Primary landing pages
Monitor pages that introduce the product, service, or campaign because a slow first experience can affect both discovery and conversion work.
Core Web Vitals Monitoring
Track LCP, CLS and loading diagnostics for selected public pages on your project domain. Review five metrics per URL and a separate homepage summary with Speed Index, then check a focused fix against a later lab result. These are controlled tests, not real-user field data.
Core Web Vitals checks
LCP
Find selected URLs where the main content appears late.
CLS
Review unexpected layout movement on selected URLs.
Daily lab checks
Record the current values and review a later lab result after a focused fix.
Monitor Largest Contentful Paint
Largest Contentful Paint measures when the largest eligible image, text block or video becomes visible in the test viewport. Use the LCP value for each monitored URL to decide which page needs a closer loading investigation.
- Screpy displays LCP in seconds: up to 2.5 s is good, above 2.5 s through 4 s needs improvement, and above 4 s is poor.
- A quick FCP followed by a slow LCP means some content appeared before the main element. Investigate that element's delivery and rendering rather than assuming the entire page was blank.
- Confirm the relevant image, font or rendering delay with a developer's performance inspection. The number alone does not identify the element or prescribe a fix.
example.comLab
LCP2.1 s
Measure Cumulative Layout Shift
A page can load quickly and still move a button or paragraph unexpectedly. Cumulative Layout Shift gives each monitored URL a lab stability score so you can investigate movement separately from loading speed.
- CLS has no time unit: up to 0.1 is good, above 0.1 through 0.25 needs improvement, and above 0.25 is poor in Screpy.
- Review reserved space for images, ads and embeds, as well as font changes. These are investigation candidates; Screpy's score does not identify which element moved.
- A low loading-test CLS cannot rule out shifts that happen later during a visitor's session. Check the actual interaction and field evidence when the problem appears after loading.
CLS
0.04Check Total Blocking Time
Total Blocking Time helps you spot main-thread work that can delay input during loading. Read the TBT value alongside LCP and FCP: content appearing quickly does not necessarily mean the page can respond promptly.
- TBT is displayed in milliseconds: up to 200 ms is good, above 200 ms through 600 ms needs improvement, and above 600 ms is poor.
- Blocking time adds the portions of long tasks beyond 50 ms during the measurement window. It is not the total time spent running JavaScript.
- If TBT is high, profile long tasks and unnecessary scripts with developer tools before changing code. The dashboard value does not attribute the delay to a particular script.
- TBT is not INP. INP measures interactions and can be tested in a lab with those interactions; this Screpy feature does not report an INP measurement.
example.comLab
TBT180 ms
Compare FCP and TTFB
First Contentful Paint marks the first visible content; Time to First Byte marks the start of the response. Reading both for the same URL helps you separate an early response delay from time spent getting content onto the screen.
- FCP is shown in seconds: up to 1.8 s is good, above 1.8 s through 3 s needs improvement, and above 3 s is poor.
- TTFB is shown in milliseconds: up to 800 ms is good, above 800 ms through 1,800 ms needs improvement, and above 1,800 ms is poor. Connection, redirect and response behavior can all affect it.
- If TTFB is low but FCP is slow, investigate what holds up the first paint. If the response is slow, examine delivery first; neither value by itself proves a backend or rendering cause.
Lab2,100 ms
TTFB450 ms
FCP1,100 ms
LCP2,100 ms
TBT95 ms
Monitor Important Website Pages
Track a manageable set of public pages from your project rather than treating a single homepage result as the whole site. Use the plan's project allowance for pages where loading or layout problems would matter most.
- The project homepage is added when the project is created. Add further public URLs from the project domain or its subdomains when your plan allows monitoring.
- Choose representative product, category, article and conversion-entry pages. A repeated template problem can justify wider investigation, but one tested URL does not measure every page using that template.
- URL entry normalizes the scheme and host, adds HTTPS when omitted and removes fragments. Paths and query strings remain significant, and a duplicate normalized URL is rejected.
- An added page waits for its first scheduled check before appearing in the results table. Adding the URL does not run an immediate test.
- Confirm removal to stop tracking a page and free its place in the allowance. This removes the monitored record, not the page from your website or Google.
example.comLab
/1.4 s/shop/linen2.8 s/guides/seo1.9 sReview Homepage Performance
The summary above the URL table uses the project's checked homepage. It brings the current lab measurements together, including Speed Index, while the table beneath it keeps the five displayed metrics tied to each monitored URL.
- Read FCP, LCP, CLS, TTFB, TBT and Speed Index in the homepage summary. These are homepage values, not an average across the tracked pages.
- Speed Index describes how quickly visible content builds up during loading. Screpy shows seconds: up to 3.4 s is good, above 3.4 s through 5.8 s needs improvement, and above 5.8 s is poor.
- Each summary bar represents the current measurement. It is not a saved trend chart, a percentage of visitors or Google's 75th-percentile field result.
- If the homepage has no checked result, its overview is unavailable. A result from another monitored URL is not substituted for it.
example.comLab
LCP2.1 s
TBT180 ms
CLS0.04
Follow Daily Lab Checks
Active eligible pages become due for another scheduled check after a day. Review the current result after a focused change, allowing for plan eligibility and check availability rather than expecting a test at an exact clock time.
- Sort the results by page URL or CWV status to organize your review. FCP, LCP, CLS, TTFB and TBT remain visible per tested URL.
- The CWV badge uses the worst available LCP, CLS and TBT classification. PASS means that available subset is good; FAIL includes both needs-improvement and poor results.
- Inspect missing values even when a row says PASS. An absent metric is not included as a healthy measurement, and the badge does not certify Google's field-based LCP, INP and CLS assessment.
- No data means the lab verdict is unavailable. A missing displayed value is not zero, and an unsuccessful check is not proof of a healthy page.
- Record the current values before deploying a fix, then compare them with a later result for the same URL. The table shows current results rather than a saved before-and-after history.
Daily09:00
123456789101112131415161718192021
Read Performance Data with SEO MCP
Bring the saved homepage lab overview into an AI conversation or a REST integration. Ask for an explanation of the available measurements and a focused investigation, with the evidence kept separate from a proposed fix.
- Authenticate and select a project you can access. The REST endpoint also requires Core Web Vitals availability on the project's plan.
- The response contains the homepage URL, saved check time and available FCP, LCP, CLS, TTFB, TBT and Speed Index values. This is homepage evidence, not a list of every monitored page.
- A missing checked homepage returns no overview; individual missing measurements remain unavailable. Ask the assistant to identify gaps before drawing conclusions.
- The Core Web Vitals MCP tool reads saved data. It does not start a new test, add monitored pages, identify the responsible element or turn a TBT value into INP.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Talk about Core Web Vitals. With SEO MCP.
Read your project's saved homepage lab overview through SEO MCP. Explain available metrics with the homepage URL and check time, then choose what to investigate without claiming an all-page report or a new test.
- Screpy: Hello! Let’s look at Core Web Vitals for example.com. What would you like to know?
- You: Explain the saved homepage lab results for example.com and identify what is still unknown.
- Screpy: In this illustrative homepage result, LCP is 3.2 s and needs improvement; CLS is 0.04 and good. Check the saved URL and check time before using the values. These two numbers do not show every metric, measure INP or identify the responsible element. I can suggest an investigation, not perform a new test. Example homepage lab values: LCP: 3.2 s. CLS: 0.04.
- You: Turn that into a short action plan.
- Screpy: I’ll keep the evidence and recommendations separate. Review the findings, choose one change and check the results afterward. Your next steps: Review: Check the source and date of each finding.. Decide: Choose the first change to make.. Verify: Compare the results after the change..
- You: Can you explain the evidence in plain language?
- Screpy: Yes. Ask about a supported result and I can explain what it shows, where it comes from and what is still uncertain. Missing data stays unavailable; recommendations are not automatic fixes.
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.
-
Choose a representative public URL
Choose public URLs on the project domain or its subdomains. Start with the homepage, a conversion-entry page and a representative URL from an important template, within the project's plan allowance.
-
Let the scheduled lab check establish a baseline
Eligible active URLs receive recurring scheduled lab checks. After the first attempt, review the available FCP, LCP, CLS, TTFB and TBT values for the tested URL; the separate homepage summary also includes Speed Index.
-
Follow the weak metric to a focused hypothesis
Use the weak metric to choose a specific investigation: LCP for main-content loading, CLS for unexpected movement, TBT for blocking work, and FCP with TTFB for early loading. Homepage Speed Index adds visual-progress context, not proof of a cause.
-
Change one cause and measure again
Record the current values before a focused change, keep the tracked URL stable, then compare a later scheduled result. The panel shows current measurements, so retain your earlier baseline separately and investigate repeated changes rather than treating one fluctuation as proof.
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.
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 describes blocking work during the measured loading period. INP requires interaction measurements and can be tested in a lab with interactions, but this Screpy feature does not report INP or replace real-user responsiveness evidence.
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.
Monitor selected public project URLs with recurring lab checks; review five table metrics and the separate six-metric homepage summary.
Crawl the wider website for links, images and on-page issues around an affected URL or template. Use those findings as technical context, not as a performance trace.
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
Use the guide to select monitored URLs, read the lab metrics and distinguish them from field data. Record a baseline separately before checking a focused improvement against a later result.
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 Google
What Is Page Experience? Core Web Vitals and UX
Learn what page experience means, why Google updates matter, and how Core Web Vitals, UX, mobile usability, and speed affect rankings.
Read article Page Speed
How Do Soft Navigations Affect Core Web Vitals?
Learn how soft navigations affect LCP, INP, and CLS in experimental CrUX data, compare reports, and separate measurement changes from real speed gains.
Read article SEO
How to Fix Render-Blocking Resources
Fix render-blocking resources using critical CSS, defer/async JavaScript, and preload hints to improve Lighthouse audits and Core Web Vitals on real pages.
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.
Which pages should I monitor first?
Start with the homepage, important public landing pages, conversion-entry pages and one representative URL per important template. Added URLs must belong to the project domain or its subdomains and fit the plan allowance. Monitoring a template sample does not test every page using that template.
Why does Screpy show TBT instead of INP?
This feature measures page loading and provides TBT as a blocking diagnostic; it does not measure the interactions needed for INP. INP can be tested in a lab by performing interactions, but a TBT value is not an INP value and does not describe every interaction after loading.
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.
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.
How often are monitored URLs checked?
Active eligible URLs become due for another scheduled check after one day. Your project's plan and check availability affect completion, so this is not a guarantee of a result at the same clock time every day. A new URL appears in the results table after its first check attempt.
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.
What does Screpy Core Web Vitals Monitoring measure?
Screpy's monitored-URL table shows lab FCP, LCP, CLS, TTFB and TBT. The checked homepage summary adds Speed Index. The table uses a lab PASS/FAIL verdict; authenticated API and MCP responses also expose the saved homepage URL and check time. These are not real-user field measurements.
Does a Screpy PASS mean the URL passes Google's Core Web Vitals?
No. Screpy's table verdict uses the worst available lab LCP, CLS and TBT classification and can still have missing values. Google's field assessment uses real-user Core Web Vitals data, including INP, with its own coverage and percentile rules. Inspect the available metrics and the relevant field report before drawing that conclusion.