Core Web Vitals Checklist for 2026: INP, LCP and CLS Fixes That Move Rankings

A Core Web Vitals checklist comes down to three numbers measured at the 75th percentile of your real visitors: Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Hit all three on mobile and on desktop and the page passes. Miss one and the page fails, however good the other two look.

The part most Dubai business owners get wrong is not the fixing. It is the measuring. Search Console reports on a 28 day window of real Chrome traffic, groups your URLs together, and shows nothing for sites below its sampling threshold. Every figure below was read from Google and Chrome documentation on 4 October 2026.

Key takeaways

• The passing marks are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, judged at the 75th percentile of page loads and split between mobile and desktop.
• Search Console’s numbers describe the last 28 days of field data, not the page you just loaded on your own laptop.
• Google states plainly that there is no single page experience signal, that Core Web Vitals are used by its ranking systems, and that good scores do not guarantee a top position.
• The Chrome User Experience Report only sees Chrome on desktop and Android. Chrome on iOS and every other browser are excluded, which in the UAE leaves a large share of real visits unmeasured.
• Roughly 40 percent of a typical LCP is server response time, so hosting and caching decisions usually move the number more than image tweaks do.
• Layout shifts within 500 milliseconds of a user interaction are not counted, which is why a menu opening is fine and an advert loading late is not.
• Search Console drops URLs into groups that share a template, so one bad page type can take a whole section down with it.

The three numbers and the thresholds you have to beat

Each metric has a good band, a needs improvement band, and a poor band. There is no partial credit: a page is assessed on the worst of the three.

INP became a stable Core Web Vital in 2024, taking over from First Input Delay. The difference matters: First Input Delay measured only the delay before the browser began handling the first interaction, which flattered sites that responded quickly and then did heavy work. INP measures through to the next paint, so a filter that takes two seconds to redraw a property list now shows up as the problem it always was.

How Google actually scores you, and why your own test does not count

Google assesses these metrics at “the 75th percentile of page loads, segmented across mobile and desktop devices”. Three quarters of your visitors have to get the good experience. The slowest quarter is allowed to be slow, which is deliberate: there will always be someone on a weak connection in a basement car park.

Search Console’s Core Web Vitals report describes each figure as the value where 75 percent of page requests took that amount of time or less in the last 28 days. Two consequences follow. A fix deployed today will not show fully for four weeks, because the window still contains the old numbers. And a page can carry a status on mobile that differs from its status on desktop, since the labels are applied per device type.

The report also groups URLs. Google puts pages with a similar experience together on the assumption that they share a framework and will fail for the same reasons. For a Dubai business that usually means all 300 product pages sit in one group, or every community guide on a brokerage site sits in another. One slow template drags the group, and fixing a single URL changes nothing on the report until the template changes.

Why your site may show no data at all

This is the question we field most often, and the answer rarely appears in the checklists that rank for this topic. Field data comes from the Chrome User Experience Report, which collects only from Chrome users who enable usage statistic reporting and sync their browser history. It covers desktop Chrome and Chrome on Android. It explicitly excludes Chrome on iOS and other Chromium browsers such as Microsoft Edge. Chrome does not publish what proportion of users meet those conditions.

There is also a popularity threshold. Google states that the exact number is not disclosed, but that it was chosen so there are enough samples to be confident in the distributions. A new clinic site in Jumeirah with 400 visits a month will often sit below it, and Search Console then shows “No data available”, which means the property is new or the data is too thin, not that the site is fast.

The UAE adds a twist worth knowing. StatCounter put mobile browser share in the United Arab Emirates for September 2026 at 69.39 percent Chrome and 22.14 percent Safari. Safari is not in the dataset at all. So for a typical Dubai site, roughly one in five mobile visits never reaches the field numbers Google judges you on, and those are often the higher-spending iPhone users. The practical response is not to distrust the data. It is to treat lab testing on an iPhone as a separate obligation rather than an optional extra.

Field data and lab data answer different questions

Field data tells you what happened to real people over 28 days, and it is the data Google ranks on. It cannot tell you which line of code is at fault, because it carries no stack trace.

Lab data from Lighthouse or Chrome DevTools tells you what happens on one simulated device, right now. It is repeatable, it points at specific resources, and it is the only way to test a page before launch. It also cannot fail a metric that depends on real interaction, which is why a page can score 100 in Lighthouse and still fail INP in the field.

Use field data to decide what to fix and lab data to work out how. Running it the other way round is how teams spend a sprint optimising a page nobody visits. Our SEO audit checklist for Dubai SMEs covers where this sits in a wider technical review.

LCP: four phases, and where the time actually goes

Google breaks LCP into four parts, with rough shares of the total: time to first byte at around 40 percent, resource load delay under 10 percent, resource load duration at around 40 percent, and element render delay under 10 percent.

