Coder Legion - Recent posts tagged ttfb

TTFB Won't Go Down? Server-Side Culprits Beyond the Theme

Sun, 23 Aug 2026 10:02:00 +0000

You moved the site behind a CDN, trimmed the theme, deferred scripts, and ran a caching plugin. PageSpeed Insights still flags a high Time to First Byte on the homepage, and the waterfall shows most of the wait in Waiting (TTFB) rather than DNS or TLS. The next ticket proposes a bigger hosting plan; in our experience that upgrade often treats the symptom while the origin keeps doing too much work per request, or background jobs steal capacity when real visitors arrive.

What follows is a server-side checklist for WordPress and PHP stacks when you need to reduce TTFB after delivery-layer fixes. We focus on origin compute and scheduling: cron, workers, cache, database, and maintenance plugins. For DNS, TLS, HTTP, and CDN cache rules, start with Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. For cases where application code beats infrastructure, see Why Your WordPress Site Is Slow (It Is Not Always Hosting).

When slow server response time is not a theme or CDN problem

Lighthouse and PageSpeed Insights label high first-byte time as Reduce initial server response time. The diagnostic measures how long the browser waits after the request leaves the client until the first byte of the HTML response arrives. When DNS, connect, and TLS are already short, the remaining delay is almost always origin processing: PHP execution, database queries, remote API calls inside the page build, or contention from other jobs on the same machine.

That pattern is common on WordPress sites that look optimised in the front end but still regenerate HTML on every uncached hit. A page cache can hide the problem until a cache miss, a logged-in session, a cart cookie, or a query-string variant bypasses the edge, so your lab test shows a high TTFB while marketing reports “the CDN is on.” Treat those misses as the path that matters, not the cached marketing homepage.

Symptom in lab or RUM	Likely layer	First place to look
High Waiting, low DNS/TLS	Origin PHP / app	Object cache, query count, cold workers
Spikes at the top of each hour	Scheduled tasks	WP-Cron, backup, search indexers
Slow only when editors are logged in	Uncached admin bar / personalised HTML	Page cache exclusions, admin-ajax
Slow on `/?` and `?nocache=1` only	Full page cache working elsewhere	Origin path above
Slow after deploy, fine after warm-up	Cold opcode / PHP workers	OPcache, worker count, warm scripts

If your waterfall still shows long DNS or TLS phases, fix the network stack first; the sections below assume those hops are already reasonable.

How WordPress WP-Cron inflates time to first byte

WordPress schedules many tasks through WP-Cron, which is not a system daemon. On default setups, wp-cron.php runs on page requests: a visitor or bot triggers due jobs before WordPress serves the page they asked for. Heavy plugins add hooks for imports, sitemap builds, newsletter sends, and housekeeping that can run for seconds on shared hosting, which is why support threads about WordPress TTFB and cron keep resurfacing. A backup finishing at 09:00, a search indexer at :15 past the hour, and a security scan at :30 can stack into the same traffic window, so editors notice the site feels slow while cron owns the CPU.

Practical fixes, in order of leverage:

Disable request-driven WP-Cron in wp-config.php (define('DISABLE_WP_CRON', true);) and trigger wp cron event run --due-now from system cron on a fixed interval (every five or fifteen minutes, not on every page view).
Audit scheduled events with wp cron event list (WP-CLI) or a cron inspector plugin in staging. Remove or reschedule plugins that register hourly full-table scans on production.
Stagger plugin schedules so backup, analytics aggregation, and link checkers do not share the same minute.
Run long jobs off-peak in the site’s traffic timezone, not the agency’s office hours.

After changes, compare TTFB on the same URL at :05 and :55 past the hour; if the spread collapses, cron was the culprit rather than the theme or CDN.

PHP workers, opcode cache, and origin saturation

Even with clean cron, each uncached HTML request needs a PHP worker to execute WordPress. On FPM pools with few children, a burst of concurrent visitors queues behind a small worker count, and cold workers (first request after idle, or after deploy) pay bootstrap cost: loading WordPress core, autoloaded options, and dozens of plugin files before your theme renders one line. The checklist below covers the worker and opcode issues we see most often on agency WordPress stacks.

Checklist for worker and opcode issues:

