01
Measure the page that feels slow
Start with the actual page and action: waiting for the opening image, scrolling a portfolio, opening the menu or using a form. A single headline score does not explain which part of that journey is slow. Save the URL, release, device profile, network setting, tool and date before changing anything.
Separate controlled lab results from field data collected from real visits. Google's web.dev LCP guidance explains why lab tools can help diagnose loading but do not necessarily represent every user's experience. When field data is unavailable, report that limit rather than substituting a lab score as proof of real-user improvement.
02
Use the same conditions for the comparison
- Page and release: [exact URL and deployed commit/version].
- Scenario: [cold load / repeat visit / scrolling / contact action].
- Lab environment: [tool, viewport, network and CPU settings].
- Runs: [repeat results, including variability and failures].
- Field evidence: [URL/origin, device segment, period or unavailable].
- Observed issue: [resource, render delay, layout movement or interaction].
- Change and visual review: [what changed and what remained readable/useful].
Change a focused cause, then repeat the same scenario. Keep the individual results and explain variation. If the deployed release, test environment or page content changed in several ways, a clean before/after attribution is harder; disclose that instead of selecting only the best run.
Also test the customer's action. A faster-looking first screen is not a successful repair if the menu, gallery navigation or form has stopped working.
03
Deliver suitable images and keep the originals
Review which image is actually visible first, its delivered size and its place in the layout. Responsive delivery can let the browser select an appropriate version while keeping a fallback image. Explicit dimensions help reserve space. Review text, details and framing visually before accepting a new derivative.
Browser-level lazy loading can defer offscreen images, but Google's guidance warns against lazy-loading likely first-viewport or LCP images. Do not apply one blanket setting to every photo. The opening image and a distant portfolio image can have different loading needs.
Keep the original approved media separately. Project Monet's export checks compare the original public assets byte-for-byte; the publication batch does not recompress the reels. A future delivery change should be separately scoped and tested rather than quietly overwriting the originals.
04
Ask what the video contributes to the visit
A reel can show a design or service more clearly than static copy. It can also create an unnecessary download if every visitor receives several videos immediately. Review where the video appears, what its first frame communicates and whether the user has enough control to browse comfortably.
- Keep key business information readable without relying on the video.
- Check media requests during the chosen test scenario.
- Review loading priority alongside the actual opening content.
- Avoid starting every offscreen media item solely because it exists.
- Test playback, controls and layout on the intended devices.
These are review questions, not a claim that a particular encoding or autoplay policy is always best. Choose the implementation against the business purpose, accessibility needs and measured behaviour.
05
Look beyond the image file
Loading can be delayed by server response, redirects, render-blocking resources or client-side work. The LCP diagnostic process examines the loading sequence rather than assuming a single image edit will fix everything. Identify the bottleneck before changing the visible design.
Keep third-party scripts and animations accountable to a purpose. Remove or defer unnecessary work only after checking the integrations that depend on it. Analytics, consent and form success behaviour should remain correct after the performance change.
06
Ask for a measured repair and an honest report
A useful performance scope names the affected pages, test conditions, planned change, visual acceptance and functional checks. It should distinguish a verified lab result, available field evidence and any outcomes that are still unknown.
Use a mobile website review to agree that scope. The maintenance guide explains broader upkeep; performance work should have its own evidence and acceptance criteria.
Sources
Primary and supporting sources
Use the linked documentation and labelled build examples to check the evidence. Business examples are planning tools; they do not establish customer outcomes or guarantee search visibility.