Revenue and signup pages
Monitor checkout entry points, pricing pages, lead forms, and signup routes where a slow experience can interrupt a high-value visit.
Website PageSpeed Monitoring
Monitor important public URLs with recurring lab checks. Review loading, response delivery, blocking and layout stability in Screpy's Core Web Vitals screen, with a separate six-metric homepage overview.
PageSpeed measurement signals
FCP
See when initial content first appears on a selected URL.
TTFB
Review time to the first response byte, including connection and delivery delays.
TBT and Speed Index
Review main-thread blocking and the homepage's visual loading progress.
Choose Pages to Monitor
Build a useful PageSpeed monitoring set around the pages people actually enter. Screpy includes the project homepage and lets you add public URLs on your project domain or its subdomains.
- Use your plan's remaining allowance for important landing pages, product pages and representative templates.
- Paths and query strings identify different monitored URLs; fragment anchors are removed and duplicate entries are rejected.
- Check public entry pages rather than expecting a lab check to complete a login, checkout or signup journey.
- Remove a URL when it no longer needs monitoring; this stops its checks without deleting the website page.
example.comLab
/1.4 s/shop/linen2.8 s/guides/seo1.9 sRun Daily PageSpeed Checks
Manage these checks in the Core Web Vitals screen of your Screpy project. Recurring checks keep selected pages under review as content, templates and scripts change.
- An added URL appears in the results table after its first check attempt; adding it does not trigger an instant result.
- Active URLs in eligible projects can receive another scheduled check once the saved attempt is at least one day old.
- Processing time and metric availability can vary. The table has no last-check date or immediate-retest control.
Daily09:00
123456789101112131415161718192021
Review URL Speed Results
Read the individual measurements beside the exact page URL before deciding what needs attention. A status badge provides a quick starting point, while the values reveal different parts of the loading experience.
- Each URL row shows FCP and LCP in seconds, TTFB and TBT in milliseconds, and unitless CLS.
- Sort by URL or status to review the monitored set; metric columns are not sortable.
- The lab status uses the worst available LCP, CLS or TBT classification. Slow FCP or TTFB can still deserve attention when that status passes.
- Missing values are unavailable measurements, and a partial pass is not Google's real-user Core Web Vitals assessment.
example.comLab
LCP2.1 s
TBT180 ms
CLS0.04
Investigate Loading Delays
Use the pattern across metrics to choose a focused investigation. Screpy supplies timing and stability signals, while your team checks the page implementation to confirm a cause.
- High TTFB can justify checking redirects, connection timing, caching and response delivery; it is not a measurement of backend execution alone.
- Low TTFB with slow FCP can point the investigation toward early rendering; delayed LCP can justify examining the main content and its delivery.
- High TBT calls for checking long main-thread tasks. It measures their blocking portions, not all JavaScript runtime or INP.
- Elevated CLS calls for checking unexpected layout movement, such as space that was not reserved for arriving content.
- Use a browser performance trace for exact element or script attribution; the Screpy table does not identify those causes.
Lab2,100 ms
TTFB450 ms
FCP1,100 ms
LCP2,100 ms
TBT95 ms
Check Homepage Speed Index
The homepage overview adds Speed Index to FCP, LCP, CLS, TTFB and TBT. Use this saved homepage result to consider visual loading progress alongside the first and largest content milestones.
- Speed Index describes how quickly visible content becomes populated, rather than when the whole page or a user journey finishes.
- Speed Index appears in the homepage overview, not in every monitored-URL table row.
- The overview represents the homepage itself, not an average of all pages, a visitor percentile or a historical trend.
Speed Index2.1 s
0.8 s
1.4 s
2.1 s
Verify Performance Changes
A later check can help you assess a focused release, but the current-result screen is not a before-and-after archive. Keep your own baseline so the comparison has a clear reference.
- Record the URL, available metric values and page version before changing a template, image strategy or script.
- Make one meaningful change and compare the same URL with a later available check; a changed query string may represent a different page.
- Consider caches, third-party content and measurement variance before attributing a changed value to your release.
- There is no multi-point history, performance alert or automatic cause-and-effect report in this view.
Before62→After87
NotesExplain PageSpeed with SEO MCP
Ask an AI assistant to interpret available saved homepage measurements through SEO MCP. Keep the explanation attached to the returned URL and saved check time rather than treating it as a new test.
- The read-only tool returns the homepage's available FCP, LCP, CLS, TTFB, TBT and Speed Index values.
- A missing homepage result or individual metric remains unavailable; the tool does not substitute another monitored page.
- SEO MCP does not start a performance check, retrieve every added URL or fix the website automatically.
- The authenticated SEO API also exposes the saved homepage overview, subject to project access and the endpoint's plan eligibility.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Talk about PageSpeed Monitoring. With SEO MCP.
Interpret saved homepage speed metrics with SEO MCP. The tool reads available results; it does not run a new test or retrieve every monitored URL.
- Screpy: Hello! Let’s look at PageSpeed Monitoring for example.com. What would you like to know?
- You: Explain the saved FCP and TTFB for example.com. What should I investigate?
- Screpy: In this illustrative homepage result, FCP is 2.4 s and TTFB is 950 ms. Review connection and response delivery, then early rendering. These values suggest investigation; they do not identify a cause. Confirm the returned URL and saved check time before comparing another result. Saved homepage example: FCP: 2.4 s. TTFB: 950 ms.
- 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 one slow result into a controlled performance check.
Reduce guesswork by keeping the URL, measurement scope, and next change specific. PageSpeed Monitoring supplies the lab evidence; the investigation still belongs to your team.
-
Choose a representative public URL
Choose a public page on the project domain or a subdomain, tied to a campaign, organic entry or important template, within your available monitoring allowance.
-
Read the URL and available metrics
Confirm the exact URL, available values and lab status. The table does not display a check date, and missing values do not establish a complete measurement.
-
Form one focused hypothesis
Use the table's FCP, LCP, TTFB, TBT and CLS to choose an investigation. Use Speed Index only from the homepage overview when visual loading progress is the question.
-
Change one cause and measure again
Keep the same URL and test scope, record the original result, make one meaningful change, and use a later check to see whether the evidence moved in the expected direction.
Monitor pages that represent a real business decision.
A smaller, intentional URL set is easier to interpret than a list with no priority. Cover important journeys and templates before low-value edge pages.
Campaign landing pages
Keep paid, email, launch, and seasonal landing pages in the monitored set while they are actively receiving traffic.
Organic entry pages
Choose representative articles, category pages, and product pages that bring search visitors into the site.
Shared templates
Monitor one representative URL from each important template so a layout or script change can be investigated with a focused lab result.
Know what the monitoring result does not prove.
Use Screpy as a recurring lab measurement workflow. Keep field data, root-cause diagnosis, historical reporting, alerts, and business outcomes separate unless another source verifies them.
Lab data is not field data
Screpy reports synthetic measurements from a controlled check. Do not present them as the experience recorded from your real visitors.
Current results need a separate baseline
Record values separately for a later comparison. The view has no multi-point historical chart, visible check-date column or performance alerts.
A metric is not the root cause
A weak FCP, LCP, TTFB, TBT, Speed Index, or CLS result identifies where to investigate; it does not prove the implementation change required.
PageSpeed is not a ranking guarantee
Faster pages can support visitors and page experience, but a lab verdict alone cannot guarantee rankings, traffic, engagement, or conversions.
Use the performance workflow that matches the question.
Monitor selected URLs for current lab results, learn how those signals relate to Core Web Vitals, or audit the wider website when a single metric cannot explain a repeated problem.
Run recurring lab checks for your selected public pages and review available URL metrics in the Core Web Vitals screen.
Separate lab diagnostics from field data and understand how LCP, CLS, TBT, and real-user INP should be interpreted.
Use crawl, link, image and on-page findings to add website context; an audit does not replace a browser performance trace.
Screpy documentation
Learn how to monitor page performance
Learn how to choose monitored URLs, interpret available lab measurements, keep field data separate and record a baseline for a later check.
Related SEO guides
Learn the concepts behind this workflow and apply them with practical SEO guidance.
Page Speed
Page Speed Monitoring: Metrics, Tools, and Workflow
Monitor important pages with consistent lab and field measurements, investigate regressions, and verify page speed fixes over time.
Read article SEO
SERP Monitoring: What is It and Why It Matters
Learn what SERP monitoring is, why it matters, and how tracking competitors, keyword rankings, and search result changes improves SEO strategy.
Read article SEO
The Best Web Site Analysis Tool: Take The Full Control!
Learn what a website analysis tool should measure, from bounce rate and conversions to traffic, rankings, sales, page issues, and optimization tasks.
Read article GEO
What Are AI-Proof Keywords and How Do You Find Them?
AI-proof keywords are search terms that still drive visits beyond AI answers; find them with SERP checks, intent signals, tools, comparisons, and local demand.
Read articlePageSpeed Monitoring FAQ
Understand URL coverage, daily eligibility, table and homepage metrics, lab status, saved results and the limits of a performance comparison.
Which URLs should I monitor first?
Start with the included homepage and representative public campaign, product, pricing or content pages on your project domain or subdomains. The plan allowance determines how many URLs you can add; a public-page check does not complete an authenticated user journey.
How often does Screpy check a monitored URL?
Active monitored URLs in eligible projects can be scheduled again once the saved check attempt is at least one day old. Adding a URL does not create an instant result, and exact completion time can vary. No check-date column is displayed in the table.
Is Screpy PageSpeed Monitoring lab data or field data?
It is synthetic lab data collected under a controlled test. Field data describes how real visitors experienced a page, so the two sources should be interpreted separately.
Does PageSpeed Monitoring include alerts or historical trend charts?
This view presents available current URL results and a saved homepage overview. It does not provide performance alerts or a multi-point historical chart. Record a baseline separately before comparing a later check.
Does Screpy show a Google PageSpeed score?
This screen does not show a 0–100 Lighthouse or Google PageSpeed score. Its lab status is based on the worst available LCP, CLS or TBT classification. FCP and TTFB are separate diagnostics, and a pass does not certify real-user Core Web Vitals.
What does Screpy PageSpeed Monitoring measure?
PageSpeed Monitoring uses the Core Web Vitals screen. Selected URL rows show FCP, LCP, TTFB, TBT and CLS with a lab status. The homepage overview also includes Speed Index. The table does not show check dates or a 0–100 PageSpeed score.
Does PageSpeed Monitoring identify the exact cause of a slow result?
No. A weak metric narrows the investigation, but it does not prove the root cause. Review the affected URL, template, assets, scripts, delivery path, and wider website audit before choosing a fix.
Will a better PageSpeed result guarantee higher rankings or more conversions?
No. Page speed can support visitor experience and page quality, but rankings and conversions depend on many factors. Treat the lab result as one decision input, not a guaranteed outcome.