Library·SOP·SEO
Test representative, important pages on mobile and desktop, separate real-user field data from simulated lab results, identify a supported bottleneck, and assign the next improvement with a like-for-like retest plan.
Last reviewed: · Editorial review
Clarity, structure and references reviewed in this version. This is not a test in a live account.
Test representative, important pages on mobile and desktop, separate real-user field data from simulated lab results, identify a supported bottleneck, and assign the next improvement with a like-for-like retest plan.
This SOP covers:
This does not cover:
Start with important visitor tasks and page types so the tests represent useful work, not a random set of URLs.
Make a working copy of the Technical SEO action plan. Use its Speed tests tab for measurements and Action plan tab for decisions and follow-up.
Choose one working public URL for each important page type or visitor task. Use a product or service page, lead form, or important article as appropriate. Test one URL per distinct layout; add another only when its layout or visitor task is meaningfully different.
Plan separate Mobile and Desktop reports for each selected URL in PageSpeed Insights. Keep the device with each measurement because a phone and desktop can show different results.
Field data describes real visitors over a rolling period. Lab data is a simulation that helps diagnose a page load. Keep the two evidence types separate.
For each selected URL and device, record whether PSI has field data for that exact URL, for the whole site origin, or not at all. Field data summarizes real Chrome visitors over a rolling 28-day period.
For each URL, enter its exact public address in PSI and run the report. After results load, use the report’s device control to choose Mobile and note whether field data says “This URL,” “Origin,” or “No data.” Then choose Desktop in the loaded report and note its field-data label.
Add one Field row per URL, device, and check date in the Speed tests tab. Fill URL, Device, Checked on, Data shown, LCP (s), INP (ms), CLS, Assessment, Report URL, and Notes. Copy the values and assessment PSI shows; leave metric cells blank when it has no data.
PSI shows the 75th-percentile field values: 75% of recorded visits were at or below each value and 25% were slower. Record the date because this 28-day window changes over time.
Use these meanings when recording the field-data assessment. The PSI “Good” cutoffs apply to the 75th-percentile field values; do not use them to label one lab run.
Largest Contentful Paint (LCP) is when the main visible content appears. Good: at or under 2.5 seconds.
Interaction to Next Paint (INP) measures how quickly the page responds after real visitor interactions. Good: at or under 200 milliseconds.
Cumulative Layout Shift (CLS) measures unexpected movement while the page loads. Good: at or under 0.1.
Run the same PSI URL and device three times to see which simulated-load findings repeat. Lab tests are controlled simulations; they help diagnose, but do not represent every visitor's device, network, or behavior.
For each URL and device, run PSI three times without changing the page. If you need to change device, first load the URL report, then choose Mobile or Desktop in that report. In Speed tests, add three Lab rows with the same URL and device, Before/After set to “Before,” and Run set to 1, 2, and 3.
For every Lab row, enter Checked on, LCP (s), CLS, TBT (ms), Performance score, Report URL, and Main finding. In Main finding, write the recurring clue PSI identifies, such as a delayed main image or slow server response, rather than “low score.”
Total Blocking Time (TBT) estimates how long page scripts or other work keep the browser busy during this simulated load. It can point to script work worth checking, but it is not INP. The standard PSI lab report does not provide lab INP.
Prioritize by visitor impact, business importance, and a cause you can point to. Use the lab score as context, not as the decision.
Compare field and lab evidence separately. Do not average them: they measure different experiences.
First consider an important page type with a field metric marked Poor or Needs Improvement. Page value comes from the visitor task or available visitor counts, not from the Performance score. If field data is Origin or No data, do not claim that it proves how the tested URL performs.
Next, look for the same likely bottleneck in most of the three Lab rows. If readings or findings vary, record that uncertainty and ask for another set before recommending a specific fix.
When two issues have similar evidence, put a fix that affects several important page types ahead of a one-off issue on a less important page. If you cannot name a likely cause, make the next action “Confirm the cause” and assign an investigation.
Example: a product page has no field data, but all three mobile Lab runs show LCP near 4 seconds and identify its large visible product image. The repeated image clue supports checking that image first, while “No data” means you cannot claim that real visitors have the same LCP. Record the image action and plan a later field check.
In the Action plan tab, add one row for each distinct issue you want to track. Fill Page or issue, What you found, Next action, Why this comes first, Owner, Review date, Status, and Result / how to undo. For new planned work, set Status to “To do.”
In What you found, name the URL, device, affected metric, and repeated lab clue or field status. In Why this comes first, say which visitor task matters and how many page types appear affected, if known. Assign one person in Owner and a date in Review date.
Use Result / how to undo for the later comparison and, when relevant, the exact reversal action and who can take it. For example, a plugin-setting change may be undone by turning that setting off and clearing its cache.
Follow the linked image procedure only when, after comparing the findings, you select a specific image improvement as the next worthwhile action for an important page. A repeated image-related LCP clue is evidence to compare, not a decision by itself. Weigh the image's role and achievable change against findings such as layout shift or render-blocking. If one of those actions ranks higher, keep it first and hand it to the appropriate owner; this image route is not needed.
If the same important public WordPress page repeatedly shows slow server response, use the linked page-cache procedure to test whether simple page caching is suitable. Treat caching as one candidate fix; the report alone cannot prove that it will solve the issue.
If PSI points to theme code, scripts, hosting, a CDN, or a layout problem, assign a developer or host specialist. Include the affected URL, device, metric, recurring clue, and PSI report links in What you found; ask them to investigate that cause.
This follow-up is for when an assigned owner has completed one change. The prioritized action plan is complete before this step.
After the assigned change is complete, repeat the three PSI lab runs for the same URL and device. Add three Lab rows with Before/After set to “After” and Run set to 1, 2, and 3.
Compare the range of each target metric and whether the original Main finding changed. If the ranges overlap, move in different directions, or another change happened at the same time, write “Unclear” in the Action plan result and explain why. Do not claim a clear gain from a score change alone.
On a later date, check PSI's field data again when its refreshed 28-day window includes meaningful visits after the change. Add one new Field row for that URL and device. Keep the older dated row, and compare only matching Data shown labels.