OPcache enabled with enough memory and validate_timestamps tuned for your deploy flow (revalidate in dev; stable in prod).
Realpath cache and sensible pm.max_children for traffic (too low queues; too high can exhaust RAM and swap).
Separate pools for admin, AJAX, and front-end when the host allows it, so admin-ajax.php storms do not starve public pages.
Warm critical URLs after deploy (homepage, top landing pages, cart) before announcing release.

Origin saturation also appears when the same server runs mail, staging sync, or backup restores alongside production. Slow server response time in that case is capacity planning, not a tweak to a single plugin, but right-sizing workers and separating batch work often beats doubling CPU without touching cron or object cache.

Database load, object cache, and N+1 queries on uncached requests

WordPress without a persistent object cache hits the database for autoloaded options, post meta, and taxonomy on nearly every request. Plugins that add large autoload rows or run wide queries on init multiply that cost, and page builders with dynamic blocks can trigger N+1 query patterns when a single template loads dozens of posts or meta keys per view. Those queries run before the first byte leaves the server, so they show up directly in Waiting time rather than as a front-end script problem.

Signs the database is dominating TTFB:

Query Monitor (staging) shows hundreds of queries on the homepage.
wp_options autoload size is megabytes (transients and plugin settings that never clean up).
Slow query log spikes on wp_postmeta, wp_options, or custom tables from analytics plugins.

Mitigations that actually move first byte:

Issue	Fix
No object cache	Redis or Memcached with a drop-in (`object-cache.php`)
Fat autoload	Audit `autoload=yes` options; remove stale plugin rows
N+1 in theme or plugin	Batch queries, lazy load blocks, or cache fragment output
Missing indexes on custom tables	Add indexes in staging; measure before prod
Remote HTTP inside `the_content` filters	Remove or cache API responses with short TTL

Object cache does not replace a full-page cache, but it cuts origin work on partial misses and logged-in routes, so pair database wins with Performance Budget Thresholds Template on templates that must stay dynamic (checkout, account, enrolment).

admin-ajax storms, backup plugins, and maintenance during peak

Two other WordPress-specific patterns keep server response time high without touching the theme CSS. admin-ajax.php handles heartbeat, cart fragments, live search, and page-builder autosaves; a misconfigured plugin polling every few seconds from the front end can keep workers busy and add latency to unrelated pages on small pools. In staging, watch access logs for admin-ajax.php volume during a normal editor session, disable heartbeat on the front end where safe, fix plugins that hammer AJAX on public pages, and rate-limit bots that target wp-login.php and AJAX endpoints.

Backup and migration plugins (UpdraftPlus, Duplicator, All-in-One WP Migration, and host scheduled snapshot tools) can lock tables or saturate disk I/O during business hours. Schedule backups when analytics show the lowest concurrent users, not at local midnight on the server if that is peak in the site’s country, and test restore windows separately from performance testing because a backup run is not a deploy. Security scanners and link-checker plugins that crawl the whole site on cron belong in the same bucket: if TTFB spikes line up with their schedule in the cron list, move or throttle them before buying hardware.

How to verify TTFB fixes without guessing

Use the same priority URL and device profile before and after each change. In WebPageTest or Chrome DevTools, confirm Waiting shrank while DNS and SSL stayed flat, and run at least twice: once during a quiet minute and once when cron used to fire. For WooCommerce and membership sites, repeat on cart and checkout URLs, not only the homepage.

Scheduled PageSpeed monitoring catches regressions when a plugin update re-enables request-driven cron or adds autoload bloat. PageSpeed Insights versus automated monitoring explains why one-off lab pastes miss hour-of-day effects, while field TTFB in CrUX moves on a 28-day window and lab TTFB on your uncached path tells you whether today’s origin fix worked. Document what you changed (cron mode, object cache, backup window) in the client runbook so the next agency does not optimise the theme again while the server still runs fifty due cron events at noon.

FAQ

What is a good TTFB for WordPress?

There is no single magic number. Google’s optimize TTFB guidance treats sub-800 ms as a reasonable target for the HTML document on the network path you control, and stricter shops aim lower on cached marketing pages. Compare your origin miss path, not only the CDN hit, because a fast edge response on a cached homepage can hide a slow uncached checkout.

