You ran your site through PageSpeed Insights, got a wall of red, and closed the tab. Reasonable response. The report is written for developers, uses three acronyms nobody explained, and offers advice like “reduce unused JavaScript” as though you personally wrote it.
Here is the same information without the jargon — and, more usefully, an explanation of why most of what you are looking at was decided by your theme rather than by anything you did.
The three numbers, in plain language
Google measures three things. They are not abstract technical scores; each one corresponds to a moment a real visitor experiences.
LCP — Largest Contentful Paint. How long until the main thing on the page shows up. Not the first pixel, not the technical “load complete” event — the moment your headline or hero image is actually visible. <cite index=”1-1″>Good is under 2.5 seconds.</cite>
INP — Interaction to Next Paint. Someone taps a button. How long before the page visibly responds? This covers every interaction on the page, not just the first one — opening a menu, applying a filter, expanding an accordion. <cite index=”1-1″>Good is under 200 milliseconds.</cite>
CLS — Cumulative Layout Shift. How much the page jumps around while it loads. This is the one where you go to tap something, an image finishes loading above it, and everything slides down. <cite index=”1-1″>Good is under 0.1.</cite>
<cite index=”6-1″>If you find an article listing something called First Input Delay, it is out of date — INP replaced it as the official responsiveness metric back in March 2024.</cite>
The part almost nobody explains
Two details change how you should read your score, and both are routinely skipped.
First: you are graded on real visitors, not on your test. <cite index=”3-1″>Google scores these metrics using field data from actual Chrome users, collected at the 75th percentile over a 28-day rolling window.</cite> A clean result in a lab tool is encouraging, but it is a simulation on one connection. <cite index=”3-1″>You pass a metric only when at least 75% of real page views hit the good threshold.</cite>
This is why “but it’s fast on my laptop” is not a defence. Your laptop is not the 75th percentile. A mid-range phone on average mobile data is much closer to it.
Second: fixes take weeks to show up. <cite index=”3-1″>Because the data rolls over a 28-day window, you need to allow several weeks after deploying a change before judging whether it worked.</cite> If you fix something on Monday and check on Wednesday, you have learned nothing. This trips up a lot of site owners into thinking a genuine improvement failed.
Why your theme owns most of your score
Now the actual point. You can write perfect content and still fail all three, because each metric is dominated by structural decisions made before you ever touched the site.
Your theme decides LCP
The largest visible element is almost always a hero image or headline, and the theme controls how it gets delivered. Is the hero image preloaded, or discovered late after the browser has parsed stylesheets? Is it served in a modern format at a size appropriate for a phone, or is a 2400px desktop image being downloaded and scaled down? Do the theme’s fonts block rendering while they download?
There is also a queuing problem. Your headline cannot paint until the browser has worked through the resources ahead of it. A theme that loads an animation library, an icon font, a slider script, and four font weights on every page has put four things in front of your headline in the queue — on pages that use none of them.
Your theme decides CLS
<cite index=”4-1″>Layout shift is largely solved by explicit dimensions: every image, video, iframe, and ad slot needs declared width and height so the browser can reserve the space before the content arrives.</cite> That declaration happens in template code. It is not something you can add while writing a blog post.
The other common source is fonts. A theme loads a custom font, and until it arrives the browser shows a fallback. When the real font swaps in, letter widths change, text reflows, and everything below moves. Handled well, this is invisible. Handled carelessly, it is a visible lurch on every page load.
<cite index=”4-1″>CLS is generally the easiest of the three to pass, which cuts both ways — if you are failing it, the theme is doing something avoidable.</cite>
Your theme decides INP — and this is the hard one
<cite index=”6-1″>INP is the metric most sites fail, and it is the hardest to fix, because LCP problems are usually about resources and CLS problems are usually about missing dimensions, but INP problems are about JavaScript architecture.</cite> You cannot compress your way out of it or add an attribute. Someone has to change how the code handles interactions.
Which means, in practice, that INP is not yours to fix. If your theme’s mobile menu runs heavy JavaScript on every tap, or its filtering logic blocks the main thread while it re-sorts a product list, that is the theme author’s code and the theme author’s decision. Your options are to ask them to fix it, hire someone to rewrite it, or change themes.
This is worth internalising before your next theme purchase: you are not buying a look. You are inheriting an engineering approach to the metric that is hardest to change later.
What you can actually do
If you already have the site:
- Get your real numbers, not lab numbers. Google Search Console has a Core Web Vitals report drawn from field data. That is your scoreboard.
- <cite index=”3-1″>Fix whichever metric is in the “poor” band first. After that, the sensible order is INP, then LCP, then CLS — and do not spend time optimising a metric that is already green.</cite>
- Audit what your theme loads that you do not use. Sliders, portfolio modules, unused font weights, an icon library for three icons. This is often the single biggest win available without touching code.
- Compress and correctly size your images. This is genuinely yours to control, and it moves LCP.
- Count your third-party scripts. Chat widgets, review embeds, heatmaps, multiple analytics tags — each one competes with your content, and INP suffers most.
If you are choosing a theme:
Run the theme’s own demo through PageSpeed Insights on mobile before you buy — and test a busy page, not the marketing homepage. That number is your ceiling. Everything you add afterwards, from your content to your plugins, only pushes it down.
The takeaway
Core Web Vitals are often presented as an SEO chore, which makes them easy to postpone. They are better understood as a measurement of something you already care about: whether your site feels fast, stable, and responsive to a real person on a real phone.
And the honest answer to “why is my score bad?” is usually not that you did something wrong. It is that a decision was made for you, by a theme author optimising a demo page, long before your first visitor arrived.
At eThemeStudio, we publish the field performance of our themes rather than a curated Lighthouse screenshot, and we treat INP as a design constraint rather than an afterthought. If your Search Console report is showing red and you are not sure whether it is your theme or your content, send it over — we will tell you which.
Comments (0)