Site Speed Optimization: Where the Time Goes

Site speed optimization is the work of making pages load and respond faster for real visitors, measured by field data such as Google’s Core Web Vitals rather than by a lab score. The fastest route is not a checklist of fifty tips. It is finding where the time actually goes on your slowest templates, then fixing the server, caching, images, fonts, JavaScript and third-party scripts in roughly that order.

This guide is for marketers and developers who already know what the metrics mean and want to know what to do next. If you need the definitions and thresholds for LCP, INP and CLS first, start with Core Web Vitals explained. This page is the practical sequel: how to measure, where the milliseconds hide, and the order of work that moves real-user numbers.

On this page

• Does site speed affect SEO?
• What should you measure before fixing anything?
• Where the time goes: the four parts of LCP
• Server response, caching and CDNs
• Images: the usual LCP element
• Fonts without the flash or the wait
• JavaScript, INP and third-party scripts
• Making site speed optimization stick

Does site speed affect SEO?

Yes, but less than most speed-tool marketing implies. Google’s page experience documentation says Core Web Vitals “are used by our ranking systems”, that there is “no single signal” for page experience, and that “trying to get a perfect score just for SEO reasons may not be the best use of your time”. It also says Google “always seeks to show the most relevant content, even if the page experience is sub-par”.

Speed pays off in three other ways that are easier to see:

• Conversions. Visitors who wait leave. That effect shows up in your analytics, not in rankings.
• Crawling. Google’s crawl budget guide says that if Google can load and render your pages faster, “we might be able to read more content from your site”, and that stable or improving response times let its crawl capacity limit go up.
• Everything around the metrics. Google says page experience aspects beyond Core Web Vitals “don’t directly help your website rank higher”, but they make a site more satisfying to use, “which is generally aligned with what our ranking systems seek to reward”. Speed sits alongside the other checks in our technical SEO checklist for AI search.

What should you measure before fixing anything?

Field data comes from real visitors on real devices; lab data comes from one simulated load in a controlled setting. Google’s web.dev article on lab and field data differences explains why they disagree: your lab data might show a fast site while field data says it needs improvement, or the other way round. When they disagree, field data is what your visitors experienced.

The thresholds that define “good” are set on field data. Per web.dev’s Web Vitals overview, a page passes when, at the 75th percentile of page loads, LCP is within 2.5 seconds, INP is 200 milliseconds or less and CLS is 0.1 or less. How common is a pass? The HTTP Archive’s 2024 Web Almanac performance chapter gives the baseline for the web as a whole.

Practical setup, in order of usefulness:

1. Search Console’s Core Web Vitals report groups similar pages into URL groups by status, so you fix templates rather than single pages.
2. PageSpeed Insights shows field data for a URL or origin when there is enough Chrome traffic, plus a Lighthouse lab run for diagnosis.
3. Chrome DevTools’ Performance panel shows your local experience next to the field LCP and breaks LCP into its parts, according to web.dev’s LCP guide.
4. Real-user monitoring on your own site, if you can add it, because it covers pages too quiet to appear in Chrome’s public dataset.

Where the time goes: the four parts of LCP

Every LCP time breaks down into four consecutive parts, and fixing the wrong one moves nothing. Google’s web.dev guide to optimizing LCP splits it into time to first byte, resource load delay, resource load duration and element render delay, with “no overlap or gap between them”. On a well-optimized page, the two network parts take about 40% each and the two delays under 10% each.

The guide’s warning is the part most teams miss. If you compress the hero image but the page is still waiting on a render-blocking script, the saved time “would just shift to the element render delay subpart”. Find the biggest part first, fix it, then measure again.

Server response, caching and CDNs

Time to first byte is the foundation, and it is where the web does worst: only 42% of mobile sites had a good TTFB in the 2024 Web Almanac. Everything else waits for it.

• Cache HTML at the edge where you can. A static or cached page served from a CDN close to the visitor removes most of the server’s thinking time. Pages that must be dynamic still benefit from caching their fragments or database queries.
• Give static assets long cache lifetimes. Google’s web.dev guide to HTTP caching recommends fingerprinted file names, such as style.x234dff.css, served with Cache-Control: max-age=31536000, so repeat visits skip the download entirely. Unversioned URLs, including HTML, should be revalidated instead.
• Support 304 Not Modified. Browsers use it on revalidation, and Google’s crawl budget guide recommends it for crawlers too: a 304 tells Google to reuse its cached copy, saving your server bandwidth.
• Remove redirect hops on the way in. Every hop between an old link and the final URL adds a round trip before the first byte. Our guide to redirects and SEO covers flattening chains.

