What Are Core Web Vitals?
Core Web Vitals are a set of three user-facing performance metrics created by Google’s Chrome team as part of their broader Web Vitals initiative. Each metric measures a different dimension of what real people experience when they visit your web page:
- Largest Contentful Paint (LCP) — measures loading performance
- Interaction to Next Paint (INP) — measures responsiveness
- Cumulative Layout Shift (CLS) — measures visual stability
According to Google’s official documentation, “Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page.”
(Source: https://developers.google.com/search/docs/appearance/core-web-vitals)
What makes these metrics different from other speed measurements is how Google collects the data. Core Web Vitals are measured using real user data from people browsing with Google Chrome. This data is collected through the Chrome User Experience Report (CrUX) and evaluated at the 75th percentile over a rolling 28-day window.
What does 75th percentile mean in simple terms? It means Google looks at how 75% of your visitors experience your page. If 75% of visits score “Good” across all three metrics, your page passes the Core Web Vitals assessment.
Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) on 12 March 2024. INP is more comprehensive because it measures every interaction throughout a visit, not just the first one.
(Source: https://developers.google.com/search/blog/2023/05/introducing-inp)
Key Point: The metrics that make up Core Web Vitals will evolve over time as the web and user expectations change. Google has stated that the current set focuses on loading, interactivity, and visual stability, but this may expand in future.
What Is Page Speed in SEO?
Page speed refers to how quickly your website loads and becomes usable for visitors. It is a broad concept that covers many different measurements, including:
- Time to First Byte (TTFB) — how fast your server responds to a request
- First Contentful Paint (FCP) — when the first piece of content appears on screen
- Largest Contentful Paint (LCP) — when the main content finishes loading
- Speed Index — how quickly visible content fills the screen
- Time to Interactive (TTI) — when the page becomes fully usable
- Total load time — when everything on the page has finished downloading
Google first confirmed page speed as a ranking factor for desktop searches in 2010. In July 2018, they extended it to mobile search results through the “Speed Update.”
Page speed matters because it directly affects how people behave on your site. Slow websites frustrate visitors. They leave. They bounce back to search results. And that sends negative signals to Google about your page’s quality.
Page speed also affects crawl efficiency. When your pages load faster, Google’s crawlers can index more of your site within the same time allocation, which helps with discoverability. If you are new to SEO fundamentals, understanding page speed is one of the first technical concepts to master.
Page Speed vs. Core Web Vitals: What Is the Difference?
This is where most people get confused. Page speed and Core Web Vitals are related but they are not the same thing.
| Aspect | Page Speed | Core Web Vitals |
| Definition | Broad concept of how fast a website loads | Three specific, standardised metrics |
| Scope | Many metrics (TTFB, FCP, SI, TTI, total load time) | Only LCP, INP, and CLS |
| What it measures | Overall loading duration | Loading + Responsiveness + Visual stability |
| Data source | Lab tools, server logs, real user monitoring | CrUX field data from real Chrome users |
| Used by Google since | 2010 (desktop), 2018 (mobile) | June 2021 (Page Experience update) |
| Focus | General website speed | Specific user experience dimensions |
Here is the important insight: Core Web Vitals are a subset of page speed metrics. A page can load quickly overall but still fail Core Web Vitals if it has layout shifts (poor CLS) or slow button responses (poor INP). The opposite is also true—a page can pass all three Core Web Vitals but still feel slow if the total load time or TTFB is high.
Tip: A perfect PageSpeed Insights score of 100 does not guarantee you pass Core Web Vitals. The performance score is based on lab data, but the CWV pass/fail decision is based on real user field data. Always check your Google Search Console Core Web Vitals report for the authoritative verdict.
Why Is Page Speed Important for SEO?
Page speed impacts your search rankings through multiple layers:
- Direct ranking signal
Core Web Vitals are a confirmed part of Google’s Page Experience ranking signals. Google’s documentation states: “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.”
(Source: https://developers.google.com/search/docs/appearance/core-web-vitals)
- Lightweight but real
Core Web Vitals function as a lightweight signal—they work more as a tiebreaker than a dominant factor. Content relevance, topical authority, and backlink quality still carry far more weight in determining rankings.
- Crawl budget efficiency
Faster websites get crawled more efficiently. Google allocates a crawl budget to every site—faster pages mean more pages get crawled and indexed within the same timeframe.
- Indirect signals through user behaviour
Slow pages increase bounce rates. When visitors leave immediately because a page takes too long, this sends negative engagement signals. Research consistently shows that even small delays in loading time significantly increase the probability of users abandoning a page.
- Mobile-first indexing
Google predominantly uses your mobile version for indexing and ranking. Desktop page experience signals have also been used since February 2022. In the UAE, where mobile internet usage is exceptionally high, mobile performance is critical.
Core Web Vitals are part of the broader technical SEO discipline that ensures your website is built for both search engines and users.
Tip: Do not over-invest in Core Web Vitals optimisation at the expense of content quality. Core Web Vitals are only one piece of the puzzle—content relevance, usefulness, and authority still come first.
The 3 Core Web Vitals Explained
Each Core Web Vital targets one specific dimension of user experience. Here are the current thresholds as defined by Google:
| Metric | What It Measures | Good | Needs Improvement | Poor |
| LCP (Largest Contentful Paint) | Loading performance | ≤2.5 seconds | >2.5s to ≤4s | >4 seconds |
| INP (Interaction to Next Paint) | Responsiveness | ≤200 milliseconds | >200ms to ≤500ms | >500 milliseconds |
| CLS (Cumulative Layout Shift) | Visual stability | ≤0.1 | >0.1 to ≤0.25 | >0.25 |
To pass the Core Web Vitals assessment, all three metrics must score “Good” based on field data. At least 75% of pageviews need to achieve “good” scores for the website to meet CWV thresholds.
What Is LCP (Largest Contentful Paint)?
Largest Contentful Paint measures the time from when a page starts loading until the largest visible content element is fully rendered on the screen. According to Google, LCP “measures loading performance” and you should “strive to have LCP occur within the first 2.5 seconds of the page starting to load.”
(Source: https://developers.google.com/search/docs/appearance/core-web-vitals)
LCP does not measure total page load time. It only measures when the biggest, most important piece of content becomes visible. This is what creates the user’s perception that “the page has loaded.”
Common LCP elements:
- Hero images
- Large text blocks (H1 headings, main paragraphs)
- Video poster images
- Elements with CSS background images
How LCP works in practice:
Imagine you open a webpage. First, the navigation bar appears. Then the headline text loads. Finally, a large hero image renders. That hero image becomes the LCP element because it is the largest visible content in the viewport. The moment it fully appears is when LCP is recorded.
LCP candidates can change as the page loads. The browser keeps updating the LCP candidate until the user interacts with the page (scrolls, clicks, or taps). At that point, the final candidate is locked in.
LCP sub-parts (what contributes to the total LCP time):
- Time to First Byte (TTFB) — server processing and network transit time
- Resource load delay — time before the LCP resource starts downloading
- Resource load time — time to download the image or render the text
- Element render delay — time from download completion to visual appearance on screen
What elements can be LCP candidates:
- <img> elements
- <image> elements inside SVG
- <video> poster images
- Elements with CSS background-image
- Block-level text elements (headings, paragraphs)
Note: standalone <svg> elements are currently not considered LCP candidates.
Target: Keep your LCP at or below 2.5 seconds.
What Is INP (Interaction to Next Paint)?
Interaction to Next Paint measures how quickly your page responds to user interactions throughout the entire visit. It evaluates a web page’s responsiveness by measuring the time it takes for the browser to provide visual feedback following user interactions.
Unlike the old FID metric that only measured the first interaction, INP measures every click, tap, and keypress—then reports the worst one (or near-worst for pages with many interactions).
The three phases of every interaction:
Every time someone interacts with your page, three things happen in sequence:
- Input delay — the time between the user’s action and when the browser starts processing it. This delay happens when the main thread is busy doing other work (like executing JavaScript).
- Processing time — the time it takes to run all the event handler code associated with that interaction.
- Presentation delay — the time from when processing finishes to when the browser paints the visual update on screen.
INP measures the total of all three phases combined.
What counts as an interaction:
- Clicks (mouse)
- Taps (touchscreen)
- Key presses (keyboard)
What does NOT count:
- Scrolling (handled by the GPU/compositor thread, not the main thread)
- Zooming
- Hovering
Why INP replaced FID:
FID was like judging a restaurant by only timing how fast the waiter greets you at the door. INP is like evaluating every single interaction—taking your order, bringing food, answering questions—throughout your entire meal. It gives a complete picture of responsiveness.
INP replaced First Input Delay (FID) in March 2024 because FID only measured the delay before the first interaction was processed, while INP measures the full latency of all interactions.
Target: Keep your INP at or below 200 milliseconds.
What Is CLS (Cumulative Layout Shift)?
Cumulative Layout Shift measures how much your page content moves around unexpectedly while it loads and while people use it. It quantifies visual stability. According to Google, CLS “measures visual stability” and you should “strive to have a CLS score of less than 0.1.”
(Source: https://developers.google.com/search/docs/appearance/core-web-vitals)
You have probably experienced this: you are reading an article on your phone, and suddenly an ad loads above the text, pushing everything down. You lose your place. Or you try to tap a button, but just before your finger lands, the button shifts because an image loaded above it. That is a layout shift, and it is frustrating.
How CLS is calculated:
CLS uses a formula:
Layout Shift Score = Impact Fraction × Distance Fraction
- Impact fraction = the percentage of the viewport area affected by the shift (combining the element’s area in both its old and new positions)
- Distance fraction = how far the element moved, as a percentage of the viewport’s largest dimension
Worked example:
- Viewport height: 800 pixels
- A text block occupies 400px and gets pushed down by 100px when an ad loads above it
- Impact fraction: (400 + 100) ÷ 800 = 0.625
- Distance fraction: 100 ÷ 800 = 0.125
- Layout shift score: 0.625 × 0.125 = 0.078 (this is within the “Good” threshold)
Important: CLS uses session windows to measure the largest burst of shifts. A session window groups shifts that happen within 1-second gaps, with a maximum window of 5 seconds. The largest session window becomes the CLS score.
Only unexpected shifts count. If a user clicks a button and content expands below it, that is an expected shift and does not count toward CLS. A shift is only counted when it is not triggered by a user interaction within 500 milliseconds.
Common causes of poor CLS:
- Images or videos without specified width and height
- Ads, embeds, or iframes that load without reserved space
- Content dynamically injected above existing content
- Web fonts causing Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT)
- Late-loading third-party widgets like chat buttons or cookie banners
Tip: Always specify explicit width and height attributes on every image and video element. This tells the browser exactly how much space to reserve before the resource downloads, preventing layout shifts. For responsive designs, the CSS aspect-ratio property achieves the same result.
Target: Keep your CLS at or below 0.1.
How Google Measures Core Web Vitals: Field Data vs. Lab Data
This is one of the most misunderstood aspects of Core Web Vitals. Getting it wrong leads people to optimise the wrong things.
There are two types of performance data:
| Characteristic | Field Data | Lab Data |
| What it is | Data from real Chrome users visiting your site | Data from a simulated test in a controlled environment |
| Source | Chrome User Experience Report (CrUX) | Lighthouse engine |
| Data freshness | Rolling 28-day window | Collected in real-time when you run a test |
| Device | Each visitor’s actual device | Emulated device (default: mid-range mobile phone) |
| Network | Each visitor’s actual internet connection | Simulated throttled connection |
| Used for ranking? | Yes — this is what Google uses | No — diagnostic only |
| INP available? | Yes | No (Total Blocking Time is used as a proxy) |
| Best use | Understanding real user experience, monitoring trends | Debugging issues, testing fixes before deployment |
| Limitation | Requires sufficient Chrome traffic; 28-day lag | Does not represent real user diversity |
Google evaluates Core Web Vitals using aggregated real-user data over time. Lab data from Lighthouse tells you what to fix, but field data determines whether you pass or fail in Google’s eyes.
You can have excellent lab scores (Lighthouse 95+) but terrible field data if your real users are on slow networks or old devices. The reverse is also true—poor lab scores but passing field data if your audience has fast connections and modern phones.
75th percentile explained simply:
Google does not look at the average experience. It looks at the 75th percentile. This means your score reflects what 75% of your visitors experience or better. If 75% of visits are “Good,” you pass. If fewer than 75% are “Good,” you do not pass.
Origin Summary:
Google also evaluates your entire domain as a whole (called the Origin Summary). This aggregates field data from all pages on your site. If certain page templates are slow, they drag down your overall site assessment.
Tip: If your website has low traffic, Google Search Console may not display Core Web Vitals data because there is insufficient CrUX data. Use Lighthouse and PageSpeed Insights for diagnostics in the meantime, but understand that Google cannot evaluate your CWVs for ranking purposes until enough real user data accumulates through Chrome.
How to Check Core Web Vitals: Tools & Step-by-Step Guide
Google provides several free tools to measure Core Web Vitals. PageSpeed Insights and Search Console are among the most important SEO tools you should be using regularly to monitor website performance. Each serves a different purpose.
Google Search Console (Core Web Vitals Report)
Best for: Monitoring your entire site’s CWV health over time.
How to access:
- Log into Google Search Console
- Navigate to Experience → Core Web Vitals
- You will see separate graphs for Mobile and Desktop
What it shows:
- How many URLs are categorised as Good, Needs Improvement, or Poor
- Trends over the last 3 months
- URL groups with specific issues (e.g., “Poor LCP issue: longer than 4s”)
Important notes:
- This is NOT real-time. It reflects the last 28 days of real user data.
- URLs are grouped by similar page types (templates). Fixing a template issue improves all pages using that template.
- The report may not show all “Good” URLs—this does not mean those pages have problems.
- You need sufficient traffic for data to appear.
Click on any issue row to see example URLs, then click “Developer Resources” to analyse specific pages in PageSpeed Insights.
Google PageSpeed Insights
Best for: Diagnosing specific pages and understanding both field data and lab data for a single URL.
How to use:
- Go to pagespeed.web.dev
- Enter your URL
- Click Analyse
- Toggle between Mobile and Desktop results
What it shows:
Section 1 — Field data (“Discover what your real users are experiencing”)
This is the data that matters for ranking. It shows your actual Core Web Vitals scores from real Chrome users over the last 28 days. If this section shows all green, you are passing.
Section 2 — Lab data (“Diagnose performance issues”)
This is from Lighthouse. It shows a performance score (0-100) and individual metric scores. Below this, you will find:
- Opportunities — specific suggestions to improve speed
- Diagnostics — detailed technical issues detected
You can filter Opportunities and Diagnostics by specific metric (LCP, CLS, TBT) using the links provided.
Performance score breakdown (Lighthouse v10/v12):
| Metric | Weight in Score |
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index (SI) | 10% |
Key Point: The performance score (0-100) is a lab metric. It is NOT the same as passing Core Web Vitals. You could score 60 in Lighthouse but still pass CWVs if your real users have a good experience. And you could score 95 in Lighthouse but fail if your field data is poor.
Chrome User Experience Report (CrUX) & Other Tools
CrUX Dashboard:
CrUX delivers real-world, user-experience data on Core Web Vitals metrics. CrUX data is collected from Google Chrome users who have opted in to reporting on their browsing history and usage statistics. You can check segments and see your historical data using Google’s free CrUX Looker Studio dashboard.
Chrome DevTools (Performance tab):
Open DevTools in Chrome, go to the Performance tab, enable Screenshots and Web Vitals, then record a page load. This gives you frame-by-frame analysis showing exactly when layout shifts happen, what element is the LCP, and where long tasks block the main thread.
Web Vitals Chrome Extension:
A lightweight browser extension that displays real-time Core Web Vitals as an overlay while you browse. Useful for quick spot-checks on any page.
Tip — Tool decision framework:
- Use Google Search Console for monitoring site-wide health over time
- Use PageSpeed Insights for diagnosing specific problem pages
- Use Chrome DevTools for debugging individual elements causing issues
- Use the Web Vitals Extension for quick, real-time spot checks while browsing
How to Improve Core Web Vitals & Page Speed
Before diving into per-metric fixes, keep these principles in mind:
- Fix templates first. One template fix improves every page using that template.
- Address site-wide elements before page-specific ones. Navigation, headers, footers, and third-party scripts affect every page.
- Prioritise by impact. Fix your worst metric first—it is the one failing you.
- Test in lab, validate in field. Make changes, confirm improvement in Lighthouse, then wait 28 days for field data confirmation.
- Monitor trends over time rather than individual scores. A practical workflow focuses on continuous improvement.
How to Improve LCP (Largest Contentful Paint)
LCP improvement targets the four sub-parts of loading: server response, resource discovery, resource download, and rendering.
- Reduce server response time (TTFB):
- Use a CDN to serve content from servers geographically closer to your UAE audience
- Enable server-side caching—stores frequently requested content in server memory, delivering it directly without reprocessing each request
- Upgrade hosting if TTFB consistently exceeds 800ms
- Use HTTP/2 for more efficient data transmission by processing multiple requests in parallel within a connection
- Enable Brotli or Gzip compression to reduce file sizes before transmission
- Eliminate render-blocking resources:
- Inline critical CSS (styles needed for above-the-fold content) directly in the HTML
- Defer non-critical CSS using media attributes or loading strategies
- Add async or defer attributes to JavaScript files that are not needed for initial render
- Remove unused CSS and JavaScript code
- Minimise scripts and stylesheets to reduce their file size
- Optimise resource loading:
- Preload your LCP resource: use <link rel=”preload”> for the hero image or key font
- Use <link rel=”preconnect”> to establish early connections to third-party domains
- Serve images in modern formats (WebP or AVIF) for significantly smaller file sizes
- Use responsive images with srcset to deliver appropriately sized images for each device
- Set fetchpriority=”high” on the LCP image to tell the browser to prioritise it
- Reduce image file sizes with compression tools without visibly compromising quality
- Reduce render delay:
- Do NOT lazy-load your above-the-fold LCP image—it must load eagerly
- Avoid using CSS background-image for LCP elements; use <img> instead (browsers can discover it earlier in the HTML)
- Use font-display: swap or font-display: optional for web fonts to prevent text rendering delays
- Minimise client-side rendering for critical content; server-render when possible
How to Improve INP (Interaction to Next Paint)
INP improvement targets the three phases of interaction: input delay, processing, and presentation.
- Reduce input delay (main thread availability):
- Break long tasks (anything over 50ms) into smaller chunks
- Reduce and defer third-party JavaScript (analytics, ads, chat widgets)
- Use requestIdleCallback for non-urgent background work
- Keep your DOM size manageable—extremely large DOMs (over 1,500 elements) increase processing time for every interaction
- Reduce processing time (faster event handlers):
- Optimise your event handler code—avoid doing unnecessary work on every interaction
- Use AbortController to cancel unnecessary ongoing operations when new interactions happen
- Debounce or throttle rapid-fire interactions (like search-as-you-type)
- Offload heavy computation to Web Workers, keeping the main thread free for user interactions
- Reduce presentation delay (faster visual updates):
- Minimise DOM size to speed up layout and paint operations
- Avoid forced synchronous layouts (reading layout properties immediately after writing them)
- Use CSS content-visibility: auto for off-screen content so the browser skips rendering it until needed
- Prefer CSS transform and opacity for animations—these are compositor-friendly and do not trigger layout recalculations
- Simplify CSS selectors to reduce style recalculation time
How to Improve CLS (Cumulative Layout Shift)
CLS improvement focuses on preventing unexpected content movement.
- Images and video:
- Always include width and height attributes on <img> and <video> elements
- Use CSS aspect-ratio property for responsive containers
- Never lazy-load above-the-fold images without explicit dimensions set
- Set images to their actual display size to prevent reflows
- Ads, embeds, and dynamic content:
- Reserve fixed space for ad slots using CSS min-height on their containers
- Give <iframe> elements explicit width and height for embeds
- Avoid inserting content above existing content
- If dynamic content must appear, use smooth CSS transitions rather than instant insertion
- Minimise animations that cause layout shifts
- Web fonts:
- Use font-display: swap or font-display: optional to prevent invisible text
- Preload critical fonts: <link rel=”preload” as=”font” crossorigin>
- Use the size-adjust descriptor on fallback fonts to match metrics of the web font
- Consider system font stacks for body text to eliminate font-loading shifts entirely
- Animations and transitions:
- Use CSS transform instead of properties that trigger layout (top, left, width, height)
- Apply will-change sparingly on elements you know will animate
- Prefer CSS animations over JavaScript-driven animations for visual effects
Core Web Vitals Best Practices (Quick Checklist)
Track your Core Web Vitals as one of your key SEO KPIs each month to ensure your site maintains healthy performance over time.
General:
- Monitor CWVs monthly in Google Search Console
- Fix template-level issues first (one fix = many pages improved)
- Prioritise mobile performance (Google indexes mobile-first)
- Use field data for assessment, lab data for debugging
- Test after every major site change or redesign
- Focus on continuous improvement rather than chasing isolated metrics
LCP checklist:
- Preload your LCP resource
- Use a CDN for all static assets
- Serve images in WebP or AVIF format
- Eliminate render-blocking CSS and JavaScript
- Keep TTFB under 800ms
- Compress all images without visible quality loss
INP checklist:
- Keep all JavaScript tasks under 50ms
- Reduce bundle sizes through code splitting
- Minimise third-party scripts
- Keep DOM under 1,500 elements where feasible
- Test actual interactions, not just page load
CLS checklist:
- Set explicit dimensions on all media elements
- Reserve space for ads and dynamic content
- Preload web fonts
- Avoid layout-triggering CSS animations
- Never inject content above existing visible content
How to Pass the Core Web Vitals Assessment
Passing the Core Web Vitals assessment means all three metrics score “Good” based on field data at the 75th percentile:
- LCP ≤ 2.5 seconds
- INP ≤ 200 milliseconds
- CLS ≤ 0.1
What “passing” actually requires:
- At least 75% of pageviews must meet the “Good” threshold for each metric
- Data must come from real Chrome users (field data via CrUX)
- Your site needs sufficient Chrome traffic for data to exist
- Assessment happens both per-URL and per-origin (site-wide)
- Google groups similar URLs—fixing one template fixes many URLs at once
Common misconceptions cleared up:
| Misconception | Reality |
| “I need a Lighthouse score of 90+ to pass” | Lighthouse score is lab data. Passing is determined by field data only. |
| “One failing page means my whole site fails” | Assessment is per-URL and per-origin separately. One bad page does not fail your entire site. |
| “I fixed it today, it should pass tomorrow” | Field data uses a 28-day rolling window. Changes take up to 28 days to fully reflect. |
| “No CWV data means I’m failing” | No data means insufficient traffic. Google cannot evaluate you—it does not mean you fail. |
Are Core Web Vitals a Ranking Factor?
Yes. Core Web Vitals are a confirmed Google ranking signal. They are part of the broader Page Experience signals that Google evaluates.
Google states: “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.”
(Source: https://developers.google.com/search/docs/appearance/core-web-vitals)
But context matters. Core Web Vitals function as a lightweight signal—think of them as a tiebreaker, not a dominant force. Content relevance, topical authority, and backlink quality remain far more important ranking factors.
Where CWVs make a difference:
When two pages have similar content quality, similar authority, and similar relevance to a search query—Core Web Vitals can tip the scale. They are most impactful when you are competing against pages of comparable quality.
The indirect effect:
Beyond the direct ranking signal, good Core Web Vitals create a better user experience. Users stay longer, bounce less, and engage more. These behavioural signals can indirectly strengthen your rankings over time. If your rankings have dropped and you suspect performance issues may be a contributing factor, our guide on ranking drop recovery explains how to diagnose and fix the problem.
The honest truth: Unless your site is extremely slow, Core Web Vitals improvements alone are unlikely to produce dramatic ranking changes. But combined with strong content, good technical SEO, and solid link authority, they contribute to overall ranking strength.
The Page Experience Signal: Where Core Web Vitals Fit
Core Web Vitals are one component of Google’s Page Experience ranking signals. Page Experience is one of many quality signals Google uses alongside E-E-A-T to evaluate whether your content deserves to rank. The full picture includes:
- Core Web Vitals — LCP, INP, CLS (loading, responsiveness, visual stability)
- HTTPS — secure encrypted connection
- Mobile-friendliness — responsive design, no horizontal scrolling on mobile
- No intrusive interstitials — no aggressive full-screen popups blocking content immediately
Timeline:
- June 2021: Page Experience rolled out on mobile
- February 2022: Extended to desktop
- April 2023: Google clarified that page experience is now integrated into its core ranking systems rather than existing as a separate standalone signal
(Source: https://developers.google.com/search/docs/appearance/page-experience)
This means page experience considerations are woven into Google’s overall approach to ranking—they do not function as an independent switch that turns on or off.
Mobile Performance & Core Web Vitals
In the UAE, mobile internet usage dominates. Most of your visitors are likely browsing on smartphones over 4G or 5G connections. This makes mobile Core Web Vitals especially critical.
Why mobile scores are typically worse:
- Mobile devices have weaker processors and less RAM than desktops
- Mobile network connections are more variable (switching between 4G, 5G, Wi-Fi)
- Screen sizes are smaller, but content complexity is often the same
- Mobile browsers handle JavaScript more slowly
Key points for UAE webmasters:
- Google uses mobile-first indexing—it predominantly crawls and indexes your mobile version
- CWV thresholds are the same for mobile and desktop (2.5s LCP, 200ms INP, 0.1 CLS)
- Google Search Console shows separate Mobile and Desktop CWV reports
- PageSpeed Insights defaults to Mobile view (always check this first)
- A mobile-first strategy means optimising the website for mobile devices first before adjusting for larger screens
Tip: When testing your site, always check mobile performance first. If your mobile CWVs are green but desktop is yellow, you are in good shape for ranking. But if mobile fails, that directly affects how Google evaluates your pages regardless of desktop scores.
Common Causes of Poor Core Web Vitals & Page Speed
Here are the most frequent problems and what they affect:
| Cause | Metrics Affected | Why It Happens |
| Large unoptimised images | LCP | Browser downloads massive files before content renders |
| Render-blocking CSS/JavaScript | LCP | Browser cannot paint content until these files download and execute |
| Slow server or no CDN | LCP, TTFB | High initial wait time, especially for users far from the server |
| Heavy or unoptimised JavaScript | INP, LCP | Blocks the main thread, preventing interaction responses |
| Very large DOM (>1,500 elements) | INP, CLS | Slower style calculations and layout operations |
| Third-party scripts (ads, analytics, chat) | INP, CLS | Unpredictable loading, main thread blocking |
| Images without width/height attributes | CLS | Browser cannot reserve space before image loads |
| Late-loading ads or embeds | CLS | Push existing content down when they appear |
| Web fonts without font-display strategy | CLS, LCP | Text reflows or disappears while fonts download |
| No browser caching strategy | LCP | Returning visitors re-download everything from scratch |
| Excess of scripts and stylesheets | LCP, INP | Too many HTTP requests slow everything down |
Core Web Vitals in 2026: Current State & What Is Next
The current three Core Web Vitals are:
- LCP (Largest Contentful Paint) — unchanged since introduction
- INP (Interaction to Next Paint) — became official March 2024, replacing FID
- CLS (Cumulative Layout Shift) — unchanged since session window update
This is a stable metric set. Google has stated that “the metrics that make up Core Web Vitals will evolve over time” but no changes to the current three are announced.
What is being explored:
- Soft navigations: Google is exploring how to measure CWVs within Single Page Applications (SPAs) where navigation happens without full page loads
- Responsiveness refinements: Potential future metrics measuring animation smoothness and interaction fluidity
- Page Experience integration: Google now treats page experience as part of its core ranking systems rather than a standalone algorithm
The direction is clear: performance measurement is becoming more sophisticated, more representative of real user experiences, and more deeply integrated into how Google evaluates and ranks pages.
Frequently Asked Questions
Does page speed affect SEO?
Yes. Page speed affects SEO directly through Core Web Vitals (a ranking signal in Google’s Page Experience system) and indirectly through user behaviour. Faster pages reduce bounce rates, increase engagement, and improve crawl efficiency. However, page speed is a lightweight signal compared to content relevance and backlink authority.
How does page speed affect SEO ranking?
Page speed influences rankings through three channels: Core Web Vitals as a direct ranking signal, crawl budget efficiency (faster pages get crawled more thoroughly), and user engagement signals (visitors spend more time on fast pages). The impact is most noticeable when competing pages have similar content quality and authority.
What is a good page speed score?
A “good” Core Web Vitals assessment requires LCP ≤2.5 seconds, INP ≤200 milliseconds, and CLS ≤0.1. The PageSpeed Insights performance score (0-100) is separate—90+ is considered good, 50-89 needs improvement, and below 50 is poor. The performance score is lab-based and does not directly determine your CWV ranking status.
How long does it take for Core Web Vitals improvements to show?
Changes take approximately 28 days to fully reflect in Google Search Console because field data is based on a 28-day rolling window of real user visits. After making optimisations, verify improvements immediately in Lighthouse (lab data), but wait at least 28 days before expecting field data changes in Search Console.
Do Core Web Vitals matter for low-traffic websites?
For websites with very low traffic, Google may not have enough CrUX data to evaluate Core Web Vitals. Without data, CWVs cannot function as a ranking signal for those pages. However, optimising for speed still benefits user experience and helps indirectly through better engagement when visitors do arrive.
What replaced FID in Core Web Vitals?
Interaction to Next Paint (INP) replaced First Input Delay (FID) on 12 March 2024. FID only measured the delay before the browser began processing the first user interaction. INP measures the complete latency of all interactions throughout the entire page visit, making it far more comprehensive and accurate as a responsiveness metric.
Is a Lighthouse score of 100 necessary to pass Core Web Vitals?
No. The Lighthouse performance score and the Core Web Vitals assessment are two different evaluations. Lighthouse provides lab data scored 0-100. Core Web Vitals pass/fail is determined by field data from real users. You can pass CWVs with a Lighthouse score of 70 if your real users have a good experience, and you can fail with a score of 95 if your real audience is on slow devices or unreliable networks.
Which Core Web Vital is hardest to fix?
LCP is generally considered the most challenging because it depends on multiple factors: server response time, resource discovery, download speed, and render timing. INP can be difficult for JavaScript-heavy applications with complex interactivity. CLS is often the easiest to fix because solutions—adding dimensions to images, reserving space for ads—are straightforward and produce predictable results.
How are Core Web Vitals different from Lighthouse scores?
Core Web Vitals are three specific metrics (LCP, INP, CLS) measured from real users over 28 days. Lighthouse scores are lab-based performance audits that simulate a page load in a controlled environment. Google uses Core Web Vitals field data for ranking decisions. Lighthouse scores are diagnostic tools that help you identify what to fix but do not directly determine your ranking status.
“`html
“`