The ad was clicked.
The page was white for four seconds.
The back button was faster.
Picture a Muscat clinic spending OMR 800 a month on Google Ads. The landing page looks polished on the office desktop. On a mid-range phone on mobile data, the hero image takes four seconds to appear, the booking button jumps down when a banner loads, and tapping “Book now” freezes for half a second.
Nobody complains. Visitors simply leave. The ad account reports clicks; the clinic wonders why bookings are flat.
This is a fictional teaching example. The three problems in it, however, map exactly onto Google’s three Core Web Vitals, which makes them measurable and fixable.
Three numbers, three feelings
Google’s Core Web Vitals turn “the site feels slow” into three specific measurements. Each maps onto something a visitor feels. [1]
| Metric | What the visitor feels | Good · Needs work · Poor |
|---|---|---|
| LCP · Largest Contentful Paint | “Is anything happening?” How long until the main content appears. | ≤ 2.5 s · up to 4 s · over 4 s |
| INP · Interaction to Next Paint | “Did my tap work?” How quickly the page responds to taps, clicks and typing. | ≤ 200 ms · up to 500 ms · over 500 ms |
| CLS · Cumulative Layout Shift | “Why did that move?” How much the layout jumps while loading. | ≤ 0.1 · up to 0.25 · over 0.25 |
A page passes when all three are in the good range for at least 75% of visits, measured separately for mobile and desktop. [1] That 75th-percentile rule matters: a page that is fast for you on office Wi-Fi can still fail for a quarter of your customers on phones.
Two of three metrics need work, so the page does not pass. The shaded part of each bar shows how far past “good” the score sits.
Lab tests versus real visitors
There are two kinds of speed data, and mixing them up causes most confusion.
Lab data comes from a single simulated visit, such as a Lighthouse test. It is excellent for diagnosing problems and checking fixes, but it is one device on one connection at one moment.
Field data comes from real visitors’ browsers. PageSpeed Insights shows it when enough real visits exist, and Search Console groups your pages by status in its Core Web Vitals report. [2] [3] Field data is what reflects your customers’ experience, so decide priorities with it, and use lab tests to find the cause.
Small sites often lack enough traffic for page-level field data. In that case, use origin-level data where available, test on a real mid-range phone over mobile data, and run lab tests with mobile throttling. You can start with this site’s free speed test tool.
Which vital should you fix first?
Enter your mobile field values from PageSpeed Insights or Search Console. If you only have lab values, use them as a rough guide.
Start with LCP: compress and correctly size the main image or hero, serve it early, and cut render-blocking scripts and fonts above it.
The checker runs in your browser and does not send or save your values. It applies Google’s published thresholds; it does not measure your site.
Fix in the order visitors feel it
Most speed problems on small-business sites come from a short list of causes. Work through them in this order.
The hero image
The largest element is often a huge photo or slider. Resize it to the space it fills, use a modern format such as WebP, avoid lazy-loading it, and remove sliders that load several heavy images at once.
Third-party tags
Chat widgets, heatmaps, multiple pixels and old tracking scripts compete for the phone’s processor. Audit your tag manager and remove anything nobody uses. This often helps LCP and INP together.
Reserved space
Give images, video embeds and banners fixed dimensions, and load cookie bars or promos without pushing content down. That is most of CLS.
Hosting and fonts
A slow server delays everything. Check server response time, use caching and a CDN, and limit custom fonts to the weights you actually use.
For Arabic and English sites, check both language versions. Arabic pages often load an extra font file, and a right-to-left layout can shift if space is not reserved for it. Measure the pages your ads and search results actually send people to, not just the homepage.
- Pages
- The five landing pages that receive most ad and search traffic, in Arabic and English.
- Target
- Good LCP, INP and CLS at the 75th percentile on mobile field data.
- First fix
- Hero image and render-blocking scripts on the booking page.
- Guardrail
- No change removes conversion tracking or consent handling.
- Proof
- Before and after lab tests now; field data re-checked after 28 days.
Keep it fast: a monthly five-minute check
Sites slow down gradually. A new plugin, a larger banner or one more tracking tag each seem harmless. Put speed into your monthly routine.
- Open Search Console’s Core Web Vitals report. Note how many mobile URLs are poor, need improvement or are good.
- Test your top landing page. Run it through PageSpeed Insights and note the field values if available.
- Review what changed. New tags, plugins, images or campaigns since last month are the usual suspects.
- Fix one thing. One focused improvement a month compounds faster than a big redesign every three years.
Before your next campaign goes live
Speed is part of the offer
A fast page will not rescue a weak offer, and Core Web Vitals are only one of many signals in search. But a slow page taxes every rial you spend bringing people to it. Fix the first impression, then judge your campaigns. For the wider technical picture, see the technical SEO checklist.
Questions about site speed
Will passing Core Web Vitals move us to the top of Google?
No single signal does that. Core Web Vitals form part of how Google assesses page experience, while relevance and content quality matter more. The stronger case for speed is conversion: visitors who wait less leave less.
My lab score is 95 but the field data says “needs improvement”. Which is right?
Both, for different visits. The lab test is one simulated load; the field data reflects real devices and connections. Your customers live in the field data.
Do I need a new website to fix this?
Rarely. Images, tags, fonts and hosting cause most problems and can usually be fixed on the existing site.
References & method
Sources checked September 24, 2026. The clinic and its scores are fictional.
- web.dev: Web Vitals — the three Core Web Vitals, their good thresholds and the 75th-percentile rule.
- PageSpeed Insights — lab and real-user field data for a URL.
- Search Console Help: Core Web Vitals report — grouping your pages by field performance.
Method: the checker rates each value as good, needs improvement or poor using the thresholds in the table (LCP 2.5 s / 4 s, INP 200 ms / 500 ms, CLS 0.1 / 0.25). The page passes only when all three are good. The first fix suggested is the worst-rated metric, taking LCP, then INP, then CLS when ratings tie.