Does a CDN always reduce TTFB?

No. A CDN lowers TTFB on cache hits, but on misses HTML still builds at origin. Fix origin compute first if misses are common or if personalised cookies bypass cache, because a green Lighthouse score on the cached homepage will not help checkout.

Should I disable WP-Cron on every site?

For production sites with real traffic, system cron plus DISABLE_WP_CRON is the usual best practice. Keep request-driven cron only where you cannot schedule CLI (some locked-down hosts), and even then reduce due events rather than accepting page-triggered jobs on every visit.

Is high TTFB a Core Web Vital?

TTFB is not one of the three Core Web Vitals (LCP, INP, CLS), but it still affects LCP because the main content cannot paint until HTML arrives. See LCP, INP, and CLS explained for how first byte fits the wider picture.

When is upgrading hosting the right fix?

When profiling shows sustained CPU or memory limits after cron, cache, and query fixes, or when traffic outgrew the plan honestly. If doubling RAM fixes TTFB without code changes, you probably skipped object cache or cron discipline first, so rerun the checklist above before signing a larger contract.

When CDN, TLS, and theme tickets are closed and TTFB is still high, walk this server-side list before the next hosting invoice. Apogee Watcher schedules PageSpeed runs on the URLs that bypass cache so you see origin truth, not only the fast cached homepage.

Start monitoring your client sites or run a free performance check on an uncached priority URL.

References

Optimize Time to First Byte (web.dev)
Time to First Byte (TTFB) (web.dev)
Reduce server response times (Chrome for Developers)
Improve Server Response Time (Google PageSpeed Insights documentation)
Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules
Why Your WordPress Site Is Slow (It Is Not Always Hosting)
WooCommerce Performance Tuning (2026 Guide)
A Quick Way to Fix LCP: Four Changes That Cut Time to Paint
Performance Budget Thresholds Template
PageSpeed Insights versus automated monitoring
LCP, INP, and CLS explained

Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules

Fri, 17 Jul 2026 04:25:10 +0000

A PageSpeed Insights run flags a high Time to First Byte. The ticket lands on the theme backlog. Hosting gets upgraded. A CDN is added. The next lab run still shows a slow first byte on the same priority URL. In our experience the miss is often earlier in the path: DNS, TLS, HTTP version, connection reuse, edge routing, or cache policy. Theme and plugin work still matter, but they sit after the network and delivery stack has done its job. If first byte is already late, paint and interactivity inherit that delay.

What follows walks that request in order for teams who need to reduce TTFB before another theme rewrite. We stay on the network and delivery layers. For WordPress cases where code on the stack beats a bigger hosting plan, see Why Your WordPress Site Is Slow (It Is Not Always Hosting). For LCP levers once first byte is under control, see A Quick Way to Fix LCP: Four Changes That Cut Time to Paint.

What TTFB includes when you measure first byte in lab tools

Time to First Byte (TTFB) measures how long the browser waits from the start of the navigation request until the first byte of the response arrives. In PageSpeed Insights and Lighthouse, it appears as a diagnostic timing. In WebPageTest and similar waterfall tools, you can split the same wait into DNS, TCP connect, TLS, and waiting (server or edge processing). That split is what makes network work actionable for delivery teams.

TTFB is not a Core Web Vital, but it feeds Largest Contentful Paint and overall load feel. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero image or heading can paint. Field data from Chrome UX Report may show Time to First Byte as a supporting metric. Lab tools remain the fastest way to prove a DNS or CDN change after a release, because you control the URL, location, and cache state of the run.

When you read TTFB in a report, ask which hop dominated. Resolver delay looks different from a cold TLS handshake. A cache miss at the CDN looks different from an origin that regenerates HTML on every request. The sections below map each hop to what you change and what you re-test on the same priority URL.

How DNS lookup performance affects first byte

Before any TLS or HTTP work starts, the client must resolve the hostname. DNS lookup performance is the time from query to answer. On a cold visit with an empty cache, that cost sits at the front of TTFB. On a warm visit with a cached answer inside TTL, the lookup may be near zero and the problem moves downstream to connect, TLS, or waiting.

Common DNS causes of slow first byte:

