Find which page resources slow the customer experience
Use a measured page trace and network evidence to locate slow loading, delayed rendering, and layout shifts. Turn confirmed causes into a prioritized improvement list.
How this works
Use a measured page trace and network evidence to locate slow loading, delayed rendering, and layout shifts. Turn confirmed causes into a prioritized improvement list. Use this when a page feels slow and the team needs evidence for which resources or rendering work to address first. Recommendations should follow a measured trace rather than a generic performance checklist.
Capture comparable page loads, connect user-visible delays to network and rendering evidence, and propose bounded changes. Separate laboratory measurements from field data and estimated impact from measured improvement. Validate one change at a time under the same conditions.
Before you start
Performance target
Select the page, important user interaction and representative device/network conditions.
Trace capability
Use an available browser performance recorder and network panel.
Code context
Obtain the relevant assets and configuration if implementation recommendations are requested.
Prepare the inputs
- page_target
- Required
URL, build and journey
State authenticated state, cache state and important content.
- measurement_conditions
- Required
device, network, browser and repetition plan
Keep conditions comparable across before and after runs.
- trace_files
- Required
timing, network and rendering evidence
Retain raw traces and capture timestamps.
- field_metrics
- Required
optional real-user measurements
Do not substitute lab results for actual customer distributions.
Implementation, step by step
Capture a baseline
- Record several representative loads and the relevant interaction.
- Keep cold and warm cache runs separate and note background variability.
Checkpoint: Baseline traces are reproducible.
Locate the delay
- Inspect request dependencies, largest content rendering, long tasks and layout shifts.
- Connect a slow resource to the affected user-visible event.
Checkpoint: Each suspected bottleneck has trace evidence.
Inspect causes
- Check asset size, loading priority, caching and relevant source behavior.
- Distinguish confirmed causes from hypotheses that need a controlled experiment.
Checkpoint: A cause table separates evidence strength.
Prioritize changes
- Estimate effort and potential impact with explicit assumptions.
- Prefer changes tied to the critical path and avoid unsupported universal speed claims.
Checkpoint: The team has a ranked bounded work list.
Validate improvements
- Apply only authorized changes and repeat measurements under comparable conditions.
- Inspect regressions in visual stability and functionality as well as timing.
Checkpoint: Results state measured changes and remaining uncertainty.
Decisions along the way
Slow third-party request is off the critical path
Do not rank it highly solely because its duration is long.
Lab and field results disagree
Investigate audience conditions and sample coverage rather than discard either source.
Run-to-run variation is large
Increase controlled repetitions or report the result as inconclusive.
What you will produce
performance-investigation.md
MarkdownA trace-backed prioritized investigation.
Include: conditions · baseline · bottlenecks · evidence · recommendations
performance-comparison.csv
CSVComparable measurements with estimates clearly separated.
Include: run · condition · metric · before · after · interpretation
Check the result
- Confirm before and after runs use the same conditions and build assumptions.
- Open traces to verify each claimed bottleneck.
- Check units and aggregation across repeated runs.
- Validate functional behavior after any performance change.
When something goes wrong
Trace is incomplete
Capture a fresh run and retain the failed trace as incomplete.
Caching hides the issue
Test the appropriate cache state and label it explicitly.
Optimization changes page behavior
Revert or isolate the change and investigate the regression.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: investigate a slow product page.
Inputs
Three cold-load traces show the main image requested only after a script completes at 2.0 seconds. A separate analytics request lasts 4.0 seconds but does not block rendering.
Expected result
Synthetic result: prioritize testing earlier main-image discovery, citing the dependency chain. Do not claim removing analytics will save four seconds of visible load time.
Run a small pilot
Start small
Investigate one high-value page and one critical interaction.
Record the baseline
Record current timings, variability and manual investigation effort.
Agree success criteria
Agree a measurable user-facing improvement and regression criteria before implementation.
Stop or revise
Stop claiming impact when measurement conditions or traces are not comparable.
Keep the scope clear
- A performance recommendation does not authorize production deployment.
- Laboratory gains do not establish a universal improvement for every customer.
Check before using
Validate recommendations against the trace. Repeat measurements under comparable conditions and distinguish laboratory results from actual customer experience.
Business activities
- Build and change software
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Target pages · Representative device and connection conditions
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow