Core Web Vitals explained: LCP, INP and CLS for Arabic websites

Core Web Vitals are three measurements of how a page feels to a real visitor: how fast the main content appears, how quickly the page responds, and how steady the layout stays. Google publishes a clear “good” threshold for each, and it recommends reaching them, but it is equally clear that good scores do not guarantee top rankings.

What the three metrics measure, and how much they matter

Here are the three metrics with the thresholds web.dev gives for a good user experience:

• Largest Contentful Paint (LCP) measures loading. LCP should occur within 2.5 seconds of when the page first starts loading.
• Interaction to Next Paint (INP) measures responsiveness to taps, clicks and key presses. Pages should have an INP of 200 milliseconds or less. INP is the current responsiveness metric, so advice written for the older FID metric is out of date.
• Cumulative Layout Shift (CLS) measures visual stability. Pages should keep a CLS of 0.1 or less.

A page does not pass on one lucky load. web.dev says a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop. In plain words, at least three out of four visits should meet the target, and mobile and desktop are judged separately.

Google’s position on their role in Search has two sides. It writes that it highly recommends site owners achieve good Core Web Vitals for success with Search and for a great user experience generally. It also says Search always seeks to show the most relevant content, even if the page experience is sub-par, and that good results in the Core Web Vitals report or in third-party tools do not guarantee top rankings.

My reading: treat Core Web Vitals as a quality standard for your readers, not as a ranking trick. A slow Arabic article with the best answer can still beat a fast page with a weak one.

Improving your scores step by step

1. Start with field data. The Search Console Core Web Vitals report is based on real world usage data. Lab tools are useful for debugging, but a lab score of 100 means little if real visitors on mid-range phones have a different experience.
2. Check individual URLs. PageSpeed Insights lets you test a single page and see where the time goes. Focus on your most visited templates first: article page, homepage, category page.
3. Fix LCP first on article pages. The largest element is usually the hero image or the headline block. Serve a properly sized, compressed hero image, and do not lazy-load it. web.dev’s research on lazy loading supports loading images in the initial viewport eagerly while lazy-loading the rest.
4. Trim your Arabic fonts. Arabic web fonts are often large, and themes tend to load several families and weights. My rule of thumb is one family and two weights at most, hosted efficiently. Every extra font file competes with your content.
5. Reduce INP with less JavaScript. Long tasks block the page from responding. Heavy third-party scripts, such as several ad networks, chat widgets and tracking tags, are frequent causes. Remove what you do not use and delay what is not needed at first paint.
6. Stop layout shifts. Give every image and embed explicit width and height so space is reserved. Reserve fixed space for ad slots. Avoid banners that push content down after the page has loaded. Check that swapping from a fallback font to your Arabic web font does not reflow the whole article.
7. Re-measure over weeks, not minutes. Field data reflects visits over time, so improvements show gradually in the report.

Example: an Arabic article template

A common pattern on Arabic news and blog sites: a large photo at the top, a slider below it, and a font that loads late. Here is a leaner version of the image markup:

<img src="/img/hero-coffee.webp" alt="فنجان قهوة عربية بجانب دلة نحاسية" width="1200" height="675" fetchpriority="high">
<img src="/img/beans.webp" alt="حبوب قهوة محمصة في وعاء خشبي" width="800" height="450" loading="lazy">

The hero image loads eagerly with high priority, which helps LCP. The second image, further down the page, is lazy-loaded. Both declare width and height, which lets the browser reserve space and helps CLS. The alt text is in Arabic because the page is in Arabic.

For RTL layouts, test the mobile menu and any sticky header on a real phone. A header that changes height as you scroll, or a menu icon that appears late, can add layout shift that a desktop test never shows.

Core Web Vitals checklist

Common mistakes

• Chasing a perfect lab score. Real visitors decide your field data. Improve what they experience.
• Lazy-loading the hero image. It delays the largest element on the page, the one LCP measures.
• Loading many Arabic font families and weights. It is a heavy cost that rarely adds anything readers notice.
• Assuming good Core Web Vitals will lift rankings by themselves. Google says relevance comes first and good scores are no guarantee.
• Still optimizing FID. INP is the metric to track now.
• Averaging mobile and desktop. Google’s guidance segments them, and the two can tell very different stories.

Sources

• web.dev, “Web Vitals” article with thresholds and the 75th percentile guidance, consulted 21 February 2026, https://web.dev/articles/vitals
• Google Search Central, documentation on Core Web Vitals and Google Search results, consulted 21 February 2026, https://developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central, documentation on page experience in Google Search, consulted 21 February 2026, https://developers.google.com/search/docs/appearance/page-experience
• web.dev, article on optimizing Interaction to Next Paint, consulted 21 February 2026, https://web.dev/articles/optimize-inp
• web.dev, article on the effect of lazy loading on LCP, consulted 21 February 2026, https://web.dev/articles/lcp-lazy-loading
• Google Search Central, documentation on getting started with Search Console (Core Web Vitals report), consulted 21 February 2026, https://developers.google.com/search/docs/monitor-debug/search-console-start