Cause	What you see	Practical fix
Slow or distant resolver path	High DNS ms in WebPageTest before connect	Prefer resolvers and authoritative DNS with low latency for your audience regions
Long CNAME chains	Extra lookups before the final A/AAAA	Flatten CNAMEs where the CDN or DNS vendor allows it
Very short TTL with frequent expiry	Repeated lookups on every cold session	Raise TTL for stable records once cutovers are rare
Geo DNS mis-routing	Fast DNS, wrong PoP or origin later	Align geo policies with real user regions, not office Wi-Fi

Do not treat “add a CDN” as a DNS fix by itself. The CDN hostname still needs clean resolution. After any nameserver, record, or CNAME change, run lab tests from more than one region on the same priority URL. A London-only pass can hide resolver pain for users in another continent. Document the DNS owner per client (registrar, Cloudflare, Route 53, hosting DNS), because ownership confusion often delays the one change that would cut cold-start TTFB more than another plugin audit.

How TLS handshake timing shows up in web TTFB

After TCP connect, the TLS handshake establishes a secure session. TLS handshake cost on the web includes certificate validation, key exchange, and optional stapled OCSP data. TLS 1.3 shortens the handshake compared with older versions. Session resumption and TLS tickets reduce work on repeat connections to the same host.

When TLS shows up as a TTFB problem:

The certificate chain is incomplete or forces extra round trips to fetch intermediates.
The edge or origin still offers TLS 1.2 only, or a weak cipher suite set that clients negotiate poorly.
OCSP stapling is missing and clients block while checking revocation.
Every asset subdomain forces a fresh handshake because connection reuse and HTTP/2 multiplexing never kick in.

Fixes are usually platform configuration, not theme code: enable TLS 1.3 at the edge, staple OCSP, serve a complete chain, and consolidate hosts so the browser can reuse connections. After certificate renewals or CDN SSL mode changes (flexible versus full), re-run lab tests. A misconfigured SSL mode can add redirects that look like “slow TTFB” in a single waterfall row.

Keep handshake tuning separate from application latency. A perfect TLS setup still waits on an origin that takes 1.5 seconds to build HTML. Use the waterfall: if TLS is 40 ms and Waiting is 900 ms, move to CDN and cache rules next instead of chasing another certificate setting.

How HTTP/2, HTTP/3, and connection setup affect TTFB

HTTP version choice changes how requests share connections. HTTP/2 multiplexes many streams over one TLS connection and removes most head-of-line blocking at the HTTP layer. HTTP/3 runs over QUIC and can reduce connection setup cost on lossy mobile networks, with different trade-offs for middleboxes and debugging. Monitoring nuances for HTTP/2 and HTTP/3 belong in a later industry piece. The operational question here is simpler: is the edge speaking a modern protocol to real browsers, and are you wasting connections on cold handshakes?

Connection setup details that still matter for TTFB:

Keep-alive and connection reuse: cold connects pay DNS, TCP, and TLS again; warm navigations on the same origin should reuse.
Preconnect: use it for third-party or CDN hosts that must be ready before LCP work; do not spray preconnect across every tag manager domain.
Connection limits: too many distinct origins fragment work and multiply handshakes.
Origin versus edge: browsers talk to the CDN hostname; the CDN opens or reuses a connection to origin on miss. Origin shield and keep-alive between PoP and origin cut repeated cold connects on miss paths.

If lab tests from a single region look fine but mobile field users complain, check whether HTTP/3 is enabled at the edge and whether your synthetic tool’s protocol path matches what Chrome does for that audience. Protocol upgrades rarely fix a 2-second origin render. They do remove avoidable setup cost when you are chasing the last few hundred milliseconds of TTFB on an otherwise healthy document response.

How CDN routing and PoP selection change cache hit TTFB

CDN routing decides which point of presence answers the request and whether the response is served from cache or fetched from origin. Cache hit versus miss is often the largest swing in TTFB for cacheable HTML and static assets. A hit can return in tens of milliseconds from a nearby PoP. A miss pays PoP-to-origin latency plus origin compute, which is why “we turned on a CDN” does not guarantee a lower first byte on HTML documents.

Checklist for CDN-related TTFB work:

