Website Slow? Fixing LCP, Render-Blocking JS and Core Web Vitals

What the three metrics measure (and their targets)

Each vitals metric has a defined good threshold at the 75th percentile of real page loads, so you are aiming for most of your users, not the best case:

LCP is the one most people mean by "slow", and its usual culprit is a big hero image or a render-blocking resource in front of it.

Lab data vs field data: why your two numbers disagree

Lab data is a single simulated run on your machine (Lighthouse, or an on-the-spot test); field data is the aggregated 75th-percentile of real visitors over weeks (Chrome UX Report). They disagree because your laptop on good Wi-Fi is not your worst mobile user on 3G.

Optimise against field data for the real user experience and use lab data to reproduce and debug a specific problem on your own connection. A fast lab score that ignores a slow field LCP is false confidence, so trust the percentile-of-users view when deciding what to fix.

Fix #1: the image behind your LCP

The largest element is very often a hero image, and the fixes are unglamorous and high-impact. Resize it to the size actually displayed - a 2400 px-wide photo shown in an 800 px slot wastes most of its bytes - compress it, and use modern formats where supported.

Shrink it with the image compressor, set exact dimensions with the resizer, and convert to WebP with the converter for roughly 25-35% smaller files at similar quality. Always reserve space with width/height or aspect-ratio so a late-loading image cannot cause CLS, and lazy-load anything below the fold while leaving the LCP image eager.

Fix #2: render-blocking JavaScript and CSS

The browser pauses rendering to fetch and run scripts and stylesheets in the head, so one large blocking file can dominate LCP. Trim the payload first - minify JavaScript with the JS minifier and stylesheets with the CSS minifier to strip whitespace and comments - then defer what is not needed for first paint by loading it with defer/async or dynamically.

Inline only genuinely critical above-the-fold CSS and load the rest non-blocking. Shipping smaller, fewer blocking files is a bigger lever than micro-optimising cache settings on files that should not be blocking at all.

Fix #3: the server and caching layer

If TTFB is high, nothing downstream can make the page feel fast, so fix backend latency before assets: enable caching and compression (gzip/Brotli), serve repeat visits from cache with sensible cache headers, and use a CDN to move content closer to users.

A fast first check here is the response-time checker, but be honest about what it measures: it times a single request from your own browser to a URL and bands that round-trip into a simple response score. That is a real, useful signal about server reachability and latency, but it is not Lighthouse - it does not compute LCP, INP or CLS, and one sample from your location is not the 75th-percentile field experience of your users.

The order to work in

Fix the biggest bottleneck first: look at what element is your LCP, resize and compress that image, remove render-blocking JS and CSS in front of it, then address server TTFB and caching. Each step is measurable, so change one thing, re-test against field data, and move on rather than applying twenty tweaks at once and not knowing which helped.

For the asset sizes themselves, the image-compression guide walks through hitting specific size targets, which pairs directly with the LCP fix above.