Images: the usual LCP element

On most pages the largest element is an image, so image work usually moves LCP the most. The 2024 Web Almanac found images were the LCP element on 73% of mobile pages. It also found three common self-inflicted delays:

• The image isn’t in the HTML. 35% of mobile sites had an LCP element that wasn’t discoverable in the initial HTML, for example because JavaScript inserts it.
• The image is lazy-loaded. 16% of mobile sites lazy-loaded their LCP image. web.dev is blunt: “Never lazy-load your LCP image.”
• The image is a CSS background. 9% of mobile pages started the LCP resource from CSS, which delays discovery until the stylesheet is processed.

The fixes follow directly. Put the hero image in the HTML as a real <img>, add fetchpriority="high" to it, and if it must come from CSS or JavaScript, preload it. Only 15% of mobile sites used this prioritization in 2024, so it is still an easy edge. Then shrink the file: serve AVIF or WebP at the size it is displayed, and set width and height so the layout doesn’t jump. Everything below the first screen can be lazy-loaded. For how image markup also helps AI engines understand the page, see image SEO for AI search.

Fonts without the flash or the wait

Fonts delay text, and text is the LCP element on about a quarter of mobile pages. The web.dev guide to font best practices gives a short list:

• Use WOFF2 only. It compresses about 30% better than WOFF and is supported everywhere that matters.
• Subset and use fewer families. Most font files carry glyphs your pages never use.
• Preconnect to third-party font origins, or inline the @font-face declarations so the browser finds fonts early.
• Preload carefully. Preloading helps when fonts are declared in an external stylesheet, but it takes bandwidth from other resources, so preload one or two critical files at most.
• Pick a font-display strategy deliberately, and tune the fallback font’s metrics to reduce the layout shift when the web font swaps in.

Self-hosting isn’t automatically faster. The same guide says the difference is “less clear cut” than it looks, and that self-hosted fonts are much less likely to win unless your site uses a CDN and HTTP/2.

JavaScript, INP and third-party scripts

JavaScript is now the most requested file type on the web, and it is the main reason phones feel sluggish. The 2024 Web Almanac’s page weight chapter found the median mobile page makes 22 JavaScript requests out of 66 in total. Its performance chapter found 74% of mobile sites have good INP against 97% on desktop, a gap that reflects slower phone processors running the same code.

For your own code, web.dev’s guide to optimizing INP comes down to keeping the main thread free:

• Ship less. Remove unused libraries and split bundles by route.
• Break up long tasks. Yield to the main thread between chunks of work so interactions aren’t queued behind them.
• Do the visual update first. Run only the code needed to paint the response to a click, and defer the rest to a later task.
• Keep the DOM small, and prefer server-rendered HTML to building large pages with client-side JavaScript. Server rendering also helps crawlers, as covered in JavaScript rendering and AI crawlers.

Third-party scripts deserve their own review because you don’t control their code. Google’s guidance on loading third-party JavaScript says to always load them with async or defer unless they are needed for the critical rendering path, to use preconnect or dns-prefetch for their origins, and to consider self-hosting a script if the provider’s server is slow. Then ask the harder question: does each tag still earn its cost? A chat widget, three analytics tools and an abandoned A/B testing script are common on sites that “just need a faster theme”.

Making site speed optimization stick

Speed decays. Every new tag, plugin, hero video and font weight adds cost, and most sites get slower between redesigns without anyone deciding they should. The teams that stay fast treat speed as a budget with an owner, not a one-off project.

The working order that follows from everything above is short:

Two habits keep the gains. Check the Core Web Vitals report after every release that touches templates, and require a reason for every new third-party tag. When a redesign is coming anyway, build performance into the templates instead of patching it afterward; our notes on website redesign SEO cover what else to protect during that work. If your site needs rebuilding on a faster foundation, our web development service ships static-first sites with images, fonts and scripts handled this way by default.