Confirm the URL under test is the public hostname users hit, not a bypass origin URL used only in staging.
Inspect Age, CF-Cache-Status, X-Cache, or vendor-equivalent headers on the HTML response and on the LCP asset.
Separate “CDN configured” from “HTML cacheable.” Many stacks cache CSS and images while every HTML document is private, no-store.
Enable origin shield or regional shielding when miss traffic repeatedly cold-starts the same origin from many PoPs.
Prefer stale-while-revalidate (or vendor equivalent) for pages that can tolerate brief staleness so users are not blocked on origin regeneration.

PoP selection mistakes show up as geography-specific TTFB spikes. A campaign aimed at Australia served primarily from a European PoP will look healthy in a default US or EU lab profile and poor for the real audience. Align synthetic locations with the client’s traffic share, then set performance budget thresholds on those same URLs so regressions after DNS or CDN edits are visible in the next scheduled run.

How CDN cache rules differ from browser cache

CDN cache rules decide what the edge may store and for how long. Browser cache rules decide what a returning visitor may reuse without another network hop. Mixing the two is a common source of tickets that say “we purged but TTFB did not move,” because the team purged the wrong layer or expected browser cache to fix cold document requests.

Layer	Typical policy intent	TTFB effect
Browser cache (static assets)	Long `max-age` / immutable hashed filenames	Helps repeat views; little effect on cold TTFB for HTML
CDN cache (static assets)	Long TTL at edge, purge on deploy of that asset set	Cuts miss cost for CSS, JS, images, fonts
CDN cache (HTML)	Short TTL, SWR, or selective caching for anonymous pages	Often the main lever to reduce TTFB on document requests
Origin	Correct `Cache-Control` / `CDN-Cache-Control` so the edge is allowed to store	Without this, CDN rules never engage

Purge discipline matters as much as TTL length. Blanket purges on every content edit can collapse hit ratio and return every visitor to origin cost. Prefer purge-by-URL or purge-by-tag for the templates you changed. After a purge storm, expect temporary TTFB regressions until the edge repopulates. Tell clients that pattern is expected, then prove recovery with scheduled lab runs rather than a single screenshot.

A deeper pass on Cache-Control header design belongs in a dedicated how-to later on the calendar. For day-to-day delivery, decide per content type whether the browser, the CDN, or only the origin may cache. Write that policy down. Verify headers on the live URL after each CDN or platform change.

How to diagnose network TTFB in PageSpeed Insights and WebPageTest

Use one cold lab run to see the full path, then one repeat view if your tool supports it. Cold runs expose DNS and TLS. Repeat views show whether connection reuse and cache headers behave as you expect.

PageSpeed Insights and Lighthouse

Read the TTFB-related diagnostic and the document request in the network breakdown when available. Treat a high TTFB with a green LCP as unstable: the next slower network or colder cache will expose the wait. Compare mobile and desktop profiles; connection and CPU throttling change how much TTFB dominates the timeline.

WebPageTest waterfalls

Expand the first document request: DNS, connect, TLS, Waiting. Note protocol (h2 / h3), CDN cache headers, and redirect count before the final document. Run the same URL from two locations that match the client’s audience so geography-specific PoP and DNS issues are not invisible.

Decision order we use in delivery

Redirects and wrong hostname (fix before tuning TLS).
DNS and TLS setup cost on cold load.
CDN miss versus hit on HTML and on the LCP asset.
Origin compute and application time (hand off to code or hosting diagnosis as in the WordPress guide linked above).
Protocol and connection reuse for the last stretch of budget.

Manual one-off checks catch the first regression. They do not prove the CDN change still holds next week. Pair diagnosis with scheduled PageSpeed monitoring on priority URLs. Keep PageSpeed Insights versus automated monitoring in mind when a stakeholder wants a single green screenshot as proof that the edge is healthy.

What to re-test after DNS, TLS, or CDN changes

Ship network changes with the same discipline you use for theme releases. After nameserver cuts, SSL mode edits, HTTP/3 toggles, cache rule updates, or purge policy changes, treat the edge the way you treat a theme deploy: prove the URL still meets budget before you close the ticket.