Read that distribution again, because it decides your priorities. About 80 percent of a typical LCP is server response plus downloading the main image or heading. Compressing a hero photograph helps the second half. Nothing in your CSS helps the first. If the server takes 1.2 seconds to answer, a 2.5 second LCP is already most of the way gone before the browser has seen the page.

That is why hosting location is a real decision for UAE businesses rather than a preference, and we have written separately on when a local server is worth it. One issue we often see is a well built theme sitting on a shared host in another continent, where every visitor pays the round trip twice.

On the resource side, Google’s guidance is specific. The LCP image has to be discoverable in the initial HTML response by the browser’s preload scanner, so an image injected by JavaScript starts late by definition. Never put loading="lazy" on the LCP image, which is the single most common self inflicted wound we see on WordPress sites where a plugin lazy loads everything including the hero. Set fetchpriority="high" on the likely LCP image. Use <link rel="preload"> for resources referenced only inside external files, such as a background image declared in CSS.

CLS: the five things that move the page

Layout shift is the cheapest of the three to fix and the most visible to a customer who has just tapped the wrong button. Shifts that happen within 500 milliseconds of a user interaction are excluded, so an accordion opening does not count against you. Everything else does.

1. Images without dimensions. Put width and height attributes on every <img> tag, or set aspect-ratio in CSS, then allow responsive sizing with height: auto. Modern browsers derive the aspect ratio from those attributes and reserve the space before the file arrives.
2. Adverts, embeds and iframes. Reserve the box with min-height or aspect-ratio. A Google Maps embed on a restaurant contact page is the classic offender.
3. Content injected without the user asking for it. A newsletter bar or a cookie notice that pushes the page down after a second is a self inflicted shift. Either reserve space for it or load it as an overlay.
4. Web fonts. Switching from the fallback to the real font reflows the text. font-display: optional avoids the re-layout, and the size-adjust, ascent-override, descent-override and line-gap-override descriptors let a fallback match the web font’s metrics closely enough that the swap is invisible. This matters more on Arabic and English sites, where the two scripts rarely share metrics.
5. Pages that cannot use the back/forward cache. A page eligible for bfcache is restored instantly on a back navigation with no re-render and therefore no shift.

INP, and where to go deeper

INP is the hardest of the three to fix because it depends on your JavaScript rather than your assets, and because the culprit is usually an interaction on an inner page rather than anything on the home page. The short version: find the slow interaction in field data, reproduce it in DevTools, then work out whether the cost sits in input delay, processing, or presentation delay, because each phase has a different remedy.

We have covered that in detail in our guide to finding and fixing INP problems, including the patterns that break it on Dubai business sites. Rather than repeat it here, treat INP as the one metric that usually needs a developer and budget accordingly.

A checklist you can run in an afternoon

In order, because each step tells you whether the next one is worth doing.

1. Open the Core Web Vitals report in Search Console and read mobile and desktop separately. If it says no data is available, skip to step 4 and work from lab testing instead.
2. Note which URL group fails and on which metric. Fix the template, not the one URL you happened to click.
3. Check the date of your last deployment against the 28 day window before concluding that a previous fix failed.
4. Run the failing template through Lighthouse on a throttled mobile profile, then on a real iPhone, since Safari traffic never appears in the field data.
5. For an LCP failure, measure server response first. If time to first byte is above roughly half a second, fix hosting, caching and database queries before touching images.
6. Confirm the hero image is in the HTML, is not lazy loaded, and carries fetchpriority="high".
7. For a CLS failure, walk the page on a slow connection and watch what jumps. Add dimensions or reserved space to each offender.
8. Re-test in the lab the same day, then wait out the field window before judging the result.

What good scores will and will not do for rankings

Be clear eyed about the payoff. Google states that there is no single page experience signal, that “Core Web Vitals are used by our ranking systems”, and at the same time that good results do not guarantee top rankings. It also says Search will show the most relevant content even where page experience is sub-par.

Read together, that means speed work rarely rescues a page that does not answer the query, and it often decides the order among pages that answer it equally well. For a Dubai business competing with ten similar agencies or clinics, that margin is worth having, and the same fixes reduce the number of people who leave before the form loads.

Treat Core Web Vitals as a maintenance standard rather than a campaign. Sites drift as plugins, tags and tracking scripts accumulate, which is why we fold this into ongoing website maintenance rather than selling it as a one off.

Figures here are indicative and taken from public documentation on the date shown; thresholds and reporting behaviour change, so check the current Google documentation before you plan work around them. If you want the measurement set up properly and the failing templates identified before anyone writes code, our SEO team in Dubai can run that assessment with you.

Cover photo: Downtown Dubai – Dubai – United Arab Emirates – panoramio (19) by ianpudsey, via Wikimedia Commons (CC BY 3.0).