Core Web Vitals: The Factors Behind LCP, INP, and CLS

A page can feel slow in three different ways. The main content arrives late. A tap sits there before anything paints. The layout jumps while someone is trying to read. Google scores those three experiences as Core Web Vitals (CWV). The factors below are the ones that move the scores visitors actually get.

Passing is a field result, measured on real phones and desktops over a rolling month. A lab test on a fast laptop is a useful rehearsal. It is a different number.

Three Scores, One Pass

• Largest Contentful Paint (LCP) is loading. It marks when the largest image, video poster, or text block in the viewport has painted.
• Interaction to Next Paint (INP) is responsiveness. It measures the wait from a click, tap, or key press until the next frame that shows the result.
• Cumulative Layout Shift (CLS) is visual stability. It scores unexpected movement of content the visitor can already see.

A URL passes when all three are in the good band at the 75th percentile of visits. Phone and desktop are separate assessments. One poor vital fails the page. The 75th percentile means a quarter of visits can be worse than the number you are judged on, so a single lucky test does not clear the bar.

Core Web Vitals are used by our ranking systems. Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases. Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results.

Google Search Central, Understanding page experience

Field data shows how many sites clear that bar, and which vital is the hard one.

Good Core Web Vitals performance reached 48% for mobile websites and 56% for desktop websites in 2025. On phone devices, 62% of websites have a good LCP, 25% need improvement, and 13% perform poorly. For phones, 77% of websites have good INP, 21% need improvement, and 3% perform poorly. For desktop, 97% of websites have good INP, 2% need improvement, and less than 1% perform poorly. Mobile pages perform better overall, with 81% achieving good CLS, 10% in needs improvement, and 9% in the poor category.

In 2025, the median home page was 2.9 megabytes for desktop and 2.6 megabytes on mobile.

HTTP Archive, Web Almanac 2025

Loading is the vital most phones still miss. Responsiveness is mostly a phone problem. Layout stability is the one more sites already pass, and it still fails when ads, fonts, or late inserts shove the page around.

How the Number Is Collected

The score Search uses comes from the Chrome User Experience Report (CrUX), a 28-day sample of real Chrome visits. A template with too little Chrome traffic has no field score yet. Origin-level numbers can look healthy while the landing page people actually use is poor, so read the URL and the site.

PageSpeed Insights shows that field score beside a lab run. Lighthouse can measure LCP and CLS in a simulated load. It cannot see a real tap, so it reports Total Blocking Time (TBT) as the lab stand-in for INP. First Contentful Paint (FCP) and Time to First Byte (TTFB) explain the loading story. They are diagnostic vitals. First Input Delay (FID) is retired. INP replaced it because the first interaction alone hid slow taps later in the visit.

The same page code produces different scores when the visit changes. These collection rules are factors in the number, separate from the bytes on the page:

• Percentile and device: The published figure is the 75th percentile, split by phone and desktop. A fast office connection doesn’t represent a phone on a crowded network.
• The 28-day window: A fix shows up as new visits replace old ones. A bad month stays in the score until it ages out.
• Which interactions count: INP watches clicks, taps, and key presses for the whole visit. Scrolling and hovering do not count. On a long visit, a small set of the slowest outliers is set aside, and a high percentile of the rest is kept. The page is still judged at the 75th percentile of visits.
• Which layout shifts count: CLS adds up shifts inside a short session window, a burst of movement with less than a second between shifts and a cap of five seconds. The score is the worst window. A shift within about half a second of an input that was expected to move the page is left out.
• Back-forward cache: A page restored from the back-forward cache can skip a full load, so the visitor does not pay LCP again. Handlers on unload, and responses marked no-store, keep the page out of that cache. Every back tap then becomes a new load.
• In-page navigations: A single-page application (SPA) often updates the view without a new document. LCP may keep the first load’s element, while INP keeps running on every later tap. A reload in the lab can look fine while the in-app path is slow.

Read the phone field numbers for the templates that earn the traffic. Use the lab run to find the file, the script, or the shift. Treat a green Lighthouse badge as a clue, and the 75th percentile as the result.

Safari now reports the same loading and responsiveness measures through the browser application programming interfaces (API) those metrics need. Layout shift is still a Chromium measurement in the field.

Largest Contentful Paint and Interaction to Next Paint became Baseline Newly available with Safari 26.2 on December 12, 2025, because current versions of the major browsers now include the APIs those metrics need.

Cumulative Layout Shift is not supported beyond Chromium-based browsers.

Chrome, on web.dev, LCP and INP are now Baseline Newly available, 2025

What Moves Largest Contentful Paint

LCP time splits into four stages. Two of them are network work you can only shorten. The other two are delays, and a delay is time when the document or the LCP file is waiting instead of transferring. Chrome’s LCP guide treats a good result as roughly 40 percent time to first byte, 40 percent resource download, and under 10 percent in each delay.

Time to First Byte

TTFB is the wait from clicking the link until the first byte of Hypertext Markup Language (HTML). Nothing paints before that byte. These are the factors inside it:

• Redirects: Each hop repeats domain lookup, the connection, and Transport Layer Security (TLS) before HTML starts. A chain from an old address, a tracking wrapper, or the insecure scheme to Hypertext Transfer Protocol Secure (HTTPS) can eat up the entire LCP budget.
• Domain resolution: The Domain Name System (DNS) lookup is a short slice of TTFB. A managed DNS service keeps that slice short and still sits on the path before the first byte.
• Distance and the edge: A visitor far from the origin waits on the round trip. Serving the HTML from a nearby cache removes that distance for repeat views and, when the document is cacheable, for the first view too.
• Uncached HTML: A content management system (CMS) that builds the page on every request spends TTFB on the database, the theme, and the plugins. A full-page cache in front of that work is the usual fix. The cache has to hold the anonymous page real visitors receive.
• Database and application work: On a cache miss, slow queries, missing indexes, autoloaded options, and remote calls inside the template become TTFB. Putting the database on a different machine in the same network helps only when the application is actually waiting on the database.
• Load on the origin: One server that falls over at peak adds TTFB for everyone at once. Load balancing across healthy origins protects the percentile. It does not make a slow template fast.
• Personalization that skips the cache: A cookie, a query parameter, or a session that makes every HTML response unique forces the origin to render. The edge then has nothing reusable to serve.
• Document size and compression: A huge HTML file, or text served without Brotli or gzip, stretches the time to the first useful byte and the time to the rest of the document the browser needs before it can discover other files.

If TTFB at the 75th percentile is already near 2.5 seconds, the later stages have no budget left. Fix the document path before tuning images.

Resource Load Delay

Resource load delay is the gap after TTFB before the browser starts downloading the LCP file. For a text block in a system font, that gap is zero. For a hero image, it is where many poor pages lose half the budget. The usual causes:

• The file is not in the HTML: A hero injected by JavaScript does not exist until that script runs. A background set in Cascading Style Sheets (CSS) waits until the style sheet is downloaded and the layout knows the element needs it.
• Lazy loading the LCP element: Lazy loading below the fold keeps competing images out of the first wave, which helps LCP. The same attribute on the hero tells the browser to wait. The LCP image should load immediately.
• Priority: The LCP image should carry fetchpriority="high". Preload that same URL when the tag would otherwise be discovered late. Preloading a different image, a font, or a script steals bandwidth from the file that decides LCP.
• Render-blocking files ahead of the hint: A long chain of style sheets in the head, or a parser-blocking script, postpones discovery of an image URL that appears later in the document.
• A hero on another host: An image served from a different site waits on a new lookup and a new secure connection unless that host is already connected. A preconnect to that host, or serving the hero from the same host, removes the extra setup.
• Carousels and late candidates: The first slide is often the LCP element, and a script that swaps it after load delays the real image and risks a layout shift.

The LCP URL belongs in the initial HTML, at high priority, with lazy loading reserved for everything further down the page.

Resource Load Duration

Once the download starts, duration is file size, distance, and competition for the connection. These factors set that duration:

• Pixel dimensions: A 4000-pixel source in an 800-pixel slot downloads pixels the screen never shows. srcset and sizes let the phone skip the desktop file.
• Format and quality: AV1 Image File Format (AVIF) and Web Picture (WebP) are smaller than a Joint Photographic Experts Group (JPEG) or Portable Network Graphic (PNG) at the same visual result. Quality settings and image compression determine the byte count after you choose a format.
• Video as the largest element: A background video, or a large poster, becomes the LCP element. The poster has to be as disciplined as a hero image. The video file itself should not be required before first paint.
• Where the file is cached: A content delivery network (CDN) shortens the trip for images and video when the object is warm at the edge. A miss at the edge on the hero is a full trip back to origin at the worst moment.
• Competition: Style sheets, scripts, and extra images that share the connection stretch the hero’s download. Fewer early files, and a higher priority on the one that matters, shorten this stage.

