Page speed optimization starts with one question: what is slow for visitors on an important page, and why? Measure the page, identify the element or task causing the delay, change that cause, and measure again. A score alone cannot tell you which fix is worth doing first. This checklist separates real-user experience from a controlled lab test, then connects common findings to practical fixes for images, server response, CSS, JavaScript, fonts, and third-party scripts.
Use it for any website stack. If you work specifically in WordPress, follow the WordPress page speed guide for hosting, themes, and plugins. For definitions and thresholds, start with the separate Core Web Vitals guide.
1. Choose the pages that matter
Start with a small set of URLs that represent your main templates: a homepage, a high-traffic article, a category page, a product or service page, and a conversion page. A single fast homepage does not prove that every template is fast. Record the URL, device, test date, recent release or content change, and the metric you want to improve.
Prioritize a repeated problem on an important template over an isolated low-traffic page. If several product pages share the same oversized hero image pattern, fixing the template can be more valuable than tuning one URL. Use search traffic and conversions to inform priority, but do not assume a speed improvement will produce a particular ranking or revenue gain.
| Question | Where to look | What to record |
|---|---|---|
| What do visitors experience? | PageSpeed Insights field data or another real-user dataset | URL or origin scope, mobile/desktop, LCP, INP, CLS, observation period |
| What can we reproduce and debug? | PageSpeed Insights lab report, browser developer tools, or a controlled test | Test settings, largest element, request waterfall, long tasks, layout shifts |
| Is the issue persistent? | Repeated checks on the same URL and template | Before/after dates, deploys, third-party changes, device context |
| Did the fix help? | The same lab test plus later field data | Changed metric, unchanged metrics, and any new regression |
PageSpeed Insights is a useful starting point because it shows both real-user and lab views when enough field data is available. Google's PSI documentation explains why those views can disagree: field data describes a range of actual visits, while the lab run uses controlled conditions. A newly published or low-traffic URL may not have URL-level field data; an origin-level result is not proof that the individual page behaves the same way.
2. Read the metric before choosing a fix
Core Web Vitals describe three aspects of experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Google's current good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 in the field assessment. The Core Web Vitals guide linked above explains the definitions, thresholds, and what each failure suggests.
Do not treat a Lighthouse performance score or a single fast test as a replacement for field data. Likewise, do not assume every red number has the same business impact. If LCP is poor on a landing-page template, inspect the largest content element and the time spent waiting for its resource. If INP is poor, investigate interactions and long main-thread tasks. If CLS is poor, inspect elements that move after rendering, such as images without reserved dimensions, embeds, ads, or late banners.
Screpy's Core Web Vitals monitoring helps you follow lab-based checks for selected project URLs, including FCP, LCP, CLS, TTFB, TBT, and Speed Index. Use those page-level results to select a URL for investigation and compare repeated checks. Screpy does not turn a lab result into an INP field measurement for all visitors. Confirm real-user experience separately when that distinction matters.
Two related metrics help with diagnosis but answer different questions. First Contentful Paint indicates when something first appears; it does not tell you when the main content is ready. Speed Index describes how quickly visible content fills in during a lab run; it is not one of the three Core Web Vitals.
3. Fix the loading path, not the score label
When LCP is slow, first identify the actual LCP element. A large image, background image, or text block can be responsible. If an image is the element, check whether the browser discovers it early, whether the delivered file is appropriately sized, and whether a carousel or client-rendered component delays it. Avoid lazy-loading an above-the-fold LCP image. Compress and use responsive images where appropriate, then verify that quality remains acceptable.
Next inspect server response and delivery. High Time to First Byte can delay everything that follows. Review caching, slow application work, redirects, and the distance between users and the server. A CDN can help static assets and sometimes HTML delivery, but it will not repair slow application code or an unnecessarily long redirect chain. Compare the request waterfall before buying a new hosting plan.
For text resources, check whether compression is active and whether the payload is large enough to matter. The text compression guide covers what to check and how to verify the response. Remove unused CSS and avoid blocking the initial view with styles or scripts that the page does not need immediately. If Lighthouse reports unminified styles, use the CSS minification guide to distinguish a real delivery improvement from a minor audit warning.
4. Reduce interaction and layout delays
For poor responsiveness, find the interaction that feels slow. Check whether third-party tags, large JavaScript bundles, hydration, or expensive event handlers keep the main thread busy. Split work into smaller tasks, defer code that is not needed for the initial task, and remove unused dependencies where possible. A lower Total Blocking Time in a lab test can be a useful debugging clue, but it is not the same metric as field INP.
For layout instability, reserve space for images, ads, videos, and embeds before they load. Set dimensions or an aspect ratio. Avoid inserting consent banners, promotions, or other blocks above content after the page has started rendering. Check font loading when text shifts or flashes; the right fix depends on the actual font and fallback behavior, not on disabling all web fonts.
Measure the affected page again after each meaningful change. If multiple changes land together, it becomes harder to know which one helped or caused a regression.
5. Adapt the fix to the platform and monitor it
A WordPress page may be slowed by theme assets, plugins, or cache settings; a JavaScript-heavy application may spend more time rendering and hydrating; an ecommerce category may have image grids, filters, and marketing tags. The underlying metric is the same, but the responsible code and owner differ. Follow the WordPress-specific guide linked above when those details apply rather than copying plugin recommendations into a platform-neutral checklist.
After a fix, retain a baseline with the URL, test settings, date, and deploy or content change. The page speed monitoring guide explains how to watch for regressions instead of treating a one-time audit as completion. Compare a few repeated lab checks and then review field data after enough real visits accumulate. A 28-day field window will not react to a new deploy like a single lab run does.
Page speed can affect experience and conversions, but avoid turning a correlation into a guaranteed outcome. Our separate guide on page speed and conversion rates addresses that business question. Google's page experience guidance is equally clear that good Core Web Vitals do not guarantee top rankings. Relevance and helpful content still matter.
A practical verification checklist
- Select a valuable URL and identify its page template.
- Record mobile and desktop field data where available; note when it is origin-level or missing.
- Reproduce the issue in a lab run and inspect the element, request, task, or layout shift behind it.
- Change one plausible cause, then run the same test again.
- Recheck other URLs on the same template and monitor after the next release.
- Review later field data before claiming the real-user problem is resolved.
What is the best first step in page speed optimization?
Measure one important URL, then identify the slow element or interaction. A generic list of speed tricks is less useful than a fix tied to a reproducible cause.
Should I optimize for a perfect PageSpeed score?
No. Use diagnostics to improve visitor experience on important pages. A perfect lab score is neither necessary nor a ranking guarantee.
Why do Screpy and PageSpeed Insights show different numbers?
Tests may use different devices, dates, environments, or measurement methods. Screpy's selected-URL checks are lab-based; PSI may show both a lab run and historical real-user data. Compare like with like before acting.
When should I check speed again?
Check immediately after a meaningful change with the same lab setup, then monitor the page over time and review field data when enough visits have been collected.
Sources and scope
The measurement distinctions and SEO claims follow the Google documentation linked where they apply. Screpy's performance guide defines the product's lab-based monitoring scope. Specific fixes remain hypotheses until they are tested on the affected page.