Core Web Vitals: Fix Slow Pages, Keep Rankings

Almost every website owner in Malaysia has, at some point, been sent a red PageSpeed score by someone trying to sell them a rebuild. The score looks alarming. The pitch writes itself. And often the money gets spent on the wrong problem entirely.

Core Web Vitals are real, and Google says plainly that they are used by its ranking systems. What gets lost is the second half of the same sentence: a good score does not guarantee rankings, and chasing a perfect one purely for SEO may not be the best use of your time. Those are Google’s words, not ours.

So the useful question is not “how do I score 100?” It is “is speed the thing costing me traffic, and if it is, which fixes earn back the most for the least effort?” This piece answers both, using Chrome’s own published field data rather than the usual list of tips. The video below is the Chrome team showing where these numbers come from.

PART 1 · DIAGNOSE

What Core Web Vitals Measure, and What Google Actually Says

IN BRIEFCore Web Vitals are three field metrics, loading, responsiveness and visual stability, measured on real visits, not on a test machine. Google says they are used by its ranking systems, but that good scores do not guarantee top positions. Treat them as one input to a wider SEO plan, not the plan itself.

The three metrics answer three different complaints a visitor might have. Largest Contentful Paint asks how long before the biggest thing on screen shows up. Interaction to Next Paint asks how long the page takes to visibly respond after someone taps. Cumulative Layout Shift asks how much the page moves under their thumb while it settles.

Two details change how you should read any report you are shown:

• The scores come from real visitors. Google’s assessment uses field data at the 75th percentile, split by mobile and desktop. A fast test on your office fibre line is not the number that counts.
• There is no single “page experience signal”. Google’s own page experience documentation states this directly, and adds that ranking systems still surface the most relevant content even when the experience is sub-par.

That second point is the one agencies quietly skip. Speed is a tie-breaker among pages that are already competitive. It is not a substitute for being the best answer to the query.

BENCHMARK BRIEFING 1 OF 4

The Three Metrics, Their Targets and Their Usual Culprits

IN BRIEFA page passes only when all three metrics sit inside their thresholds for most real visits. The targets are published and fixed; what varies is which part of your site breaks them. On small Malaysian sites the culprit is usually the theme, the hero image or a plugin, rarely the hosting alone. Our technical SEO basics guide covers the groundwork underneath.

PART 2 · DIAGNOSE

Is Speed Really Why You Lost Rankings?

IN BRIEFUsually not. Rankings fall for indexing, relevance or competitive reasons far more often than for speed. Speed work pays when your pages already appear on page one or two and visitors leave before reading. If your pages never appear at all, start with why your website isn’t ranking instead.

The honest test is a sequence, not a score. Ask, in order: is the page indexed, does it match what the searcher wants, does it compete on substance, and only then, does it load acceptably on a mid-range Android phone on mobile data?

Most sites we look at fail at step two or three. Speed becomes the visible symptom because it is the only thing with a number attached, so it takes the blame for a content problem.

BENCHMARK BRIEFING 2 OF 4

Where the Loading Time Actually Goes on Pages That Fail

IN BRIEFChrome’s published field analysis is blunt about this: slow pages are usually not slow because the image file is big. They are slow because the browser finds out about the image too late. That single insight redirects most speed budgets, and it belongs in every SEO audit checklist.

Two numbers in that guide do the real teaching. Chrome reports that most origins with poor loading times spend less than 10% of that time actually downloading the image, and that on failing pages the image start is delayed by about 1,290 milliseconds at the 75th percentile. The wait is queueing, not bandwidth.

PART 3 · DESIGN

Which Fixes Are Worth Paying For

IN BRIEFFour fixes carry most of the gain for a typical small business site: set image dimensions, put the main image in the HTML at high priority, cut unused scripts and tags, and serve through a CDN. None of them require a rebuild, which is why a rebuild quote deserves scrutiny before you sign a website design project.

The fixes worth buying share a shape: they are cheap, they are reversible, and they change how the browser finds work rather than how much work exists. In rough order of return:

1. Set width and height on every image. Two-thirds of pages have at least one unsized image. This is often an afternoon of work and it moves layout stability immediately.
2. Put the main image in the HTML and mark it high priority. Remove lazy loading from the top image, avoid loading it through a script, and let the browser start early.
3. Audit your tags and widgets. Live chat, heat maps, three analytics tools and a review popup compete for the same thread that answers taps.
4. Put the site behind a CDN. Only about a third of HTML documents are served this way, and Malaysian sites serving regional visitors gain the most.
5. Stop animating layout properties. Sliding banners that push content are a common, avoidable source of shift.