A hero that is discoverable, sized to the slot, and encoded for the web spends this stage on the transfer. This is the shape of that tag:

<img src="hero.avif" width="1200" height="675" alt="Hero" fetchpriority="high">

The width and height also reserve the box so the image does not shove the layout when it arrives. That part of the tag is a CLS factor as much as an LCP factor.

Element Render Delay

Element render delay is the wait after the LCP file has arrived before it paints. The file can be sitting in memory while the page is still blocked. The common blocks:

• Render-blocking CSS: The browser holds first paint until the stylesheets in the head arrive. Critical CSS for the top of the page, and the rest deferred, cuts this wait. A single unused style sheet in the head holds the hero anyway.
• Parser-blocking scripts: A script in the head without defer or async stops the parser. The LCP element further down the HTML is not even built yet.
• Web fonts on a text LCP: When the largest element is a heading, a font that blocks rendering holds LCP until the font file arrives. A fallback with matching metrics, and a font-display policy that allows text to paint, lets the heading count earlier.
• The element is not in the document yet: If JavaScript creates the hero node, paint waits on download, parse, and execution. Server-rendered HTML already contains the node when the file arrives.
• A busy main thread: Long tasks at startup delay the paint even after the bytes are local. Third-party tags that run immediately compete with the first frame.

Render delay should be a sliver. If the hero file is done and the screen is still blank, the blocker is CSS, a script, a font, or the thread.

Chrome’s field breakdown of poor LCP shows how often the first two stages consume the budget on their own.

For at least half of the origins with poor LCP, a 75th-percentile time to first byte of 2,270 milliseconds alone nearly guarantees that LCP cannot be faster than the 2.5 second good threshold. The median site with poor LCP spends almost four times as long waiting to start downloading the LCP image as it does actually downloading it, waiting 1.3 seconds between the first byte and the image request.

Chrome, on web.dev, Common misconceptions about how to optimize LCP

What Moves Interaction to Next Paint

INP is one interaction, usually a slow one, broken into input delay, processing time, and presentation delay. Input delay is the wait before your event handler starts. Processing time is the handler itself. Presentation delay is the wait from the end of the handler until the browser paints the next frame. A tap can fail any of the three.

Input Delay

The main thread can be busy before the visitor ever taps. That backlog becomes input delay. The factors that fill it:

• Script evaluation: After a JavaScript file downloads, the browser still parses it, compiles it, and runs it. Large bundles and unused code turn that work into long tasks.
• Third-party tags: Analytics, ads, chat, consent platforms, and split-test scripts often run during load. A tag manager that waits for the page to settle, and a short list of tags that deserve to run at all, keeps the thread free for the first taps.
• Hydration: A client framework that rebuilds the page in the browser can occupy the thread after the HTML has already painted. Taps during that window wait.
• Timers and overlapping taps: Recurring timers and main-thread animation frames compete with input. A second tap that arrives before the first frame paints adds another delay.
• Plugin and builder weight: On a WordPress site, the theme and each plugin can add a script to every template. The ones that do no work on that template still cost parse time.

Input delay falls when less JavaScript runs before the visitor needs the page, and when the rest is deferred until after the first paint.

Processing Time

Processing time is the work your handler does before it returns. These patterns stretch it:

• Heavy handlers: Filtering a large list, rewriting a big tree of nodes, or waiting on a synchronous request inside a click keeps the frame from starting.
• Layout thrashing: Reading layout, writing style, and reading layout again in a loop forces the browser to recalculate in the middle of the handler.
• Third-party work in the handler: A click that calls into a chat widget, a form embed, or a split-test library inherits that library’s cost.
• Document size: A huge Document Object Model (DOM) makes every query and every update more expensive. Fewer nodes mean faster handlers.

Handlers that update only what changed, and that leave network calls asynchronous, stay inside the 200 millisecond budget on a mid-range phone.

Presentation Delay

The handler can finish, and the screen can still wait. Presentation delay is the paint. It grows when:

• Style and layout are expensive: Complex selectors and a large DOM make the browser spend the frame on style recalculation and layout.
• The update is too big: Replacing a whole region, or rendering a result the visitor cannot see yet, paints more than the interaction required.
• Animation runs on the main thread: Animating position, height, or margin makes the main thread do layout. Animating transform and opacity can stay on the compositor and off the interaction’s path.

INP improves when the next frame is small. Show the result of the tap, and do the rest after that frame.

