I Tested Three Sites I Built. The Slow Part Wasn’t the Images.
On a simulated phone, 70 to 90 percent of the wait for the main content was render delay. Here is the one table that tells you what to fix first.
This morning I ran three websites I built through Google’s Lighthouse test on a simulated phone. All three missed the main loading target. None of them missed it because an image was slow to download.
That surprised me a little. When a client tells me their site feels slow, the first thing most people reach for is image compression. I have done it too.
On these three sites, compressing every image would have changed almost nothing. The time was going somewhere else. Lighthouse even tells you where, in a small table most people scroll past.
Here is what I found, what it means, and how to check your own site in about ten minutes.
What I tested, and how
The three sites are pinn.media (my studio), jnaikcreates.solutions (my personal site), and PrintVision, a printing company site we rebuilt in Next.js. All three are modern builds. None is an old WordPress theme with twenty plugins.
I used Lighthouse 12.8.2 with its default mobile settings on Tuesday, November 3, 2026, between 8:19 and 8:27 AM CT. That setup simulates a mid-range phone on a slow 4G connection. I ran each site twice and report both runs where they differ.
The number I care about is Largest Contentful Paint, or LCP. It is the moment the biggest piece of text or image in the first screen appears. Google’s guidance says a good LCP is 2.5 seconds or less.
One honest warning before the numbers. Lighthouse is a lab test. It runs one simulated load, and the results move between runs. Google ranks on real-visitor data, not on this. I wrote about that split in my plain-English guide to Core Web Vitals. The lab is still the best tool for finding out why a page is slow.
The table most people scroll past
Every Lighthouse and PageSpeed Insights report names your LCP element. That is the exact thing on the page that counted as “largest.” Under it sits a breakdown of where the time went.
Google’s web.dev guide splits LCP into four parts:
- Time to first byte. How long the server takes to start sending the page.
- Load delay. The gap before the browser starts fetching the LCP image, if there is one.
- Load time. How long that image takes to download.
- Render delay. The time between “ready to show” and “actually shown.”
The guide suggests that on a healthy page each “delay” part stays under about 10 percent of the total. It calls those splits guidelines, not strict rules.
Image compression only helps the third part. If your time sits in the fourth part, you are fixing the wrong thing.
Here is what my three sites looked like.
Render delay took 90 percent of LCP on pinn.media, 84 to 85 percent on jnaikcreates.solutions, and 70 to 86 percent on PrintVision. The image download on PrintVision took 12 percent in the first run.
So the content was ready. The browser just wasn’t showing it yet. Something was holding it back.
Site one: my studio site was showing a loading screen
On pinn.media, the LCP element was not my headline. It was the cookie banner text: “We use cookies to keep the site, chat and booking working…”
That told me the banner was the biggest thing on the first screen by the time the page settled. It also told me the banner appears late, at about 7 seconds in the simulation.
Then I looked at the HTML the server sends. The headline is not in it. The cookie banner is not in it. What is in it is a loading screen that says “Operating system loading.”
The site is built like a small desktop you can click around in. It is fun. But everything a visitor reads gets drawn by JavaScript after the page arrives.
The quickest way to see this is to turn JavaScript off and reload. Chrome DevTools has a built-in command for it. With JavaScript off, pinn.media never gets past the loader.
Google’s guide describes this exact case. If the LCP element is hidden until JavaScript finishes, a smaller image just moves the wait into render delay. The page still appears at the same time.
I wrote about a cousin of this problem in our post on animation and performance. A hero that fades in from invisible doesn’t count for LCP until it is visible. A loader in front of the hero does the same thing, only harder.
Site two: the text was there, the browser was busy
My personal site is a better-behaved case. The LCP element was a small header line, “Multidisciplinary creative technologist.” That text is in the HTML the server sends.
So why did it take 4.7 seconds to show? Because the browser’s main thread was busy running JavaScript. Total blocking time, which measures how long the page is too busy to respond, was 1,070 ms in one run and 1,630 ms in the other.
The home page has a split-flap board that types out my intro, plus a cookie banner that covers half the screen on a phone. Both are JavaScript.
Get Jawad Farooq Naik’s stories in your inbox
Join Medium for free to get updates from this writer.
When I blocked JavaScript and ran Lighthouse again, LCP dropped from 4.7 seconds to 2.2 seconds. Same text, same server. The only change was the scripts.
That is a clean test. If removing JavaScript cuts your LCP in half, your images are not the story.
I’m not saying ship a site with no JavaScript. The board is the point of the page. I’m saying the headline shouldn’t wait for it.
What clicking “Accept all” costs
This part I didn’t expect.
By default, Lighthouse clears storage before each run. So it always tests a visitor who hasn’t answered the cookie banner. That visitor never loads most of the analytics and ad tags. My personal site waits for consent before it loads any. On pinn.media, everything except Meta’s pixel script waits.
So I saved “accepted” in the browser, cleared the cache, and ran Lighthouse again with storage reset turned off. That is the experience of someone who taps “Accept all” and comes back the next day.
- jnaikcreates.solutions: LCP went from 4.7 seconds to 7.4 and 8.0 seconds. Page weight went from 640 KiB to 838 KiB.
- pinn.media: LCP went from 7.0 seconds to 11.6 and 11.8 seconds. Page weight went from 804 KiB to 1,228 KiB.
After consent, pinn.media loaded Google Tag Manager and Google’s tag (about 302 KB together), Meta’s pixel and its settings file (about 208 KB) and Microsoft Clarity (about 28 KB). My personal site added Google’s tag (about 177 KB) and Clarity.
These are simulated numbers, and a real phone will land somewhere different. But the direction is clear. The visitors who said yes to tracking got a slower site than the ones who said no.
If you only test the default report, you never see this. And a lot of your real visitors are probably in the “accepted” group.
Site three: the one where the image mattered a bit
PrintVision is the only one of the three where the LCP element was an image. It was the company emblem, a 121 KB PNG.
Lighthouse flagged that the file is 700 by 689 pixels but shows at about 104 pixels wide on a phone. A properly sized version would be a fraction of the size. That is real, and I will fix it.
But even here, the download was the small part. Load time was 728 ms. Render delay was 4.2 seconds in the first run and 5.0 seconds in the second.
I also found something I need to own. Our PrintVision case study says the plant video is compressed to 7.4 MB, every video is poster first, and playback is deferred until scroll.
The compression is true. The file is 7.8 million bytes, which is 7.4 MB. I didn’t test when it plays. I tested when it downloads. When I loaded the home page in Chrome at phone size and didn’t scroll at all, the whole file arrived within ten seconds.
My best guess at the cause is one attribute. One of the two video players on the page is set to autoplay, with preload set to none. MDN’s video reference says the autoplay attribute takes precedence over preload. So that “don’t preload” setting likely does nothing.
That is 7.4 MB of someone’s data plan before they have read a word. It is also bandwidth the rest of the page has to share. I’m changing it so the video loads only after the page has shown its content. Then I’ll make sure the case study matches what the site does.
How to check your own site in ten minutes
You don’t need to be a developer for most of this.
- Run your home page through PageSpeed Insights on mobile. Find the LCP element. Ask whether it is what you expected. A cookie banner or a tiny header line is a clue.
- Read the LCP breakdown. If load time is the big part, image work will pay off. If render delay is the big part, keep going.
- Turn JavaScript off and reload. In Chrome DevTools, open the Command Menu, type “javascript” and pick Disable JavaScript. If your headline or main image disappears, that is your render delay.
- Test as a visitor who accepted cookies. Accept the banner, then run Lighthouse in DevTools with “Clear storage” unchecked. Compare LCP and page weight with the first run.
- Check for autoplay video. Load the page, don’t scroll, and watch the Network tab in DevTools for video files. If one downloads, check whether it has autoplay.
- Then look at real data. The Core Web Vitals report in Search Console shows what visitors actually got. Small sites often see “No data available,” because the report relies on Chrome data that only covers pages and sites with enough visitors. That is normal. Use the lab to find causes in the meantime.
What I’m changing on my own sites
Here is my list, in the order I’ll do it.
Put the words in the HTML. On pinn.media, the headline and the cookie banner text should arrive with the page, not after a loader. The desktop can still boot. It just shouldn’t stand in front of the first sentence.
Make the cookie banner smaller on phones. On my personal site, it covers half the first screen. A banner that big becomes the main content, which is the opposite of what a banner should be.
Load tags later. Both sites are built with Next.js. Its Script component has a lazyOnload setting that loads a script during browser idle time. Analytics can wait a few seconds. Your visitor shouldn’t. The same idea works on any platform. Web.dev has a solid guide on loading third-party scripts efficiently.
Stop autoplay from fetching the whole video. On PrintVision, show the poster image first and start the video after the page has painted.
Size the emblem. Serve it near the size it is shown, in a modern format.
I’ll rerun the same tests after the changes and keep the numbers honest either way.
The lesson for me is simple. Before you compress anything, read the one line that says where the time went. On my sites, it pointed at code I wrote, not at the photos.
If you’d like a second pair of eyes on your own LCP breakdown, Pinn.Media does short discovery calls. Book one here and bring your PageSpeed link.
