Slow Money Pages
Learn how to prioritize Core Web Vitals work using real-user LCP, INP, CLS, visits, page views, page purpose, and business impact.
Slow Money Pages combines real-user performance signals with visits and page views to identify slow URLs that matter. The report includes the page, traffic, Core Web Vitals, and an impact indicator.
The name expresses a prioritization principle: an important landing, product, signup, or lead page with moderate performance problems can deserve attention before an extremely slow page with almost no users.
Understand Core Web Vitals
| Metric | Experience represented | Good threshold at the 75th percentile |
|---|---|---|
| LCP | Loading performance of the largest visible content element | 2.5 seconds or less |
| INP | Responsiveness across user interactions | 200 milliseconds or less |
| CLS | Visual stability from unexpected layout shifts | 0.1 or less |
The thresholds and percentile evaluation are documented in Web Vitals. Field data describes real users and devices; it can differ from a one-time lab test.
Read performance with traffic and purpose
| Signal | Interpretation |
|---|---|
| Poor vital + high traffic + critical page | High-priority investigation |
| Needs-improvement vital + high-value conversion page | Often more important than an obscure poor page |
| Poor vital + very low traffic | Validate the sample and template before prioritizing |
| Good field data + poor lab test | The test may expose a future risk or unrepresented condition |
| Poor field data + good lab test | Real devices, networks, interactions, or a previous release may differ |
Do not combine LCP, INP, and CLS into one vague “speed” problem. Each metric has different likely causes.
Diagnose LCP
Identify the LCP element on representative page types and devices. Investigate server response time, render-blocking styles or scripts, resource discovery, image size, font behavior, cacheability, and client-side rendering delays.
The largest element can change across mobile and desktop. Optimize the actual element and delivery chain rather than applying generic minification.
Diagnose INP
Find the interactions users perform: menu, filter, search, form, accordion, cart, or editor. Long JavaScript tasks, excessive rendering, event-handler work, and main-thread contention can delay the next paint.
Reduce work per interaction, break up long tasks, avoid unnecessary rerenders, and defer non-critical code. Measure the complete interaction, not only event-handler duration.
Diagnose CLS
Look for images without dimensions, late banners, injected ads, consent notices, font swaps, dynamic widgets, and content inserted above existing elements. Reserve space and avoid moving content after the user begins reading or interacting.
Expected movement triggered immediately by a user action can be acceptable; unexpected movement is the problem.
Prioritize with an impact model
Use:
priority = affected users × page value × severity × confidence ÷ effort
This is a planning model, not a Screpy formula. Page value can include revenue, lead generation, activation, support reduction, or strategic acquisition.
Group pages by template. If hundreds of product pages share the same LCP cause, one component-level fix can outperform isolated page edits.
Example
A checkout entry page has LCP 3.1 s, INP 170 ms, CLS 0.04, and substantial traffic. A low-traffic archive has LCP 5.8 s. The checkout page may deserve priority because its affected audience and business role are much larger, even though the archive is technically slower.
The metric also points toward the investigation: LCP needs work; INP and CLS do not currently justify equal effort on that page.
Field data, lab data, and release verification
- Field data tells you what real users experienced over an aggregation window.
- Lab tests provide controlled diagnostics and repeatable traces.
- Application monitoring confirms release timing and errors.
Use all three for different purposes. A successful lab result does not instantly replace the field-data window. Verify the deployment immediately, then monitor field metrics long enough for the new experience to be represented.
Avoid harmful performance work
- Do not remove essential content or functionality to improve a score.
- Do not load critical content only after interaction to hide it from measurement.
- Do not optimize desktop while ignoring mobile traffic.
- Do not apply one fix to every template without measuring its cause.
- Do not declare success from one favorable test run.
Verify the outcome
Record the page group, traffic, vital values, devices, and release date. Confirm the technical cause in lab diagnostics, deploy the targeted fix, watch errors and conversion behavior, and compare field data when the window updates. Success means a better real experience without lost functionality or business performance.