# Mobile Pages and Page Speed: Core Web Vitals Explained for Beginners, and How They Really Relate to Rankings > Core Web Vitals measure loading, responsiveness and layout stability. Learn the LCP, INP and CLS thresholds, why mobile matters, and what they mean for rankings. | Field | Value | |-------|-------| | Published | 2026-10-13 | | Category | Beginner | | Author | Aro Ogata | | Tags | beginner, SEO basics, Core Web Vitals, page experience, mobile-first indexing, PageSpeed Insights, page speed | | URL | https://linksurge.jp/blog/en/core-web-vitals-beginners/ | --- ## Key Takeaways: Core Web Vitals Are a Health Check for How Your Page Feels, Not a Ranking Guarantee Sooner or later, every new site owner hears it: "Slow sites get buried in Google." After reading Google's Search Central documentation side by side with the metric guides on web.dev, here's what I think a beginner actually needs to know. 1. **Core Web Vitals measure page experience with three numbers** — How long the main content takes to appear (LCP), how quickly the page responds to taps and clicks (INP), and how much the layout jumps around while loading (CLS). Google's "good" targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less 2. **Google looks at the mobile version of your page** — Google crawls with a smartphone agent and uses the mobile version of your content for indexing and ranking. This is called mobile-first indexing 3. **They're used in ranking, but faster doesn't automatically mean higher** — Google says its ranking systems use Core Web Vitals, yet good scores don't guarantee top rankings, and the most relevant content is always favored 4. **Two free tools are enough to check** — PageSpeed Insights shows page-level numbers, and Search Console's Core Web Vitals report shows trends across your site. Both are built on real-user data Let's walk through what the three numbers mean, why mobile matters, how they connect to rankings, and how to check your own site. --- ## 1. What Are Core Web Vitals? ### In one line: do people get frustrated using your page? Core Web Vitals are three metrics Google uses to describe the experience of using a page. They cover loading, responsiveness, and visual stability. Think of it like walking into a store. Does the door open right away? When you ask a clerk something, do they answer? Does the shelf suddenly slide so you grab the wrong product? None of that is about what the store sells. But if it's bad enough, customers walk out. ### They're one part of "page experience" Google calls the overall experience of using a page "page experience." Core Web Vitals are one piece. Google's self-assessment questions for site owners also ask whether: - Your pages are served securely over HTTPS (the encrypted connection behind URLs that start with "https://") - Your content displays well on mobile devices - You avoid so many ads that they distract from the main content - You avoid intrusive interstitials, the pop-ups that cover the page - Visitors can easily tell your main content apart from everything else Here's a simple way to hold it in your head: Core Web Vitals are the parts you can measure with numbers. The rest you check by looking at your pages. > References: > [Understanding page experience in Google Search results - Google Search Central](https://developers.google.com/search/docs/appearance/page-experience) > [Understanding Core Web Vitals and Google search results - Google Search Central](https://developers.google.com/search/docs/appearance/core-web-vitals) --- ## 2. Reading the Three Numbers ### LCP: how long until the "main thing" shows up LCP (Largest Contentful Paint) measures how long it takes for the largest image or block of text in the visible screen to appear. On a news article, that's often the lead photo or headline. On a product page, it's usually the product image. Put simply: the moment you feel the page has actually loaded. ### INP: how fast the page reacts to you INP (Interaction to Next Paint) measures the time from a click, tap, or key press until the screen shows a response. You tap a button, nothing happens, you tap it again. That sluggish feeling is what INP captures. Scrolling and hovering don't count. INP joined the Core Web Vitals in 2024, replacing an older metric called FID (First Input Delay). ### CLS: does the layout jump while you read? CLS (Cumulative Layout Shift) measures how much text and buttons move unexpectedly. You go to tap a link, an ad loads above it, and you hit the wrong thing. web.dev even gives an example of someone confirming a large order they meant to cancel. Shifts that happen within half a second of your own input aren't counted. ### The thresholds Here are the thresholds from web.dev and Search Console Help, as checked on October 13, 2026. | Metric | What it measures | Good | Needs improvement | Poor | |:--|:--|:--|:--|:--| | LCP | Main content appearing | 2.5s or less | Up to 4s | Over 4s | | INP | Response to input | 200ms or less | Up to 500ms | Over 500ms | | CLS | Layout shifting | 0.1 or less | Up to 0.25 | Over 0.25 | CLS has no unit because it scores how much things moved, not how long anything took. ### Judged at 75% of visits, not one test This is the part beginners usually miss. Core Web Vitals aren't pass/fail on a single measurement. web.dev recommends judging at the 75th percentile of real page loads. In plain terms, a page is "good" when at least 75% of visits meet the target. And that judgment is made separately for mobile and desktop. Your page can feel instant on your office laptop and still drag for someone on a phone with a weak signal. I see that gap all the time. > References: > [Web Vitals - web.dev](https://web.dev/articles/vitals) > [Largest Contentful Paint (LCP) - web.dev](https://web.dev/articles/lcp) > [Interaction to Next Paint (INP) - web.dev](https://web.dev/articles/inp) > [Cumulative Layout Shift (CLS) - web.dev](https://web.dev/articles/cls) > [Core Web Vitals report - Search Console Help](https://support.google.com/webmasters/answer/9205520?hl=en) --- ## 3. Why Mobile Matters So Much With the three numbers covered, let's turn to the other half of this topic: how your pages work on phones. ### Google reads the phone version of your page Google uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking. That's mobile-first indexing. In "[How Search Engines Work](/blog/en/how-search-engines-work/)," we broke search into finding, storing, and choosing pages. The version Google stores is the mobile one. ### Cutting content on mobile can cost you traffic Google asks you to put the same content on your mobile site as on your desktop site. Its guide warns that if you show less on mobile, you should expect some traffic loss. The fix for small screens isn't deleting text. It's folding it into accordions or tabs that open on tap. One more trap: main content that only loads after a tap or swipe. Google doesn't click or swipe to reveal content, so anything hidden behind that kind of interaction may never be read. ### Responsive design is the default choice Google recommends responsive web design, where the same URL and HTML adjust to the screen size, because it's the easiest pattern to implement and maintain. Most modern WordPress themes and website builders work this way. Having a mobile version isn't technically required to appear in Google. But Google calls it "very strongly recommended." > References: > [Mobile site and mobile-first indexing best practices - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) --- ## 4. How Do Core Web Vitals Relate to Rankings? This is the most important section of the article. Don't skip it. ### What Google actually says | What Google says | What it means for you | |:--|:--| | Core Web Vitals are used by its ranking systems | They are one of the inputs | | There is no single page experience signal | It's not a simple "hit the number, get a bonus" system | | Good results don't guarantee top rankings | Passing doesn't mean you'll move up | | Search always seeks to show the most relevant content, even with sub-par page experience | A slow page that answers the question well can still rank | | For many queries there is lots of helpful content, and a great page experience can contribute to success | With many good options, it can help you stand out | What struck me reading the docs was how Google pairs "we strongly recommend improving" with repeated reminders that nothing is guaranteed and relevance comes first. Google also says page experience aspects beyond Core Web Vitals don't directly help you rank higher. They can still make your site more satisfying to use, which is why improving them is worthwhile. ### Not a gate, not a cheat code My reading is that Core Web Vitals matter most when pages are otherwise similarly useful. Speed won't lift a page that doesn't answer the searcher's question. And a "needs improvement" score won't keep a page out of search either. So if your rankings drop, don't jump straight to blaming speed. Rankings move for lots of reasons, from daily noise to core updates. "[Why Do Search Rankings Change Every Day?](/blog/en/why-search-rankings-change/)" and "[Rankings Dropped? What to Check First](/blog/en/ranking-drop-first-checks/)" walk through how to tell them apart. > References: > [Understanding page experience in Google Search results - Google Search Central](https://developers.google.com/search/docs/appearance/page-experience) > [Understanding Core Web Vitals and Google search results - Google Search Central](https://developers.google.com/search/docs/appearance/core-web-vitals) --- ## 5. How to Check Your Own Numbers Now let's look at real numbers. Two free tools will do. ### PageSpeed Insights: one page at a time PageSpeed Insights is Google's free tool that analyzes a single URL. The results show two kinds of data side by side. When I explain this tool to people, this distinction is where I spend the most time. | Type | What it is | Use it for | |:--|:--|:--| | Field data (real-user data) | Measurements from real Chrome users over the past 28 days | Deciding whether Core Web Vitals pass | | Lab data (including the Performance score) | A simulated page load under fixed conditions | Finding the cause of problems | The 0–100 Performance score comes from lab data. 90 or higher counts as good, but it isn't the Core Web Vitals verdict. web.dev is blunt about this: lab measurement is not a substitute for field measurement. New pages and low-traffic pages may not have enough field data. In that case PageSpeed Insights falls back to site-wide data, or shows no real-user data at all. ### Search Console's Core Web Vitals report: the whole site Search Console, Google's free site management tool, has a Core Web Vitals report. It also runs on real-user data. It groups similar pages and rates each group Good, Need improvement, or Poor. A group's status is set by its worst metric, and mobile and desktop are reported separately. After you fix something, click "Start Tracking" to begin a 28-day monitoring period. If the issue doesn't show up on any URL in that window, it counts as fixed. Results take about a month, so don't panic when nothing changes the next day. If you haven't set up Search Console yet, start with "[Your First Hour in Google Search Console](/blog/en/search-console-first-hour/)." ### Keeping it in one place If you'd rather run a page audit and a speed check together, [LinkSurge](https://linksurge.jp/)'s [AI Ready diagnostic](https://linksurge.jp/ai-ready) can run a mobile and desktop speed analysis alongside its page checks. The numbers come from PageSpeed Insights, so the field-versus-lab distinction above still applies. > References: > [About PageSpeed Insights - Google for Developers](https://developers.google.com/speed/docs/insights/v5/about) > [Core Web Vitals report - Search Console Help](https://support.google.com/webmasters/answer/9205520?hl=en) > [Web Vitals - web.dev](https://web.dev/articles/vitals) --- ## 6. Where to Look When the Numbers Are Bad You'll probably hand the actual fixes to a developer or agency. Knowing the usual suspects still makes that conversation much faster. Here are typical causes from web.dev's optimization guides. | Metric | Common causes | How to brief your developer | |:--|:--|:--| | LCP | The first visible image is too large, it's set to lazy-load, or the server responds slowly | "Can you check the size and loading of the main image, and our server response time?" | | INP | Heavy JavaScript work keeps the page from responding to input | "Taps feel slow to respond. Can you look for long-running scripts?" | | CLS | Images or videos without set dimensions, ads or embeds that resize, web fonts swapping in | "The layout jumps while loading. Can you set image dimensions and reserve space for ads?" | When I reworked some of our own pages, the first wins were boring. Setting image width and height. Removing embeds nobody used. That alone often calms CLS down. After any fix, keep a record of how rankings and traffic move. If you want daily rankings for specific keywords under the same conditions, a tool like [LinkSurge](https://linksurge.jp/)'s [rank tracker](https://linksurge.jp/features/ranking-dashboard/) can do that. Just remember section 4: rankings not moving right after a speed fix is perfectly normal. > References: > [Optimize Largest Contentful Paint - web.dev](https://web.dev/articles/optimize-lcp) > [Optimize Interaction to Next Paint - web.dev](https://web.dev/articles/optimize-inp) > [Cumulative Layout Shift (CLS) - web.dev](https://web.dev/articles/cls) --- ## 7. Common Misconceptions and Mistakes Speed comes with numbers, and numbers invite myths. Here are five I see often. ### Myth 1: "A 100 in PageSpeed Insights will boost my rankings" That score is a lab simulation, not the Core Web Vitals verdict. And Google says even good Core Web Vitals don't guarantee top rankings. Spending weeks pushing a score from 80 to 95 is often time better spent on your content. ### Myth 2: "It's fast on my computer, so it's fine" Google reads the mobile version and judges mobile and desktop separately. Testing on a fast office connection tells you nothing about someone on a phone in a train station. ### Myth 3: "Trimming text on mobile is more user-friendly" Google asks for the same content on mobile as on desktop and warns of traffic loss if you show less. If readability is the goal, fold content away rather than cutting it. ### Myth 4: "My rankings dropped, so my site must be too slow" Speed is one input among many, and Google says relevance comes first. When rankings fall, check for tracking glitches, technical breakage, and algorithm updates before you blame speed. ### Myth 5: "I'll just run the Mobile-Friendly Test" Google retired Search Console's Mobile Usability report, the Mobile-Friendly Test tool, and its API on December 1, 2023. Google stressed that mobile usability still matters and pointed to other resources such as Chrome's Lighthouse. If an old tutorial tells you to use those tools, it's out of date. > References: > [Understanding page experience in Google Search results - Google Search Central](https://developers.google.com/search/docs/appearance/page-experience) > [Mobile site and mobile-first indexing best practices - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) > [The role of page experience in creating helpful content - Google Search Central Blog](https://developers.google.com/search/blog/2023/04/page-experience-in-search) --- {{linksurge-card}} ## Quick Check ### Q1: Name the three Core Web Vitals and what each one measures. Answer: LCP measures how long the main content takes to appear, INP measures how quickly the page responds to input, and CLS measures unexpected layout shifts. ### Q2: If your PageSpeed Insights Performance score is below 90, have you failed Core Web Vitals? Answer: Not necessarily. The score is a lab simulation. Core Web Vitals are judged on real-user field data from the past 28 days. ### Q3: Will reaching "good" on all three metrics raise your rankings? Answer: There's no guarantee. Google uses Core Web Vitals in ranking, but says good results don't guarantee top positions and the most relevant content is favored. --- ## Frequently Asked Questions ### What are the Core Web Vitals thresholds? The "good" targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. A page passes when at least 75% of real visits meet them, and mobile and desktop are assessed separately. ### What is mobile-first indexing? It means Google uses the mobile version of your page, crawled with a smartphone agent, for indexing and ranking. Google recommends keeping the same content on mobile and desktop. ### Why does Search Console's Core Web Vitals report say "No data available"? There isn't enough real-user data yet. This is common for new or low-traffic sites. In the meantime, PageSpeed Insights lab data can help you spot likely problems. ### Can I improve page speed myself? Some fixes are DIY-friendly: compressing images, setting image dimensions, and removing unused plugins or embeds from your CMS (such as WordPress). Server and script changes need technical skills, so share your numbers with a developer. --- ## Conclusion: Start by Looking at Your Mobile Field Data Once Core Web Vitals are a three-number health check for how a page feels to use. The first step is simple. Run one important page through PageSpeed Insights and read the mobile real-user data. If there isn't any, open Search Console's Core Web Vitals report to see which groups of pages need attention. Speed work shouldn't replace content work. Clear the easy wins, like image dimensions, first. For bigger changes, bring numbers to a developer. This article is part of the series' third set, "Common Mistakes and What to Do When Things Go Wrong." The previous article is "[Keyword Research Basics for Beginners](/blog/en/keyword-selection-basics/)." Up next: "[What Is Structured Data?](/blog/en/structured-data-beginners/)," which covers how to describe your page's content to search engines. For where speed fits among the fundamentals, see "[5 SEO Basics That Haven't Changed in the AI Era](/blog/en/seo-basics-unchanged-ai-era/)." The full reading order is in the "[SEO, GEO and AIO Beginner Curriculum](/blog/en/seo-beginner-curriculum/)," and the "[SEO Glossary for Beginners](/blog/en/seo-glossary-beginners/)" is there when a term trips you up. LinkSurge's [AI Ready diagnostic](https://linksurge.jp/ai-ready) runs mobile and desktop speed analysis alongside its page checks.