How Core Web Vitals Checker Works
Core Web Vitals Checker is suitable for initial page checks, post-technical checks, and comparing mobile and desktop versions. To check website speed online, simply enter the desired URL, run the analysis, and analyze the results by individual metrics, rather than relying solely on the overall score.
The Core Web Vitals Checker checks metrics related to content rendering speed, interface responsiveness, and layout stability. This core web vitals test helps understand how smoothly a page operates for the user and at what point noticeable delays occur.
Checking core web vitals is especially useful when combined with additional performance metrics. The final report should be read sequentially: first, Core Web Vitals, then server response, critical resource loading, images, CSS, JavaScript, and other elements that may impact the results.
What does the Core Web Vitals check show?
The current set of Core Web Vitals includes Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Each metric addresses a specific aspect of the user experience, so a good result in one metric doesn't necessarily correct a problem in another.
If real user data is available, it's best to use the 75th percentile for the score. A lab test is more convenient for identifying the root cause, re-diagnosing after fixes, and comparing two versions of the same page under similar conditions.
Largest Contentful Paint – LCP
Largest Contentful Paint indicates the moment the largest visible element of the main content appears. This is most often the overlay image, a large banner, a headline, or another prominent block.
A good benchmark is an LCP of up to 2.5 seconds. This figure can deteriorate due to a slow server response, a heavy hero image, late loading of critical resources, unnecessary CSS, or incorrect loading priority of the main element.
Interaction to Next Paint – INP
Interaction to Next Paint measures how quickly a page visually responds after a click, tap, or other user action. A good INP value is considered to be up to 200 ms at the 75th percentile.
Lag is often caused by large amounts of JavaScript, long main-thread tasks, heavy event handlers, and third-party libraries. The longer the browser spends performing calculations, the longer it will take the user to see the interface respond.
Cumulative Layout Shift – CLS
Cumulative Layout Shift evaluates the visual stability of a page. A high CLS occurs when text, buttons, images, or banners unexpectedly change position after the page has already started loading.
A CLS of up to 0.1 is considered good. Typical causes of this problem include images without specified dimensions, late font loading, dynamic inserts, and blocks for which space in the layout has not been reserved in advance.
How to read PageSpeed and Core Web Vitals results?
The final Performance Score is convenient for quick comparison, but a single number is insufficient for technical conclusions. Website performance is best assessed using specific metrics, real user data, and recommendations related to the root cause of the problem.
The page speed checker should be used as a starting point for diagnostics. After the report, identify the failing metrics, understand the origin of the data, and only then develop a plan for technical corrections.
What do good, average, and bad scores mean?
For the Core Web Vitals, thresholds are used to classify results as good, needs improvement, or poor. For field data, the 75th percentile of actual page loads is used.
| Metrics | Fine | Needs improvement | Badly |
|---|---|---|---|
| LCP | up to 2.5 s | more than 2.5 to 4 s | more than 4 s |
| INP | up to 200 ms | more than 200 to 500 ms | more than 500 ms |
| CLS | up to 0.1 | more than 0.1 to 0.25 | more than 0.25 |
The table helps quickly identify the direction of work, but the same value can have different causes. For example, a poor LCP can be related to the server, image, CSS, JavaScript, or resource loading sequence.
How is Field Data different from Lab Data?
Field Data reflects page performance for real visitors across different devices and connections. The source may be the Chrome User Experience Report, our own Real User Monitoring, or another system for collecting actual user measurements.
Lab Data is obtained in a controlled environment through a synthetic test or other lab scenario. This type of lab test is convenient to run immediately after editing, as there's no need to wait for new real-user statistics to accumulate.
What is the Chrome User Experience Report (CrUX)?
The Chrome User Experience Report, or CrUX, contains aggregated, real-world data from Chrome users. It helps evaluate user experience and compare actual page metrics with lab results.
CrUX isn't available for every URL, as individual pages may lack the necessary data. In such cases, core web vitals testing continues with lab measurements, but this result should be viewed as a diagnostic snapshot.
Why do the results of different tests differ?
Results depend on the device, network, test server location, cache status, current backend load, and third-party services. The same resource may respond at different speeds even in two consecutive runs.
That's why website speed tests and pagespeed checkers sometimes show different results for the same URL. It's more useful to compare multiple tests performed using the same methodology, especially if the goal is to evaluate the results of technical improvements.
I don't rely solely on the overall PageSpeed score. I first look at the actual Core Web Vitals—LCP, INP, and CLS at the 75th percentile—and then use the lab report to identify the cause. A high lab score alone doesn't guarantee good performance with real visitors.
What affects page loading speed?
Checking page load speed is only useful when the cause of the delay is clear beyond the numbers. Page performance is simultaneously impacted by the server, images, styles, scripts, fonts, third-party services, and the resource loading sequence.
It's best to analyze website speed from server response to display and interactivity. This order helps eliminate major issues first, and then address low-impact recommendations.
Server and TTFB
A slow server response delays the entire download. This could be due to complex database queries, a lack of caching, an overloaded server, slow server rendering, or a large distance from the user.
To diagnose the issue, we check the backend, cache, CDN, database, and HTML rendering time. If the server takes too long to respond, image optimization won't eliminate the underlying latency, as the browser receives the source document late.
Images and media content
Large images often increase page weight and degrade LCP. It's best to use real display sizes, responsive images, WebP or AVIF formats, and optimized files without unnecessary quality.
Lazy loading is suitable for content below the fold, but it can't be automatically applied to LCP images. Critical images sometimes require preload or a higher priority so the browser can begin loading them sooner.
CSS and JavaScript
Render-blocking resources can delay page rendering, and large amounts of JavaScript increase the load on the main thread. During the audit, look for unused CSS, unnecessary code, large bundles, and long-running browser tasks.
Defer and async help defer execution of some scripts if it's safe for the page logic. Any changes should be tested after implementation to ensure optimization doesn't break forms, menus, analytics, or other features.
Fonts
A large number of fonts increases the number of requests and the size of downloaded files. To optimize fonts, unneeded variants are reduced, font-display is used, and preload is used when necessary for critical files.
Fonts also affect visual stability. If text sizes change after loading, adjacent elements may shift, so font performance should be checked in conjunction with CLS.
Third-party scripts
Analytics, advertising, online chats, maps, call tracking, and other external services add network requests and JavaScript. With numerous integrations, pages may take longer to load and respond more slowly.
There's no need to remove every third-party service. First, check its actual impact, then adjust the startup time, remove duplicates, or replace an overly heavy solution with a more suitable one.
What we actually did
Dental clinic · Kyiv and Chernihiv
+44% clicks from search
A domain with no history on a website builder. We built the semantic core for both cities, reworked the landing pages and built the link profile from zero. Four months: 34.8k clicks, impressions 1.32 → 1.76M, DR 0 → 41.
E-commerce · international
+96% clicks in two months
A catalog of digital 3D models. We clustered the semantics, rebuilt the hub pages and closed duplicates and indexing errors. Google users 247 → 532, CTR 2.4% → 4%.
Medical center · Ukraine
+68.75% visibility in the first month
Narrow visibility and a small semantic core at the start. Semantics, landing page structure, metadata and internal linking, then gradual link building.
Answers to your questions
How to check website speed online?
Enter the full page URL and run the check. After analysis, compare LCP, INP, CLS, and additional metrics, then view the mobile and desktop versions separately.
If you need to check your site's speed online after a technical change, use the same URL and comparable conditions. This will make it easier to attribute the results to the change.
What are Core Web Vitals?
Core Web Vitals is a set of Google metrics for assessing core content loading, interface responsiveness, and visual stability. The current set includes LCP, INP, and CLS.
The former First Input Delay, or FID, is no longer included in the current Core Web Vitals. Its place in the current responsiveness assessment is taken by INP.
What Core Web Vitals metrics are considered good?
Good benchmarks include LCP up to 2.5 seconds, INP up to 200 ms, and CLS up to 0.1. For field data, these values are considered at the 75th percentile of user loads.
If one metric is outside the acceptable range, the cause of this deviation should be investigated first. Simultaneously correcting all recommendations complicates the verification of the results.
How are Core Web Vitals different from PageSpeed Score?
Core Web Vitals measure individual components of the user experience, while PageSpeed Performance Score represents a lab-based assessment of multiple metrics.
A high overall score does not automatically indicate good field data from real visitors. Therefore, these metrics should be analyzed separately.
Why is website speed slower on mobile than on desktop?
Mobile devices are more sensitive to processor power, connection quality, and the amount of JavaScript. The responsive version may also load different images, menus, or interface elements.
If the difference is noticeable, you need to check the resources of the first screen, third-party scripts, and the operation of the interface specifically in mobile mode.
Why does PageSpeed show different results when I re-check it?
Results depend on the network, cache, server load, third-party services, and the timing of the test. Therefore, slight differences between consecutive lab measurements are considered normal.
To draw conclusions, it's best to look at several comparable runs and a consistent trend. A single test doesn't describe page performance under all conditions.
Why is there no Core Web Vitals data for this page?
Some URLs may be missing user data in the Chrome User Experience Report. This is often the case with new or rarely visited pages.
The page can still be tested in a lab setting and Real User Monitoring can be enabled if necessary. This data simply can't be completely compared to CrUX.
Do Core Web Vitals Impact SEO?
Core Web Vitals are considered by Google as part of its overall user experience assessment, but they alone do not guarantee high rankings. Organic traffic also requires relevant content, proper indexing, and a technically sound website.
Therefore, speed testing remains a part of technical SEO. It complements other work, not replaces it.
Related services
CMS Detector / Detect a site CMS
Identify a website's CMS online by domain or URL. CMS Detector checks for engine features, popular platforms, and web technologies and displays results in seconds.
Indexability check
Check if your page is indexable by Google: robots.txt, noindex, canonical, HTTP status, and other technical indicators. Online URL indexability checker.
Google index check
Check if a URL or website page is indexed in Google. Methods include Search Console, site:, the bulk checker, and reasons why pages are not indexed.
HTTP Status Checker
HTTP Status Checker by Seo-Gen: check URL response codes, redirects, and 4xx/5xx errors online. Suitable for single-page and bulk URL checking.
Broken Link Checker
Broken Link Checker by Seo-Gen: Find broken and inactive links, 404 errors, and problematic URLs on your website. Online verification of internal and external links.
Robots.txt Checker
Robots.txt Checker for online robots.txt file analysis and verification. Find Allow, Disallow, and User-agent errors, and check URL accessibility for Googlebot and other search robots.
Sitemap Checker
Sitemap Checker from Seo-Gen checks your XML sitemap online: structure errors, URLs, sitemap index, lastmod, limits, and accessibility. Find issues before submitting your sitemap to Google.
Robots Meta Checker
Meta robots Checker checks Meta Robots and X-Robots-Tag, detects noindex, nofollow, and directive conflicts. Paste the URL and check the page settings.
Canonical Checker
Canonical Checker Online: Check rel=canonical, target URL, HTTP status, and common page canonicalization errors. Quick canonical check for SEO.
Hreflang Checker
Hreflang Checker by Seo-Gen: Check hreflang, x-default, canonical, language and region codes, backlinks and URL errors online.
Core Web Vitals Checker helps you quickly assess the performance of a specific page, checking LCP, INP, CLS, and additional metrics, and then proceeding to a technical diagnosis of the cause. The most useful picture is provided by a combination of lab testing, CrUX, and real user data, when available.
Enter the page URL, run a site speed test, and compare the results for mobile and desktop. It's best to start fixing the metrics and issues that most impact the actual user experience.
We reply within one business day. No newsletters, no “just a reminder” calls.
He will look at the site himself instead of passing it to a manager.
More on: Core Web Vitals Checker – website speed test
How to check website speed online?
A full technical audit isn't necessary for initial diagnostics. You can run a page speed test online, obtain basic values, and see which resources or loading stages are causing the most noticeable delays.
This type of website speed test is useful after a redesign, template change, migration to a new server, enabling analytics, or image optimization. A retest allows you to compare the page's performance before and after a specific modification.
How to run PageSpeed test?
Enter the full URL of the desired page and run the pagespeed test online. After the analysis is complete, compare key metrics, check mobile and desktop separately, and then open the recommendations for any issues found.
The working order of the inspection:
- Enter the full address of the desired page with the correct protocol and language version.
- Run the analysis and wait for the results to be generated for the main metrics.
- Compare the mobile and desktop versions if the report separates these data.
- Find the issues that most impact loading and interaction.
- After making the corrections, repeat the site speed test and compare the new values.
A single pagespeed checker shows the page's performance under specific launch conditions. For important URLs, it's best to look at several comparable measurements and verify whether the improvement persists after changes.
What exactly does a website speed test check?
A website speed test examines multiple stages of page loading, rather than a single, abstract speed. A website speed checker helps determine where the problem occurs: on the server side, during the initial content display, or after JavaScript execution.
In addition to Core Web Vitals, reports may also include First Contentful Paint, Time to First Byte, Total Blocking Time, and other metrics. These metrics describe different stages of loading, so each metric should be interpreted separately.
First Contentful Paint – FCP
First Contentful Paint indicates the moment when the browser first displays a noticeable portion of the page's content. This could be text, an image, or another visual element that informs the user that loading has begun.
FCP is not included in the current Core Web Vitals set. A high value may indicate a slow server response, blocking CSS, delayed font loading, or other resources that prevent content from rendering early.
Time to First Byte – TTFB
Time to First Byte shows the time it takes to receive the first byte of a server response. TTFB is affected by backend performance, database, caching, CDN, network, and server geographic location.
A high TTFB can degrade subsequent loading times, including LCP. Therefore, website speed analysis should begin with the server side if latency occurs before the first content is displayed.
Total Blocking Time – TBT
Total Blocking Time shows how much time the browser's main thread was occupied by long tasks. In lab diagnostics, TBT helps identify heavy JavaScript scripts and calculations that hinder page responsiveness.
TBT is not a current Core Web Vital. A high value typically requires checking large JavaScript bundles, third-party libraries, unnecessary calculations, and scripts that take too long to execute on the main thread.
Checking the mobile and desktop versions
The same page can show significantly different results on mobile and desktop. Mobile devices typically have a slower processor, a different connection, and are more responsive to heavy JavaScript, large images, and third-party widgets.
A website speed test should consider both versions. If mobile is noticeably slower than desktop, it's worth checking responsive images, the size of scripts, the loading sequence of critical resources, and the functionality of adaptive interface elements.
How to improve Core Web Vitals after verification?
After a core web vitals test, it's better to focus on a specific failed metric rather than trying to implement all the recommendations at once. First, identify the root cause, then check the scope of the problem, and only then make changes.
After each significant set of edits, it's useful to run a site speed test again. This comparison shows which optimizations actually impacted the results and which issues remain.
How to improve LCP?
First, you need to determine the element that is considered the Largest Contentful Paint. Then, you check the TTFB, resource size, its loading priority, critical CSS, caching, and the presence of blocking requests.
If the LCP is related to a hero image, file size, format, and the start time of the download are typically checked. If the delay originates on the server, the backend, cache, and HTML rendering time are prioritized.
How to improve INP?
To improve INP, you need to identify long-running tasks that occupy the main thread during interaction. Common causes include large JavaScript files, heavy event handlers, complex rendering, and external libraries.
Large tasks are separated, unnecessary calculations are reduced, and user action handlers are tested separately. Particularly careful testing is required for forms, filters, menus, and other elements that visitors interact with regularly.
How to reduce CLS?
Images and videos should be pre-sized, and space should be reserved in the layout for ads and dynamic content. This way, the appearance of a new element doesn't force existing content to shift position abruptly.
Additionally, you should check fonts, notifications, banners, and blocks added above existing content. If an element is loaded later, its future area should be planned for in advance.
In what order should errors be corrected?
First, they fix failed Core Web Vitals and issues that recur across a large number of pages. Then they move on to slow server responses, critical resources, images, JavaScript, and third-party services.
Optimal order of work:
- Fix critical LCP, INP, and CLS issues on primary landing pages.
- Check for template errors that affect a large number of URLs at once.
- Eliminate server latency, caching, and loading of critical resources.
- Optimize images, styles, JavaScript, and heavy third-party integrations.
- Repeat the site speed analysis and compare the results with the original values.
After such a cycle, it's easier to understand the real impact of edits. Secondary recommendations should be implemented after issues that significantly impact users and are repeated on key pages.
Core Web Vitals and SEO
Core Web Vitals are taken into account by Google's systems and are linked to the quality of the page experience. However, a page's search ranking depends on multiple signals. Good speed does not replace relevant content, proper indexing, site structure, and internal linking.
For SEO, performance is especially important on pages that receive organic traffic or participate in conversion scenarios. Technical optimization should improve the real user experience, not just pursue maximum numbers in a single test.
Does website speed affect Google rankings?
Speed and Core Web Vitals may be considered in rankings, but good metrics don't guarantee a top spot. Performance Score shouldn't be considered a standalone factor that can compensate for weak content or inappropriate search query performance.
Website speed testing is part of technical SEO monitoring and helps eliminate obvious user experience issues. Afterwards, the page still needs to be assessed based on intent, content, indexation, and other SEO factors.
Why is speed important besides SEO?
A fast page displays content earlier, responds more quickly to actions, and is less likely to irritate users with unexpected changes. This impacts catalog browsing, form completion, filtering, order submission, and other post-click actions.
Delays are especially noticeable on mobile devices and unstable connections. Therefore, website speed testing is useful for monitoring product quality after releases, regardless of the page's current search ranking.
PageSpeed Insights, Lighthouse, and Search Console – What's the Difference?
Google PageSpeed Insights, Lighthouse, and Search Console offer different performance insights. The first is useful for checking a specific URL, the second helps with lab diagnostics, and the third shows the status of groups of pages based on Google data.
The proprietary Core Web Vitals Checker is convenient for a quick initial analysis. Once a problem is identified, you can move on to a more in-depth diagnosis and compare results from different sources.
PageSpeed Insights
Google PageSpeed Insights combines field data, when available, with Lighthouse lab diagnostics. The service is suitable for a quick page check and helps you see Core Web Vitals, Performance Score, and technical recommendations.
It's convenient to run an online page speed test after modifications or during an initial URL audit. For long-term evaluation, it's best to supplement the results with real user data.
Lighthouse
Lighthouse conducts a lab audit and calculates a Performance Score based on a set of metrics. It's convenient for developers to reproducibly check a page after changes to the code, template, or resource loading.
Laboratory data are useful for identifying causes, but they are not a substitute for CrUX or RUM. For a complete assessment, it's best to compare both types of measurements.
Google Search Console
Google Search Console displays a Core Web Vitals report for groups of similar pages. This report helps you identify large-scale issues that recur across category templates, cards, articles, and other URL types.
Search Console isn't enough to pinpoint a specific cause. The problematic page is then checked using a specialized tool and individual metrics analyzed.
When do you need your own Core Web Vitals Checker?
A custom checker is useful when you need to quickly check a URL, get basic metrics, and determine further diagnostics. This scenario is convenient for an SEO specialist, developer, or website owner after making changes to a page.
A website speed checker can be used before a technical audit, after a release, or when checking a problematic template. It shortens the process from detecting a slow page to assigning a specific task to the developer.
When should I re-run a website speed test?
A re-check is necessary after a redesign, template update, transfer to a different server, adding new scripts, changing images, or major frontend improvements. Any such change can impact page loading and interaction.
The test should be run after fixing the identified issue and comparing the results with the original data. For key pages, it's advisable to supplement a one-time site speed test with regular monitoring, as a single successful run doesn't reflect the site's condition over a long period.