What Moves Cumulative Layout Shift

CLS rises when something that is already visible moves without a visitor asking it to. The score weights how much of the viewport moved and how far. These are the shifts that show up in the field:

• Images, video, and iframes without a box: Missing width and height, or a missing aspect ratio, let the element open from nothing and push what is below it. The attributes in the hero example above are the fix.
• Ads, embeds, and embeds that resize: A slot that starts at zero height and grows when the creative arrives shifts the article. Reserve the largest size you are willing to show, and put late units below the content the visitor came to read.
• Banners inserted above existing content: Cookie bars, promo strips, and related-article modules that push the page down are layout shifts. A bar that overlays, or a space reserved before first paint, keeps the content still.
• Web fonts with different metrics: A fallback and a web font that differ in size, width, or line height move every line when the font swaps. Matching the fallback with size-adjust and related overrides, or using a font-display policy that avoids a late swap, removes that shift.
• Late CSS: A style sheet that arrives after first paint and changes type size, spacing, or visibility moves content the visitor has already seen.
• Content visibility without a reserved size: Skipping rendering for off-screen regions is fine when the skipped box has an intrinsic size. Without that size, the page jumps as the visitor scrolls those regions into view.
• Layout animations: Transitions on top, height, or margin are shifts if they run without a recent input. Transform and opacity do not move the document flow.

Reserve the space, paint the text with a font that fits the same box, and insert new material without pushing the content already on screen.

Delivery Choices That Touch Every Vital

A few platform choices move more than one score at once. They are easy to get wrong because older habits were built around a different set of browser limits.

• Multiplexed connections: HTTP versions 2 and 3 carry many files on one connection. Splitting scripts, style, and media across extra hostnames adds handshakes and usually slows LCP. Fewer origins, with the important file prioritized, beat domain sharding.
• Text compression: Brotli or gzip on HTML, CSS, and JavaScript cuts transfer time. Smaller scripts also parse faster, which shows up in INP as shorter startup tasks.
• Cache partitioning: A library or font hosted on a public domain is downloaded again for your site. Browsers keep those caches separate per site, so a shared host adds an extra connection and extra delay for both LCP and input delay.
• Early hints and speculation rules: A 103 response can start the LCP image before the HTML finishes. Speculation rules can prerender the next page so its LCP is already done when the visitor clicks. Both use bandwidth and processor time, and both change the following page’s field score when they hit.
• The back-forward cache, again: Eligibility is a delivery choice. Cache-Control no-store and unload listeners trade a fresh load, and a fresh LCP, for every return visit via the back button.

Serve one cacheable document from a nearby edge, compress the text, prioritize the LCP file, and keep third-party hosts off the first paint unless the page cannot render without them.

How Browsers Fetch in Parallel

The parser does not finish the document before it asks for other files. While it reads HTML, a preload scanner looks ahead for images, style sheets, and scripts and starts those downloads in parallel. A hero URL written in the first HTML can begin transferring before the rest of the page has been parsed.

Older HTTP allowed only a handful of files in flight to one host, which is why sites split assets across extra hostnames. Current HTTP carries many files on one connection. Those files still share the bandwidth, and the browser still chooses which one goes first. Parallel fetching removes the old connection cap. It does not give every file the wire at the same time.

A file the scanner cannot see yet waits. A hero set in a style sheet, a font named only inside that style sheet, and an image injected by a script all start later than a URL sitting in the HTML. That wait is resource load delay, even on a fast connection.

Write the critical URLs where the scanner can see them, and mark which of those parallel downloads has to finish first.

Resource Hints

A resource hint starts work the scanner would otherwise begin later. It sits in the document head, or in an early response, and it names a host or a file. The hint does not replace the tag that actually uses the file.

Each hint does a different amount of work:

