Four things decide when the main thing on your page finally shows up. How fast your server answers, how long the browser waits before it starts fetching your biggest image, how long that image takes to download, and how long the page takes to paint it. Fix them in that order. Google’s own data on already slow sites says the download is rarely the slow part, even though it is the part most people go after first.
The four parts of one number
Google measures load speed with a single number. It is called Largest Contentful Paint, or LCP. It marks the moment the biggest thing on the screen finishes showing up. Google says that biggest thing is either an image or a block of text. On a plumbing or roofing site that means the hero photo or the headline.
That one number splits into four parts. The web.dev page “Optimize Largest Contentful Paint”, published April 30, 2020 and last updated March 31, 2025, names them:
- Time to first byte. How long your server takes to send the first scrap of the page.
- Resource load delay. The gap between that first scrap and the moment the browser starts downloading the main image.
- Resource load duration. The download itself.
- Element render delay. The gap between the download finishing and the picture actually appearing.
Every millisecond of your load time lands in one of those four buckets. Nothing else. That is why the order matters. Shrink an image that was never the problem and the number barely moves.
The bar is 2.5 seconds, and phones miss it more
The web.dev page “Largest Contentful Paint (LCP)”, published August 8, 2019 and last updated September 4, 2025, sets the target. Sites “should strive to have Largest Contentful Paint of 2.5 seconds or less.” It says to judge that at the 75th percentile of page loads, counted separately for phone and desktop. In plain words, three out of four visits should come in under 2.5 seconds.
Plenty of sites do not get there. The Performance chapter of the Web Almanac 2025, from HTTP Archive, published January 15, 2026 and last updated May 5, 2026, reports 74% of desktop pages hitting a good LCP against 62% on mobile. Mobile also had close to double the rate of poor scores, 13% against 7%. Those figures come from real Chrome users in July 2025.
Your customer is on the phone side of that split, standing in a wet basement.
The download is rarely the slow part
The optimize-lcp page gives a target split for a well tuned page. Roughly 40% time to first byte, roughly 40% download, and under 10% each for the two delays.
Read the fine print on that. Google introduces it as “the ideal breakdown of these subparts is on a well-optimized page”, then adds that the breakdowns “are guidelines, not strict rules.” It is a target for a good page, not a description of yours. Do not assume your site splits that way. Measure it.
Slow sites look nothing like the target. A web.dev article by Brendan Kenny, “Common misconceptions about how to optimize LCP”, last updated August 20, 2024, checked real sites with poor LCP and found this. “The majority of origins with poor LCP spend less than 10% of their p75 LCP time downloading the LCP image.” And this. “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.”
Four times as long waiting as downloading. That is the whole article in one line.
Fix the server first, then the wait, then the picture
Start with time to first byte. The web.dev page “Time to First Byte (TTFB)”, published October 26, 2021 and last updated November 18, 2025, says “most sites should strive to have a TTFB of 0.8 seconds or less.” Kenny’s article gives the ugly version. For at least half the sites with poor LCP, the 75th percentile time to first byte is 2,270 milliseconds. That is 2.27 seconds gone before a single image starts, against a 2.5 second budget for the whole thing.
Time to first byte is mostly your host, plus how much work the page has to do before it can answer at all, though moving that host closer to your town does less than people expect. A page that gets assembled fresh on every visit does that work while the visitor waits, and a heatwave week that sends everyone at once is when that line gets long. A page that was already built and is sitting there as a finished file does not. That is how a site gets built here.
Next comes resource load delay. That is dead time where the browser has your HTML but has not started on your photo yet. Google’s list of causes is short. The picture gets put on the page by a script, or it is set to load lazily, or it is a background image named in a stylesheet. In all three the browser cannot find the picture by reading the page source, so it does not start fetching. Google’s rule is that your main image should be findable in the page source.
Chrome will show you all four parts. The optimize-lcp page says Chrome DevTools and Lighthouse both measure these subparts for you, so you do not have to work them out by hand. The same page is blunt about which parts to hunt first. Spend a lot of unnecessary time in either of the delay portions, it says, and “it will be very difficult to constantly hit the 2.5 second target.” The delays are the cheap wins.
Only then the picture itself. A photo straight off a phone is far bigger than any page needs, and that part is real. Job photos are the usual offender.
Element render delay is last. That is the gap after the file has landed and before you can see it. On a well tuned page Google puts it under 10% of the total.
What faster will not do for you
Speed is a floor, not a lever. If your page already paints in about two seconds on a phone, speed is not the thing holding you back, and a rebuild sold on speed grounds alone is not the work you need. Nobody can tell you what a faster page will do to your call count, and nobody honest will try. What this article can tell you is which of the four parts is eating your load time. That is the whole of it.
Two limits on the evidence above. The 40/40/10/10 split is Google’s target for a good page, not a measurement of your page. And the field numbers, both the Web Almanac figures and Kenny’s, come from sites with enough traffic to appear in Google’s real user data. A small local site often has none, and the report will say so. Here is why PageSpeed Insights shows you no real user data.
There are no client case studies to show you here. The only score this company will point at is its own site, which scored 100 on Google’s PageSpeed test, desktop and mobile, when it launched in August 2026. A fast site also cannot fix a phone nobody answers, and how fast a web lead gets called back is a separate question worth answering first.
What to do next
Work down this list and stop as soon as your number is under 2.5 seconds.
- Run your busiest page through Google’s PageSpeed Insights on mobile. Write down the LCP.
- Open that page in Chrome, press F12, go to the Performance panel and record a reload. It will show you which of the four parts is eating your time.
- If time to first byte is over 0.8 seconds, that is your job. Everything else is second.
- If the wait before the image is the biggest slice, find what the browser is fetching first and get it out of the way.
- Only after those two are handled, resize the photo.
Do that and you will know which part of your load is slow instead of guessing. If you would rather hand the job over, the monthly plans are laid out on the pricing page.