Engrain by ByteRush

QLT.01.02 Mid-level· 11 minCore — asked often

Optimizing LCP: find which part of the wait is slow

Split Largest Contentful Paint into its four sub-parts (TTFB, resource load delay, load duration, render delay), then apply the matching fix: faster servers and CDNs, discoverable and high-priority LCP images, smaller files, and fewer render-blocking resources.

Comes up in: Web fundamentals, Frontend system design

Learn#

Anita’s travel home page has an LCP of 4.1 seconds. Her team compresses the hero image twice, and LCP barely moves. The image was never the slow part; it was found late.

The LCP element is the largest image or text block in the viewport. Its time splits into four parts, and each has its own fix:

  1. TTFB: the server’s first byte. Fix with caching, a CDN, less server work.
  2. Resource load delay: from TTFB until the image request starts. Fix by making the image discoverable in the HTML and high priority.
  3. Load duration: downloading the file. Fix with smaller, modern formats and the right size (WEB.10.01).
  4. Render delay: from download to paint. Fix render-blocking CSS, fonts and scripts.
<!-- The LCP image: in the HTML, eager, high priority, sized for the device -->
<img src="hero-800.avif" srcset="hero-480.avif 480w, hero-800.avif 800w, hero-1200.avif 1200w"
     sizes="100vw" width="1200" height="600" fetchpriority="high" alt="Backwaters at sunset">
Breaking a 4.1 s LCP into its partsStep 1 of 4

State

  • TTFB 600 ms

LCP is 4.1 s. Step 1: TTFB 600 ms, the server's response time.

Read the steps as text
  1. LCP is 4.1 s. Step 1: TTFB 600 ms, the server's response time.
  2. Step 2: the hero image request starts only at 2,300 ms: resource load delay 1,700 ms. It is set as a CSS background, found late.
  3. Step 3: downloading the 900 KB JPEG takes 1,500 ms (load duration).
  4. Step 4: render delay 300 ms waiting for CSS. Fix the biggest part first: an <img> with fetchpriority="high" in the HTML, then AVIF and srcset.

Predict#

Predict first

The hero image is rendered by a React component after the JavaScript bundle loads (client-side rendering). Which LCP sub-part suffers most?

Interview angle#

Say it like this — about 30 seconds

“I first find the LCP element and split its time into TTFB, resource load delay, load duration and render delay, using DevTools or the web-vitals attribution build. For an image-heavy homepage the usual fixes are: put the hero image in the HTML as an img, never lazy-load it, give it fetchpriority high, serve AVIF or WebP at the right size with srcset, and serve it from a CDN. Then I cut render-blocking CSS and fonts, and improve TTFB with caching and server rendering of the hero.”

Stays on your device. Nothing is uploaded.
Follow-up How would you improve LCP on an image-heavy homepage?
Make the hero discoverable in HTML, fetchpriority=“high”, no lazy loading, modern formats with srcset, CDN delivery, fewer render-blocking resources.
Follow-up Why is a CSS background image a bad LCP element?
The browser finds it only after downloading and parsing the CSS, adding load delay; preload it or use an img.
Follow-up How do you find the LCP element in the field?
The web-vitals library’s attribution build reports the element and its sub-part timings.

Practice#

Guided

Split an LCP time into its four sub-parts and name the biggest one.

Done when

  • Image LCP times split into TTFB, load delay, load duration and render delay.
  • Text LCP elements have no resource parts.
  • The worst part is named, with ties going to the earlier part.
Your solution
Ctrl/⌘ + Enter

Remember#

Try to answer each card before you open it. Then add them to your reviews.

Name the four LCP sub-parts.

TTFB, resource load delay, resource load duration, element render delay.

Should the LCP image use loading="lazy"?

No. It delays the most important image.

Which attribute raises the LCP image's network priority?

fetchpriority="high".

Why do client-rendered heroes have poor LCP?

The image is found only after JavaScript runs, adding load delay.

Go deeper

Four layers. Stop at the one your interview needs; each ends with a quick check.

The core ideaEvery round

In a healthy page, most LCP time is TTFB and the download itself; load delay and render delay should be close to zero. Large delays point at discovery and blocking problems.

Check yourself: Which sub-part should usually be the largest in a good LCP?

Load duration and TTFB; load delay and render delay should be small.

How it works underneathSenior rounds
Browsers start images at low priority until layout shows they are in the viewport. fetchpriority="high" raises the LCP image at once: Chrome 102, Firefox 132, Safari 17.2 .
Lazy loading waits for layout, adding delay.
Check yourself: Why does fetchpriority=&quot;high&quot; help even when the image is in the HTML?

Images start at low priority; the hint raises it above other images and scripts.

Edge cases and trapsWhere people slip
Render delay comes from blocking CSS and fonts: text set in a loading font may be invisible (WEB.01.05). Inline critical CSS and use font-display.
Server rendering puts the LCP element in the HTML; client rendering adds JavaScript download and run time first.
Check yourself: How do web fonts delay a text LCP?

Text using a loading web font may be hidden until the font arrives.

In productionStaff-level answers
Cache HTML at the CDN where possible, and use 103 Early Hints for the hero (WEB.01.05). Track LCP sub-parts in the field to see whether fixes worked .
Check yourself: How can a CDN help both TTFB and load duration?

It serves cached HTML and images from servers near the user.

Finished the five steps? Mark it, and its cards join your reviews.

Last checked 2026-11-01. Spot a mistake? Use “Report an error” below — fixes are listed on the corrections page.

Interview questions this answers

  • How would you improve LCP on an image-heavy homepage?