• dns-prefetch: Resolves the hostname and stops there. Use it for a host you will need soon, but not for the file that decides the first paint.
• preconnect: Resolves the name, opens the connection, and finishes the secure handshake. Keep it to the one extra origin that serves the LCP file or a font the first paint requires. The cross-origin mode has to match the later request. Fonts are fetched in that mode, so a preconnect without it opens a second connection and wastes the first. Several preconnects compete with the document.
• preload: Downloads one specific file now. Point it at the real LCP image, or at the style sheet or font the first paint needs. Set as to the file type. Set fetchpriority to high only on the LCP file. A preload of a different image, a late script, or an unused font takes bandwidth from the file that decides LCP.
• modulepreload: Downloads a module script, and the modules it depends on, so they can compile before that script runs. It belongs on a module the current page needs immediately. It is not a way to pull the rest of the application into the first wave.
• prefetch: Downloads a file for a likely next page, at low priority. It has to stay behind the current page’s LCP image and the scripts that handle the first tap.
• Prerender: Speculation rules can build the next page in the background so its largest paint is already done when the visitor continues. That spends bandwidth and processor time on a page the visitor might never open.
• Early Hints: A 103 response can carry the preload and the preconnect before the HTML is finished, so the LCP file starts while the origin is still building the document. The URL in the hint has to be the file the document will use.
• fetchpriority: This is a priority on a request the browser is already making, not a separate download. High on the LCP image, and low on images further down the page, is how the shared connection is divided.

A preconnect for the image host, and a preload for the hero file, look like this:

<link rel="preconnect" href="https://images.example" crossorigin>
<link rel="preload" href="hero.avif" as="image" fetchpriority="high">

Hints move the start time. They do not shrink the file. A hint for a file the page never uses is another download on the critical path.

Caches from the Browser to the Database

The CDN, the browser, a page cache, compiled code, an object cache, and the database each hold a different result. A hit on an outer layer means the inner layers never run for that request. Database caching is the work you skip when HTML, compiled code, and saved results are already in memory.

• Browser cache: Cache-Control on fingerprinted CSS, JavaScript, and images can last a long time, because the filename changes when the bytes change. Keep HTML on a short lifetime so a correction shows up. A document sent with no-store also skips the back-forward cache on the return visit.
• CDN and the edge: The edge can store anonymous HTML and static files closer to the visitor than the origin. A cookie, a session, or a Vary header that differs for every visitor causes a cache miss, and the document or the hero comes from the origin at the moment LCP can least afford it.
• Page cache: A full-page cache stores the finished HTML so PHP does not build the anonymous page again. Logged-in and personalized responses stay out of that cache, unless a variant is reused often enough to be worth storing on its own.
• OPcache: When the page cache misses, PHP still has to run. OPcache keeps the compiled bytecode in memory so the request skips compilation. It does not store HTML, options, or query results. Give it enough memory for the code you actually run, and let it notice new files so a deploy is not stuck on the previous bytecode.
• Object cache: Redis or Memcached keeps the options, transients, and query results WordPress would otherwise request on every miss. The page cache stores HTML. OPcache stores compiled PHP. The object cache stores the data those requests would have pulled from the database.
• Database: Indexes keep the remaining queries on the rows they need. The buffer pool keeps those hot pages in memory so repeat reads don’t wait on disk. Repeated results belong in the object cache.

Serve anonymous HTML from the page cache or the edge. On a miss, compiled code and the object cache should make the origin’s remaining work short. The database then answers only the reads those caches did not already hold.

Performance Add-Ons

A WordPress page-cache plugin and an optimization service such as NitroPack, can help. They store the anonymous document, defer scripts, shrink images, and sometimes serve the page from their own edge. A slow origin can get faster without rewriting the theme.

That help is another layer in front of the page. Stacking these add-ons means more than one system can rewrite the HTML or change when scripts run. Attribution, event management, and analytics need each tag to fire on the right page, in the right order, with the campaign identifiers still attached. These are the breaks that show up after the score improves:

• Attribution: A cached or rewritten landing page can drop the click identifier. The sale is then credited to the wrong campaign, or to none.
• Event management: A delayed or combined script can fire the event after the visitor has left, or swallow the data the tag manager was waiting on.
• Analytics: Two layers that both inject a tag, or both defer it, produce a missing session or a second pageview for the same visit.

The goal is to fix the core problem. Make the document cacheable, put the hero in the first HTML, shorten the tasks that delay the next paint, and reserve the space that jumps. Add one plugin for a gap that is still open. A second plugin that rewrites the same files will fight the first, and the field score is the wrong place to discover a missing conversion.

A CDN is an exception. An edge network that stores files close to the visitor is something most teams cannot build or afford to run on their own. Cloudflare Zaraz is the other exception. It runs third-party tools at the edge, off the visitor’s browser, which is the same kind of infrastructure. Use those for the edge work. If the host already stores anonymous HTML, leave the extra cache plugin out and fix the template, the hero, and the tags.

Scores That Sit Beside the Vitals

Several famous numbers describe the same visit and do not change the Core Web Vitals assessment.