Lab-test the homepage and at least one high-intent template (product, pricing, or primary landing URL).
Capture cache status headers and TTFB from a location that matches traffic.
Compare against the budget you already set for that URL.
Watch the next few scheduled runs for hit-ratio recovery after purges.
Only then reopen theme or plugin tickets that assumed “hosting was fine.”

Apogee Watcher fits as the continuous layer on top of this checklist: multi-site schedules, device splits, and alerts when TTFB or LCP leave budget after an edge change. It layers onto your DNS and CDN vendors; it does not replace them. Network fixes stay verified without someone remembering to open PageSpeed Insights after every Cloudflare or Fastly edit.

FAQ

Does reducing TTFB always improve Core Web Vitals?Often for LCP, when first byte was a large share of the delay and the LCP element was waiting on the document or a late resource discovery. Not always for INP or CLS, which depend on main-thread work and layout stability. Treat TTFB as a supporting budget with its own threshold, then confirm LCP on the same URLs after the network change lands.

Should we cache HTML at the CDN for logged-in or personalised pages?Usually no for fully personalised HTML. Prefer caching anonymous shells or use edge strategies your platform supports without leaking private content. Wrong HTML caching creates security and correctness incidents that dwarf a TTFB win, so write the exception list into the cache policy before you enable document caching at the edge.

Is a CDN enough to fix DNS lookup performance?No. The CDN improves delivery after resolution. Flatten CNAME chains, set sensible TTLs, and confirm geo DNS still points users at a sensible PoP. Re-test cold loads from more than one region after DNS ownership or nameserver changes.

When is origin compute the real TTFB problem?When the waterfall Waiting phase dominates after DNS, connect, and TLS are small, and cache headers show misses or bypass. Then audit application time, database work, and cron load rather than another TLS tweak. That hand-off is where the WordPress hosting-versus-code diagnosis usually starts.

How soon should we re-run lab tests after a DNS cutover?As soon as TTL and resolver caches allow the new answers to appear, then again from a second region. Do not wait for a monthly report cycle to learn the cutover raised TTFB for half the audience. Put the same URLs on a short schedule for the first week after the cutover so hit-ratio and geo routing surprises show up while ownership is still clear.

Put priority URLs on a schedule after network changes

Pick one priority URL with a high lab TTFB. Export or screenshot the waterfall split for DNS, TLS, Waiting, and cache status. Fix the largest hop first, re-test from a relevant location, then put that URL on a schedule so the next DNS or CDN change cannot silently undo the gain. If you manage many client hostnames, use Watcher’s portfolio schedules and budgets so edge regressions surface the same way application regressions do.

A Quick Way to Fix LCP: Four Changes That Cut Time to Paint

Thu, 09 Jul 2026 12:39:00 +0000

Largest Contentful Paint (LCP) fails when the browser is still waiting on the server, fighting for bandwidth, or blocked on JavaScript before it can paint the biggest thing in the viewport. You do not need a six-week performance programme to move the needle. In our delivery work, four changes cover most urgent LCP regressions: fix Time to First Byte (TTFB), remove competing work from the path to the LCP element, prioritise that element with fetchpriority="high", and schedule low-value JavaScript after the load event. What follows is a practical order of operations, with enough detail to implement without re-reading a full Core Web Vitals textbook.

For background on thresholds and the four LCP sub-parts, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. For image-specific tuning when the LCP element is a hero photo, see Image Optimisation Strategies for Better LCP Scores. Both posts go deeper on sub-parts and formats; here we stay focused on the fastest fixes.

What is the path to LCP?

LCP is not one timer. It is a chain from first request to final paint of the largest visible element. Google’s documentation breaks the chain into TTFB, resource load delay, resource load duration, and element render delay. The path to LCP is everything the browser does before that element paints: HTML download, discovery of the LCP resource, competing requests, font and script work on the main thread, and layout.

When teams say “LCP is slow but the hero image is only 200 KB,” the bottleneck is usually earlier in the chain. TTFB adds blank time. Icons, analytics, web fonts, and below-the-fold images steal connection slots. JavaScript runs before the browser can commit the LCP paint even after the asset has arrived. The four fixes below map directly to those failure modes.

Step 1: Improve TTFB (Time to First Byte)

TTFB is pure page-blank time. Nothing in the viewport can render until the first byte of HTML arrives. If TTFB is 800 ms on mobile lab tests, every downstream optimisation starts late.