BENCHMARK BRIEFING 3 OF 4

Fix Effort Against Likely Metric Movement

IN BRIEFEffort and impact do not line up neatly. The cheapest fixes often move the most, while the expensive ones, new hosting, new framework, move the least per ringgit spent. Sequence by return, not by how impressive the work sounds in a proposal.

PART 4 · DEPLOY

How to Sequence the Work Without Breaking the Site

IN BRIEFChange one category at a time and wait for the field data to catch up. Google’s assessment uses a rolling 28-day window of real visits, so a fix made today shows up in reports weeks later. Rushing five changes at once means you learn nothing about which one worked.

A workable order for a small team:

• Week 1, measure and record. Note the current field figures for your top ten pages before touching anything.
• Week 2, the free wins. Image dimensions, main image priority, remove dead tags.
• Weeks 3 to 6, wait and read. Field data lags. Resist the urge to keep changing things.
• Weeks 7 to 10, infrastructure. CDN, caching, back/forward cache eligibility if the first round fell short.
• Week 12, decide. Either you are passing, or the platform itself is the constraint and a rebuild becomes a genuine option rather than a default one.

Keep a plain record of what changed and when. When the numbers move, that record is the only thing that tells you why.

BENCHMARK BRIEFING 4 OF 4

What a Twelve-Week Remediation Looks Like on Paper

IN BRIEFProgress is stepped, not smooth. The visible jump lands three to five weeks after the work, because the reporting window is a 28-day rolling average of real visits. Plan the reporting conversation around that lag so nobody panics in week three.

PART 5 · DRIVE

How to Know the Fix Actually Worked

IN BRIEFJudge the work on three things: the Search Console report moving URLs from poor to good, enquiries holding or rising, and nothing else breaking. A lab score improving on its own proves the test ran, not that customers had a better visit.

Set the success measure before the work begins, and keep it small:

• Field data, not lab data. The Search Console Core Web Vitals report is the scoreboard, because it reflects real visits.
• URL groups, not single pages. Google groups similar URLs; a fix to one template moves the whole group.
• A business number alongside it. Enquiries, calls or form fills for the affected pages. If those do not move at all, the speed problem was not the constraint, and that is worth knowing early.

Speed work is maintenance, not a project you finish. Every new plugin, tracking tag and campaign landing page can undo it, so a quarterly check is more useful than one heroic sprint.

THE VERDICT

What We Would Do in Your Position

Check whether you are competitive first. If your pages already earn impressions, spend a fortnight on the cheap fixes, image dimensions, image priority, tag cleanup, and give the field data six weeks to answer. That sequence costs very little and settles the argument with evidence.

If your pages are not appearing at all, put the speed budget aside. Nothing about Core Web Vitals will rescue a page that Google has not indexed or does not consider relevant. Deal with that first, then come back to milliseconds when they are the last thing standing between you and the click. More of this thinking sits on the IZI homepage and across our SEO work.

FAQ

Common Questions About Core Web Vitals

1. Do Core Web Vitals affect Google rankings in 2026?

Yes, Google confirms they are used by its ranking systems. It depends on how competitive your query is, where several pages answer equally well, experience can separate them. Google also states that good scores do not guarantee top positions, so treat them as a tie-breaker rather than a lever.

2. What is a good Core Web Vitals score?

A page passes when Largest Contentful Paint is within 2.5 seconds, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift stays below 0.1. It depends on real visitors, not test runs, the assessment uses the 75th percentile of actual page loads, split by mobile and desktop.

3. Why does PageSpeed Insights show a different score from Search Console?

Because they measure different things. The lab test simulates one load on a set configuration; Search Console reports what real visitors experienced over a rolling 28-day window. When the two disagree, the field data is the one Google uses, and the one worth acting on.

4. How long before Core Web Vitals fixes show up in Search Console?

Plan for three to five weeks. It depends on how much traffic the affected pages get. The report averages 28 days of real visits, so a low-traffic page takes longer to reflect a change than a busy one. Making several changes at once will hide which fix did the work.

5. Do I need to rebuild my website to pass Core Web Vitals?

Rarely. Most failures on small business sites trace to images without dimensions, a main image loaded by script, or too many third-party widgets, all fixable in place. A rebuild becomes reasonable only when the platform itself blocks the fixes, and that should be proven, not assumed.