• The Lighthouse performance score: That 0 to 100 figure is a weighted lab mix. TBT is the heaviest piece. The ranking systems use the field LCP, INP, and CLS at the 75th percentile.
• FCP, Speed Index, and TBT: They help you find a render-blocking file or a long task. They are not part of the pass-or-fail assessment.
• FID: It measures only the delay before the first handler started. A page could pass FID and still feel late on every later tap. INP is the responsiveness metric.
• HTTPS, mobile layout, interstitials, and ad density: Google’s page-experience questions still include a secure connection, a layout that works on a phone, and pages that are usable without a blocking interstitial or a wall of ads. Those factors shape the visit. They do not move the three vital numbers. Intrusive interstitials can still cause layout shifts or long tasks when the implementation pushes content or runs a heavy script. The interstitial policy itself is a separate review.

Use the lab score to choose the next fix. Report the three field vitals when someone asks whether the page passes.

Where to Read the Result

Search Console groups URLs that share a template and shows which vital failed over the last 28 days. PageSpeed Insights reads the same field data for one address and adds the lab trace that names the file. Neither one replaces your own real user monitoring (RUM) when you need the slow interaction, the element that shifted, or the LCP stage on a single visit.

Start with the phone percentile for LCP, then INP, then CLS. Trace LCP through the first byte, the wait before the hero downloads, the download itself, and the wait before paint. Trace INP through input delay, the handler, and the next frame. Trace CLS to the node that moved. Remove the factor that eats the budget.

Measure a URL with PageSpeed Insights

Run the address through our PageSpeed Insights tool. It runs PageSpeed Insights for one URL on a phone or desktop profile, adds a redirect check, and measures network timing from our server.

Read the report in this order:

• Redirects: A chain appears when the address hops before the final URL. Each hop repeats the connection before HTML starts.
• Category scores: Lighthouse rolls many audits into a 0-100 score per category. That number is a summary. The pass or fail is the field vitals.
• Field vitals for this URL: These are the 28-day results for the address when enough visits exist. Phone and desktop are separate. When this URL is too thin, the whole-site block is the origin, and it is not a second measurement of the page.
• Network timing: This is the name lookup, the Transmission Control Protocol (TCP) connection, TLS, the server response, and the transfer of the initial HTML. We measure it from our server with a standard browser agent, so it can look healthy when the lab run was blocked.
• Lab metrics: One throttled Lighthouse run on the profile you chose. Use it to see the file. The ranking uses the field numbers above it.
• Opportunities and diagnostics: Opportunities are ranked by estimated savings. Open diagnostics when savings are small or hard to estimate. An empty pair means the lab run found no outstanding performance issues. The same report can be downloaded.

If a crawler block drops the lab run, the category scores, opportunities, and diagnostics are intentionally left out. Field vitals and network timing remain, and they still describe real visits and the document response.

Correct What the Audit Finds

Match the failing vital to the opportunity that names the file. The estimated savings are a forecast from one lab run. The field score moves after new visits replace the 28-day window. Search Console stays the scoreboard for a template because it groups the URLs that share it.

These are the corrections the usual findings are asking for:

• Redirect hops: Point internal links and the canonical address at the final URL so the document is the first response.
• A slow server response: Put anonymous HTML on the page cache and on the CDN. On a miss, OPcache should already hold the compiled PHP, and the object cache should already hold the options and query results. What remains is an indexed read from memory. Adding workers does not make one slow template fast.
• Render-blocking files: Defer scripts the first paint does not need, and send the CSS for the first screen in the initial response. A chain of style sheets postpones the hero URL.
• An LCP image discovered late: Preload that exact URL with fetchpriority high, and leave lazy loading for images below the fold. A preload of any other file competes with the hero.
• Large or older images: Offer a file that matches the slot, with srcset and sizes, in AVIF or WebP.
• Heavy JavaScript: Ship less of it, split off what this page does not need, and keep tasks short. That is what moves INP. Third-party tags wait until after first paint unless the page cannot render without them.
• Images, ads, and fonts without a box: Set width and height, reserve the ad slot, and match the fallback font to the web font. That is the CLS finding.
• Uncompressed text or a short-lived static file: Brotli or gzip on HTML, CSS, and JavaScript, and a long lifetime on fingerprinted assets; this shortens this visit and the next one.

Apply the change to the trace names, then run the URL again to confirm the lab forecast moved. The pass is still the phone percentile for LCP, then INP, then CLS, after the field window includes the new version.