Treat TTFB as a caching and origin problem first:

Cache database queries on CMS and ecommerce routes that build the HTML shell. Object caches (Redis, Memcached) and query result caching cut repeated work on popular templates.
Cache full pages or page fragments at the edge. A CDN or reverse proxy (Cloudflare, Fastly, Varnish, nginx proxy_cache) should serve anonymous HTML for marketing and category pages where content is not user-specific.
Cache generated code paths where applicable. Opcode caches (OPcache on PHP), template compilation caches, and warmed application caches reduce CPU time per request.

Also check the basics: slow upstream APIs in the critical path, cold serverless instances, and TLS or DNS misconfiguration. TTFB improvements often drop LCP by hundreds of milliseconds without touching front-end assets at all, which makes this step worth doing even when the design team is already compressing heroes.

Run PageSpeed Insights and note TTFB in the diagnostics. If it is high, fix origin and caching before optimising images. Our Core Web Vitals guide lists the “good” LCP band at 2.5 seconds or less in the field; shaving TTFB is the fastest way to buy headroom when you are close to the line.

Step 2: Remove anything in the path to LCP that matters less than the LCP element

Once HTML starts arriving, the browser schedules dozens of requests. Anything that competes with the LCP resource for bandwidth or main-thread time extends resource load delay and render delay. The rule is simple: if it is not required to paint the LCP element, it should not run or download ahead of it.

Icons and decorative assets

Favicons, sprite sheets, and small UI icons often sit early in the document or load from high-priority stylesheets. They rarely affect LCP directly, but they consume connections and parser attention. Inline critical icon SVGs only when needed above the fold; otherwise load icon fonts and sprite bundles after the LCP resource is underway or from low-priority async paths.

Third-party scripts

Analytics, chat widgets, A/B testing snippets, and personalisation tags are common LCP killers. They execute in the head or early body and block parsing. Audit with the Network panel: sort by start time and see what fires before the LCP image or text block.

Practical moves:

Load tag managers and non-essential vendors after the LCP resource is discoverable (see Step 4 for load-based scheduling).
Self-host or proxy only what you truly need on first paint.
For deeper triage patterns, see Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders.

Below-the-fold images

Lazy-loading is correct for content lower on the page, but never lazy-load the LCP candidate. Conversely, do not let below-the-fold tags without loading="lazy" sit in the head of the queue with fetchpriority defaults that compete with the hero. Ensure decorative and content images that are not LCP use lazy loading and lower priority so the hero wins the network race.

Fonts that are not needed for the LCP element

Web fonts are often requested from CSS before the LCP image is even parsed. If the LCP element is a photograph, decorative display fonts do not need to block the chain. If the LCP element is a headline, only the weights used in that headline need early loading.

The goal is not “delay until interaction” tricks that hide text until a user taps. The goal is enqueue order: make sure font files for secondary UI copy enter the pipeline after the LCP resource is requested and ideally after it has started downloading. Techniques include splitting @font-face rules into non-critical stylesheets loaded later, subsetting fonts (font subsetting guide), and using system font stacks for non-LCP text on first paint.

Step 3: Prioritise the LCP element with fetchpriority="high"

Browsers schedule requests with heuristics. Hero images discovered late in HTML or hidden behind CSS may get default priority while less important assets jump ahead. The fetchpriority attribute lets you mark what matters.

For an image LCP element:

Pair with in when the LCP image is known at build time and appears late in the markup. Preload is not a substitute for fixing TTFB or removing competing scripts, but it removes discovery delay when the hero sits below inline styles or markup generated by JavaScript.

Do not set fetchpriority="high" on everything. If every image is high priority, none are. Reserve it for the single LCP candidate PSI reports in Lighthouse diagnostics.

For text or video LCP elements, the same principle applies: ensure the resource that feeds the largest paint is discoverable early and not deprioritised by lazy attributes or late injection.

Step 4: Schedule less important JavaScript after the load event

Even when the LCP asset has downloaded, element render delay can balloon if the main thread is busy executing JavaScript. Parsing, compilation, and long tasks defer layout and paint, which is why deferral belongs in the same checklist as caching and fetch priority.

