If a WooCommerce store feels slow on a phone or variable connection, do not start by compressing every image or chasing a PageSpeed score of 100. Find which content arrives late, which interaction responds slowly, and whether the layout shifts during load. Use user data when it is available, then reproduce the issue in a lab test to isolate likely causes.
Core Web Vitals describe three parts of real user experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google's current “good” thresholds at the 75th percentile are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. These are experience targets, not a ranking promise. See Core Web Vitals and page experience in Google Search.
Separate field data from lab measurements
Field data summarizes visits from real users over a collection period; lab data runs a controlled simulation. CrUX may not have enough data for every URL, so a page-level report can be unavailable even when an origin-level result exists. Lighthouse can help reproduce and investigate, but one run does not describe every device, network, or visit.
Start in PageSpeed Insights with representative product, category, cart, and checkout pages. Note whether each result is URL-level or origin-level, field or lab, mobile or desktop, and which period it covers. Keep the same URL, test conditions, and metric when comparing before and after.
Identify the template and element before changing the site
Group URLs by template and product behavior. A product image problem may affect one layout; a script or font may affect the whole store. Record the template, major element, plugin or theme path, and device context before changing code. Avoid a sitewide fix based on one unusual URL.
Diagnose LCP: what is the largest content waiting for?
Inspect the reported LCP element. It may be a hero image, product photo, text block, or another large visible element. Check server response time, image discovery and loading priority, file dimensions, and whether scripts delay rendering. Confirm the actual rendered asset before choosing an image optimization; compressing a non-LCP image may not change LCP.
Diagnose INP: which interaction is delayed?
Look at the interaction that feels slow—variant selection, add to cart, filters, or a menu—and inspect what work runs around it. Long main-thread tasks, third-party scripts, and expensive handlers can delay feedback. Test the same interaction on the same template before and after a focused change.
Diagnose CLS: what moves after reading begins?
Find elements that appear without reserved space: product images, banners, fonts, reviews, or payment widgets. Set stable dimensions where possible and check font loading and late insertions. A visual shift can be concentrated in one template or third-party component; locate its source before applying a broad stylesheet rule.
| Symptom | First evidence to inspect | Possible investigation |
|---|---|---|
| LCP high | LCP element and server timing | Image discovery, priority, rendering delay |
| INP high | Slow interaction and long tasks | Event handler, main thread, third-party script |
| CLS high | Layout shift sources | Missing dimensions, late banner, font swap |
| Field/lab mismatch | Data source and collection period | Device mix, route coverage, test conditions |
Prioritize fixes by impact and risk
Prefer a verified bottleneck affecting a high-value template over a cosmetic score change. Estimate how many routes share it, check conversion-critical behavior, and make one reversible change at a time. A plugin or theme update can affect cart and checkout; validate those journeys before release.
Build a mobile test plan for Egyptian shoppers
Do not assume one network, phone, or city represents all shoppers in Egypt. Select representative devices and connection conditions from observed customer support, analytics, or field research. Test product discovery, variant selection, cart, payment, and confirmation. Record the conditions so a later comparison can be repeated. If CrUX has no data for a page, report that gap instead of inventing a field result.
Short-video script: do not chase a score of 100
Opening: “Your store feels slow on mobile? A perfect lab score is not the first diagnosis.”
Scene 1: “Check field data and identify the template and metric.”
Scene 2: “Find the LCP element, slow interaction, or shifting component.”
Close: “Fix the verified bottleneck and test the shopping journey again.”
Educational carousel: three metrics, three different causes
- Cover: Diagnose the experience before changing every image.
- LCP: Which large visible element appears late?
- INP: Which interaction waits for the main thread?
- CLS: Which element moves after content appears?
- Field vs. lab: Real-user trends and controlled reproduction answer different questions.
- Template: Check representative product, category, and checkout pages.
- Action: Change one verified cause and repeat the same test.
Field experiment thread: test one product-template improvement
1/ Select representative product pages and capture field and lab results separately.
2/ Name the target metric, template, and specific element or interaction. Save the current journey and conditions.
3/ Change one suspected cause—such as the LCP image priority or reserved image space—without bundling unrelated edits.
4/ Repeat the same route and lab conditions; then review field data when a comparable sample is available.
5/ Record impact on the shopping flow and any side effects. Do not claim a user-wide improvement from one lab run.
Tool-neutral prompt pack: create a repeatable diagnosis
Prompt 1: “Given these redacted PSI results [URL type, data source, device, LCP element, metrics], separate field observations from lab results and list missing context.”
Prompt 2: “Review this template and interaction evidence [details]. Identify possible causes for LCP, INP, or CLS, rank by evidence, and suggest the smallest reversible check.”
Prompt 3: “Create a before/after test record for [change] that preserves the same route, device, network condition, checkout behavior, and metric. Do not infer a ranking effect.”
Stop-doing swipe file: stop optimizing the wrong signal
- Stop: “The score is not 100, so the page is bad.” Use: Identify a user-experienced bottleneck and its evidence.
- Stop: Compressing every image first. Use: Find whether the LCP element is actually an image.
- Stop: Treating one Lighthouse run as field performance. Use: Label lab and field data separately.
- Stop: Changing several templates and scripts together. Use: Fix a shared cause, then verify representative journeys.
Hook–Value–Template: metric, cause, then fix
Hook: “A useful speed fix starts with the delayed content, interaction, or shift—not a target score.”
Value: Separate field and lab evidence, locate the affected template, and choose a reversible fix for the user-visible bottleneck.
Template: Page/template [ ]; field source/period [ ]; lab setup [ ]; target metric [ ]; affected element or interaction [ ]; observed cause [ ]; change [ ]; checkout side effects [ ]; repeat-test conditions [ ]; result and evidence limits [ ].
Official performance references
- Google Search Central: Core Web Vitals
- Google Search Central: Page experience
- web.dev: Lab and field data differences
- PageSpeed Insights
The metrics help diagnose user experience; they do not guarantee rankings, traffic, or sales. Report the data source, period, page scope, and test conditions with every comparison.