Largest Contentful Paint (LCP)
Estimate when the largest visible image or text block finishes rendering in the lab test. Use a slow result to investigate the main content path, assets, and delivery setup.
Core Web Vitals Monitoring
Run daily lab checks for selected public URLs and keep LCP, CLS, FCP, TTFB, TBT, Speed Index, the current verdict, and check time beside your technical SEO workflow. Find regressions and retest focused fixes without mistaking synthetic measurements for real-user field data.
TL;DR
Too Long; Didn't Read
Show summary Hide summary
TL;DR
Too Long; Didn't Read
What Is Core Web Vitals Monitoring?
Screpy runs recurring lab checks for selected public URLs. It reports LCP and CLS with supporting FCP, TTFB, TBT, Speed Index, a lab verdict, and check freshness so teams can find performance regressions, investigate a focused cause, and measure again without confusing synthetic results with real-user field data.
Choose the monitoring scope
- The homepage is included when a project is set up for monitoring.
- Additional public URLs can be added within the allowance of the current plan.
- Each active URL becomes eligible for another scheduled check after one day.
- The exact URL and last-check time remain visible beside the result.
Read the primary lab signals
- Largest Contentful Paint estimates when the main visible content finishes rendering.
- Cumulative Layout Shift measures unexpected movement during the test.
- A lab verdict helps surface URLs that need attention first.
- The verdict is a synthetic diagnostic, not Google's field-data assessment.
Use supporting diagnostics
- First Contentful Paint adds early rendering context.
- Time to First Byte helps narrow the investigation toward initial response delay.
- Total Blocking Time exposes main-thread blocking in the lab.
- Speed Index summarizes how quickly visible content appears throughout the test.
Interpret the result safely
- Lab data should be compared with the same URL and measurement method.
- Total Blocking Time is not Interaction to Next Paint.
- A weak metric narrows an investigation but does not prove the root cause.
- Better page experience supports users without guaranteeing rankings or traffic.
Read the lab metrics behind every checked page.
The report separates loading, visual stability, server response, and main-thread diagnostics so one summary verdict does not hide the signal that needs investigation.
Cumulative Layout Shift (CLS)
Measure unexpected visual movement during the test. Images without dimensions, embeds, fonts, and late content are common places to investigate.
First Contentful Paint (FCP)
See when the first text, image, or other page content is painted. FCP helps narrow down early rendering delays before the main content appears.
Time to First Byte (TTFB)
Review the initial server-response delay observed by the lab check. A slow value can point the investigation toward hosting, caching, redirects, or backend work.
Total Blocking Time (TBT)
Measure how long main-thread tasks block responsiveness in the lab. TBT is a useful diagnostic, but it is not the real-user Interaction to Next Paint metric.
Speed Index
Summarize how quickly visible page content appears throughout the lab test instead of relying on one rendering milestone alone.
Lab performance verdict
Use the Good, Needs Improvement, or Poor verdict to find the selected URLs that need attention first. It summarizes lab results, not Google's real-user assessment.
URL and check freshness
Keep every result attached to its exact public URL and last-check time so an old or unrelated measurement is not used for a current decision.
Keep important pages on a recurring lab-check cycle.
Add representative public URLs and review the latest result after each page becomes eligible for its daily scheduled check. Every verdict stays attached to the tested URL and collection time.
- Monitor the homepage and selected high-value URLs
- Sort checked pages by verdict or URL
- Use the last-check time before acting on a result
Separate Core Web Vitals from supporting diagnostics.
Review LCP and CLS with FCP, TTFB, TBT, and Speed Index. Screpy keeps TBT clearly identified as a lab responsiveness diagnostic instead of presenting it as real-user INP.
- Inspect loading and visual-stability measurements
- Use response and rendering metrics to narrow the next check
- Keep lab and field-data claims distinct
Move from a weak metric to one testable change.
Use the weakest current metric to decide whether to inspect content rendering, layout reservation, server response, assets, or main-thread work. Change one likely cause and measure the same URL again.
- Prioritize business-critical pages and shared templates
- Investigate the page and delivery path before changing code
- Validate the focused fix with a later scheduled result
Turn a slow URL into a testable performance fix.
Keep the URL and measurement method stable, use the weakest metric to narrow the investigation, and validate one change with a later check.
- 01
Choose a representative public URL
Start with the homepage, a conversion page, or one URL from an important template. Monitoring every low-value page creates noise before it creates insight.
- 02
Let the scheduled lab check establish a baseline
Screpy checks eligible monitored URLs on a daily cycle and records the current lab verdict, supporting metrics, tested URL, and check time.
- 03
Follow the weak metric to a focused hypothesis
Use LCP, CLS, FCP, TTFB, TBT, and Speed Index to decide whether to inspect content rendering, layout reservation, server response, assets, or main-thread work first.
- 04
Change one cause and measure again
Deploy the smallest relevant fix, keep the monitored URL stable, and use a later scheduled result to check whether the lab measurement improved.
Monitor the pages where a regression would matter most.
A small, representative URL set is easier to investigate than a dashboard full of low-value pages. Start with business-critical journeys and reusable templates.
Primary landing pages
Monitor pages that introduce the product, service, or campaign because a slow first experience can affect both discovery and conversion work.
Shared page templates
Choose one representative product, category, article, or documentation URL to expose performance problems that may repeat across the same template.
Conversion paths
Keep pricing, signup, lead, and checkout entry pages visible when scripts, embeds, experiments, or third-party tags change their performance.
Release-sensitive pages
Track URLs affected by redesigns, framework changes, new media, tag-manager updates, or delivery changes before rolling the same pattern out more widely.
Interpret lab results without overstating them.
Screpy is designed to make recurring performance checks actionable. These boundaries keep the result accurate when field data, causal diagnosis, or ranking impact is the real question.
Lab data, not field data
Screpy runs controlled page tests. The result does not represent the trailing real-user dataset reported by Chrome UX Report or Google Search Console.
TBT is not INP
TBT helps diagnose lab responsiveness. INP requires real interactions from users, so a TBT result must not be presented as an INP measurement.
A verdict is not a root cause
A poor metric tells you where to investigate. Confirm the actual element, request, script, template, or server behavior before deciding what to change.
Performance is not a ranking guarantee
Good page experience supports users and search quality, but it does not replace relevant content, crawlability, indexing, links, or other search signals.
Use the performance workflow that matches the question.
Monitor selected URLs for recurring lab results, audit the wider website for repeated technical patterns, or read the measurement methodology before comparing Screpy with a field-data report.
Run daily lab checks for selected public URLs and review their current verdict, metrics, and check freshness.
Crawl the wider site to find repeated page, asset, rendering, and technical patterns around an affected URL or template.
Understand the scope, timing, and limits of Screpy lab data before comparing it with real-user field reports.
Screpy documentation
Learn how to interpret lab performance checks
Follow the Screpy guide to choose monitored URLs, read each metric with its URL and date, distinguish lab data from field data, and test a focused improvement.
Related SEO guides
Learn the concepts behind this workflow and apply them with practical SEO guidance.
Page Speed
Core Web Vitals: What They Are and Why They Matter for SEO
Learn what Core Web Vitals are, why they matter for SEO and UX, and how LCP, FID, CLS, and page performance affect website quality.
Read article Page Speed
What is First Contentful Paint? And How To Optimize It!
Learn what First Contentful Paint is, how Google Lighthouse measures FCP, and how faster loading improves Core Web Vitals, UX, and SEO.
Read article Google
What is Page Experience? – Google 2021 Update
Learn what page experience means, why Google updates matter, and how Core Web Vitals, UX, mobile usability, and speed affect rankings.
Read article SEO
What SEO Alerts Should You Monitor Before Traffic Drops
SEO alerts to track in GA4 and Search Console: indexing and crawl errors, ranking volatility, Core Web Vitals shifts, plus security or manual actions.
Read articleCore Web Vitals FAQ
Understand lab versus field data, LCP, CLS, TBT, supporting speed metrics, daily checks, URL selection, verdicts, and the limits of page-experience claims.
What does Screpy Core Web Vitals Monitoring measure?
Screpy runs lab-based checks for selected public URLs. It reports LCP, CLS, FCP, TTFB, TBT, Speed Index, a lab verdict, and the latest check time so teams can identify pages that need a focused performance investigation.
Is Screpy Core Web Vitals data based on real users?
No. Screpy reports controlled lab measurements for the checked URL. Field data from Chrome UX Report or Google Search Console reflects real visits over a rolling collection period and can differ because devices, networks, geography, and user behavior vary.
Which metrics are the official Core Web Vitals?
Google currently defines Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift as the Core Web Vitals. Screpy measures LCP and CLS in its lab checks and reports TBT as a lab responsiveness diagnostic alongside FCP, TTFB, and Speed Index. It does not present TBT as INP.
Why does Screpy show TBT instead of INP?
Interaction to Next Paint depends on real user interactions and is a field metric. Total Blocking Time can be measured in a controlled lab test and helps reveal main-thread work that may make a page slow to respond, but the two metrics are not interchangeable.
How often are monitored URLs checked?
Active URLs become eligible for another scheduled check after one day. Queue activity, page availability, and the current plan can affect when a result is ready, so use the displayed last-check time before acting on it.
Which pages should I monitor first?
Start with the homepage, high-traffic landing pages, conversion entry points, and one representative URL from each important template. Add pages where a regression would affect many visitors or where the same implementation is reused widely.
Does a Good Screpy verdict mean the URL passes Google Core Web Vitals?
Not necessarily. Screpy summarizes a lab check, while Google's Core Web Vitals assessment uses real-user LCP, INP, and CLS data when enough field data is available. Use the Screpy verdict to guide testing, then compare it with the relevant field report when a real-user assessment is required.
Will improving Core Web Vitals guarantee higher rankings?
No. Google recommends good Core Web Vitals for users and Search, but page experience is only part of a much broader set of signals. Relevant content can still rank with weaker page experience, and a fast page is not guaranteed to rank.