defer and async help for scripts that must run before interaction, but many apps bundle analytics, carousels, and enhancement code that can wait until the page has fully loaded. The load event fires when the document and its subresources (images, stylesheets) have finished loading. Scheduling non-critical work there keeps the main thread freer while LCP is still forming.

Example pattern:



  window.addEventListener('load', function () {
requestIdleCallback(function () {
  initNonCriticalWidgets();
  loadDeferredAnalytics();
}, { timeout: 2000 });

});

Use requestIdleCallback where supported so you do not immediately replace one long task with another. Framework-specific code splitting (dynamic import() on load or on first interaction) achieves the same outcome: the LCP element paints before megabytes of client-side routing and chart libraries execute.

This is distinct from deferring fonts until interaction, which can harm readability. Here we defer JavaScript functions that do not affect first paint: heatmaps, chat bubbles, personalisation hooks, and secondary carousels below the hero.

A one-hour LCP fix workflow

Use this sequence when you have a red LCP on a priority URL and limited time:

Identify the LCP element in PageSpeed Insights or Lighthouse (Diagnostics → LCP element).
Record TTFB on mobile lab. If it is above ~600 ms, open caching and origin tickets first.
Waterfall audit: list every request and script that starts before the LCP resource. Remove or postpone icons, third parties, lazy-competing images, and non-LCP fonts.
Add fetchpriority="high" (and preload if needed) on the LCP node only.
Move non-critical JS to load + idle callbacks; retest.
Set an LCP budget in your monitoring tool so the fix survives the next deploy. See Performance Budget Thresholds Template.

Agencies managing many client homepages and landers should run mobile and desktop lab tests on the same URL after each change. One-off PSI tabs miss regressions when a plugin reintroduces a head script. PageSpeed Insights vs automated monitoring explains why scheduled tests and alerts matter once the quick fix ships.

What these four steps do not replace

These changes target the delivery path to LCP. They do not replace image compression, responsive srcset, CDN tuning, or server-side rendering when the LCP element itself is too large or injected only after client-side hydration. When the LCP element is an image, combine this checklist with the image optimisation guide. When third parties dominate the waterfall, the third-party scripts post goes deeper on vendor policy.

LCP also differs between mobile and desktop strategies. A fix on one may not carry to the other if different heroes or ad slots apply. Monitor both; see Mobile vs Desktop Core Web Vitals.

FAQ

Should I fix TTFB or the LCP image first?

Fix TTFB first when it is high. Blank time before HTML cannot be recovered by compressing a hero image. If TTFB is already healthy, focus on the path to LCP and the LCP resource itself.

Does fetchpriority replace preload?

No. fetchpriority="high" adjusts priority once the browser discovers the resource. Preload starts discovery earlier when the URL is known at build time. Use both on image heroes that appear late in the document.

Is lazy-loading the LCP element ever correct?

No. Never lazy-load the element PageSpeed Insights reports as LCP. Lazy-load below-the-fold images only.

Why defer JavaScript to load instead of using defer on every script?

The defer attribute preserves execution order before DOMContentLoaded for scripts that still run during the critical path. Analytics, widgets, and enhancement bundles that do not affect first paint can wait until load, which reduces main-thread contention while LCP is still forming.

How do I know the fix worked?

Re-run PageSpeed Insights on the same URL and strategy (mobile vs desktop). Compare LCP time and the filmstrip. For production confidence, schedule lab tests with budgets in Apogee Watcher so the next theme or tag-manager change triggers an alert if LCP drifts back above your threshold.

Can Apogee Watcher fix LCP automatically?

No. Watcher schedules PageSpeed lab tests, stores LCP and other vitals over time, and emails you when budgets breach. You still implement caching, prioritisation, and script deferral in the codebase; Watcher tells you when those fixes slip on priority URLs across client sites.

TTFB, a clear path to the LCP element, fetchpriority="high", and JavaScript deferred until after load are the four changes we reach for first when LCP is red and the release window is small. Ship them in that order, re-test on mobile lab, then lock the win with budgets and scheduled monitoring so the metric stays green after the next deploy. Start a free Apogee Watcher account to track LCP on priority URLs with mobile and desktop schedules and vitals budgets, or run a free domain PageSpeed check before you change caching or script order.