Improve LCP by identifying the actual largest element and shortening every preceding delay.
Expose its resource early, give it suitable priority, and render it promptly.
Do not optimise a guessed hero while another element controls the metric.
Understand what LCP measures
Largest Contentful Paint measures when the largest eligible viewport element appears.
Eligible candidates commonly include images, text blocks, videos, and background images.
The candidate can change while the page loads and larger elements render.
Use the current good target
Google defines good LCP as 2.5 seconds or faster.
Apply that target at the seventy-fifth percentile of page visits.
Optimise field experiences, then use controlled laboratory runs for diagnosis.
Identify the actual LCP element
Record the public page in browser performance tools.
Inspect the LCP marker and its associated rendered DOM node.
Repeat across mobile and desktop. Different viewports can produce different winners.
Do not assume the hero wins
A smaller mobile crop may lose to a large heading.
A cookie notice or delayed banner can introduce another large element.
Use evidence from every representative template and viewport.
Break LCP into four subparts
The web.dev LCP guide separates four useful timing subparts.
They cover server response, resource discovery, resource transfer, and element rendering.
Text LCP has no separate image transfer but still has rendering dependencies.
Shorten time to first byte
The browser needs the HTML response before discovering most page resources.
Slow uncached generation delays every later LCP phase.
Measure server timing separately from browser rendering.
Check WordPress page caching
Anonymous page caching can avoid repeated WordPress generation work.
Cookies, query strings, personalisation, and logged-in sessions may bypass it.
Inspect response headers and compare cold, miss, and hit behaviour.
Check dynamic block rendering
Dynamic blocks can run database queries or remote requests before returning HTML.
A slow Query Loop can delay a hero rendered elsewhere.
Profile server work and cache safe results where appropriate.
Check template complexity
Headers, navigation, patterns, queries, and template parts all render before delivery.
Repeated dynamic components can increase response time and HTML size.
Test representative templates rather than one unusually simple post.
Reduce resource load delay
Resource load delay starts after HTML arrives but before the resource request.
Late discovery, low priority, and competing requests can extend it.
For image LCP, this phase often offers substantial improvement.
Make the LCP image discoverable
Use a real image source in the initial server-rendered HTML.
JavaScript-injected sources prevent the preload scanner from finding them early.
`data-src` placeholders can create the same discovery delay.
Do not lazy-load the LCP image
Lazy loading waits for layout before requesting an in-viewport image.
That delay directly worsens an image-based LCP.
Inspect final markup for `loading=”lazy”` after all WordPress filters run. The detail lives in font loading on WordPress block themes.
Use high fetch priority selectively
`fetchpriority=”high”` tells browsers that one resource deserves greater relative priority.
WordPress can add it to a likely important image.
Do not mark many images high. Priority loses meaning through competition.
Understand WordPress image logic
WordPress coordinates loading, fetch priority, and decoding attributes for images.
Core introduced central loading optimisation logic to avoid conflicting decisions.
Inspect output because theme and plugin filters can override defaults.
Check featured images
A template may render featured media before the post’s saved blocks.
That image can become LCP across every article using the template.
Optimise its markup, size selection, priority, and delivery at template level. We looked at that in when block markup gets too deep.
Check Image blocks above the fold
An early Image block can become LCP when no featured image exists.
Its position depends on headings, notices, templates, and viewport height.
Do not force every first content image high without measuring.
Check Cover block backgrounds
CSS background images are discovered after the relevant stylesheet arrives.
This can delay a Cover block’s large background resource.
Prefer discoverable image markup when semantics and design allow.
Preload only undiscoverable critical media
A preload can expose a critical background resource earlier.
It forces a fetch, so incorrect preloads waste bandwidth and priority.
Match responsive sources carefully. Confirm the requested resource is actually used.
Use responsive image candidates
`srcset` lets browsers choose an appropriate image candidate.
The `sizes` value must describe the expected rendered width accurately.
An oversized candidate extends transfer and decoding without adding visible value.
Check full-width alignments
Wide and full images may need larger candidates than content-width images.
Theme layout determines their real CSS width at each viewport.
Compare selected candidate dimensions with rendered dimensions in browser tools.
Compress the exact LCP resource
Optimising unused attachment sizes cannot change the delivered candidate.
Identify its URL, format, dimensions, transfer size, and cache status.
Reduce bytes while preserving acceptable visual quality.
Choose modern formats from evidence
Modern formats can reduce bytes for suitable images.
Encoding settings, image content, and browser support affect actual savings.
Compare delivered quality and size. Do not trust file extensions alone.
Serve media from efficient origins
Same-origin media can reuse the page’s established connection.
Remote media may require DNS, connection, and security negotiation first.
Measure real timing before moving critical assets or adding connection hints.
Reduce resource load duration
Transfer duration depends on bytes, network quality, server speed, and competition.
Prioritisation cannot eliminate an unnecessarily large image.
Compression cannot eliminate late discovery. Fix each subpart directly.
Reduce element render delay
A downloaded resource can wait before its element paints.
CSS, JavaScript, fonts, overlays, and animations can postpone visibility.
Compare resource completion with the recorded LCP time.
Check render-blocking CSS
Browsers need applicable CSS before rendering styled content reliably.
Large global stylesheets can delay a simple visible block.
Remove unused rules cautiously and preserve critical above-the-fold styling.
Check block plugin CSS
A plugin may load shared styles for many blocks on every page.
Another may enqueue styles only when a registered block renders.
Inspect the network waterfall and stylesheet contents before changing delivery.
Check JavaScript visibility classes
Some blocks hide content until initialisation adds a ready class.
The image may finish downloading while its wrapper remains invisible.
Render useful initial content without waiting for enhancement scripts.
Check entrance animations
Fade-ins and delayed animations can postpone the final visible state.
They can add render delay without improving comprehension.
Remove delays from likely LCP elements. Respect reduced-motion preferences.
Check slider first slides
A hero slider may hide its first image until JavaScript completes.
It can also request several hidden slides with competing priority.
Render the initial slide directly and deprioritise noninitial media appropriately.
Check text-based LCP
A large heading or paragraph can become the LCP element.
Its timing depends on server delivery, CSS, fonts, and visibility.
Image compression cannot improve a text-based candidate.
Check web font timing
Invisible text can delay a large heading until its font arrives.
Many weights and remote origins add competition and connection work.
Use suitable display strategy, subsets, caching, and fallback families.
Avoid broad font preloading
Preloading every font forces downloads before the browser confirms need.
Those requests can compete with an image LCP resource.
Preload only verified critical files and include correct cross-origin handling.
Check consent interfaces
A large consent panel can become an LCP candidate itself.
Its scripts and styles can also delay underlying content rendering.
Test accepted, rejected, and undecided states separately.
Check responsive visibility
Some designs render separate desktop and mobile heroes simultaneously.
Hidden copies can still download and compete for network capacity.
Prefer one responsive source when practical. Verify hidden resource behaviour.
Check optimisation plugins
Automatic lazy loading, CSS delay, and script delay can affect LCP differently.
A setting name cannot prove the resource sequence improved.
Compare waterfalls and LCP subparts before and after each change.
Test cold browser caches
Warm caches can conceal large fonts, styles, scripts, and media transfers.
First visits often reveal the most contested critical path.
Record repeat visits too. Field data contains both experiences.
Test realistic network and processing
Fast development machines hide transfer competition and main-thread delays.
Use repeatable mobile conditions for laboratory comparisons.
Validate direction with real-user field data after deployment.
Compare identical runs carefully
Server, network, and browser scheduling create normal timing variation.
Run several tests and compare distributions or medians.
Keep viewport, throttling, cache, consent, and content constant.
Fix the dominant subpart first
A huge server delay makes tiny image refinements secondary.
Late discovery makes additional compression only a partial answer.
Prioritise the largest verified delay with the broadest visitor impact.
Retest other Web Vitals
Priority changes can increase competition for scripts or other media.
CSS changes can create layout shifts or broken interactions.
Repeat LCP, INP, CLS, accessibility, and functional journeys.
Monitor field LCP after deployment
Laboratory improvement is early evidence, not the final visitor result.
Record deployment dates and watch representative URL groups.
Allow time for field reporting periods while checking immediate regressions.
Remove redirect delays
Redirects postpone the final HTML request and every dependent resource discovery.
Test canonical addresses, campaign links, language routing, and protocol redirects.
Keep necessary chains short. Update internal links to final destinations.
Check HTML element order
Earlier discoverable resources usually enter browser scheduling sooner.
Complex headers can place critical post media surprisingly late in HTML.
Do not reorder content purely for speed. Preserve meaning and accessibility.
Use preconnect only when justified
A preconnect can establish an important remote origin connection earlier.
Unused connections consume resources and provide no LCP benefit.
Apply it to verified critical origins and measure the resulting waterfall.
Reduce priority competition
Large fonts, early images, styles, and scripts compete for constrained bandwidth.
Marking everything important does not create additional network capacity.
Deprioritise verified noncritical media and remove unnecessary early requests.
Preserve LCP image dimensions
Correct dimensions reserve space before the critical image finishes loading.
They also support WordPress loading optimisation decisions.
Wrong ratios can create CLS while LCP timing appears improved.
Review asynchronous decoding
WordPress can add asynchronous decoding to image output.
Decoding behaviour interacts with image size, browser scheduling, and display timing.
Do not override it without measured evidence from the target image.
Verify CDN transformations
An image CDN may rewrite URLs, formats, sizes, and quality.
Confirm its chosen candidate matches the visible slot and device density.
Test cache misses too. Transformation latency can affect first requests.
Verify preload matching
A preload helps only when the page later requests the same resource.
Responsive selection, credentials, and content type can prevent reuse.
Look for duplicate requests or unused-preload warnings after implementation.
Set durable asset caching
Versioned images, fonts, styles, and scripts can use effective browser caching.
Repeat visits then avoid transferring unchanged critical resources.
Use reliable version changes when asset contents change.
Verify editor and frontend differences
The block editor does not reproduce public caching or asset sequencing.
Its viewport and wrapper styles can also change the largest visible element.
Use previews for content review, then measure the anonymous frontend.
Know when image work loses
Image compression cannot repair dominant server delay or hidden-element rendering.
It also cannot help when large text controls LCP.
This is the honest weak case. Optimise the measured candidate and subpart.
Use the WordPress LCP checklist
- Review field LCP.
- Select representative templates.
- Record the public page.
- Identify the actual LCP element.
- Measure all four subparts.
- Check server response time.
- Check page caching.
- Expose critical resources early.
- Remove LCP lazy loading.
- Set priority selectively.
- Verify responsive candidates.
- Reduce delivered bytes.
- Remove render delays.
- Repeat controlled tests.
- Retest every vital.
- Monitor field results.
Frequently asked questions
What is a good LCP score?
Google defines good LCP as 2.5 seconds or faster for most visits.
Should the WordPress hero image be lazy-loaded?
No, when it is the likely in-viewport LCP image.
Should every visible image use high fetch priority?
No. Reserve high priority for one or very few verified critical resources.
Can a heading become the LCP element?
Yes. Large text blocks can become LCP candidates on some viewports.
Does image compression always improve LCP?
No. Server, discovery, or render delays may dominate the metric.
The verdict
Core image output includes useful loading optimisation. Verify the final response. Then compare the $299 lifetime suite when several Pro blocks meet your measured LCP budget.
Leave a Reply