Login pages are the second-highest-traffic page on most SaaS sites, after the landing. They’re also where many teams unknowingly ship 300KB of blocking JavaScript that makes the page feel broken on mobile.
Measure first
Open your login page in Chrome DevTools with a throttled “Fast 3G” connection. Record a Lighthouse run. You’re looking for:
- Largest Contentful Paint (LCP): should be under 2.5s. On most slow login pages, LCP is 4-7s.
- Time to Interactive (TTI): should be under 3s. Often 5-10s.
- Total Blocking Time (TBT): should be under 200ms. The usual culprit — auth SDKs evaluating synchronously.
If LCP is bad, it’s probably render-blocking resources. If TBT is bad, it’s probably JavaScript execution.
The usual suspects
1. Auth SDK in the critical path
Most auth vendors’ snippets include 100-300KB of minified JS that initializes on page load. If you’re loading it synchronously in <head>, you’re blocking first paint on an SDK that won’t actually be used until the user clicks a button.
Fix: load the SDK defer or async. If the SDK requires it to be loaded before render (some older ones do), see if the vendor offers a modern ESM version that’s tree-shakable.
2. Over-eager initialization
The SDK loads — then it does a round-trip to check the user’s session, loads configuration, hydrates state. All before the user has done anything.
Fix: lazy-initialize. Load the SDK, but only init on first user action (click a button, start typing). Your login form doesn’t need the SDK to render.
3. WebAuthn feature detection synchronously
WebAuthn detection involves PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable(), which can be slow on some platforms. Running it synchronously during page load blocks.
Fix: run it asynchronously after first paint. Show the password form immediately; reveal the WebAuthn button once the feature check resolves.
4. Third-party scripts on the login page
Analytics, session replay, A/B testing SDKs, Zendesk chat widgets — they all want to be on the login page for tracking reasons, and they all cost hundreds of milliseconds. Ask whether you actually need them here. The conversion gain from adding them is often less than the conversion loss from slowing down the page.
A minimal login page
- HTML with the form inlined.
- One script tag:
<script defer src="..."></script>for the auth SDK. - No third-party scripts above the fold.
- Fonts preloaded or system-font-stacked.
Your login page should be under 100KB total, first paint under 1s on a mid-range phone. If it’s 5× that, something fat is in the critical path.