- Find the affected experience
- Diagnose the cause
- Change one meaningful factor
- Verify and monitor
Which metrics are you trying to improve?
The current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. They describe loading, responsiveness and visual stability. Google's published good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, assessed at the 75th percentile with mobile and desktop considered separately. Check the current definitions before using an old audit template.
These measures answer different questions. A page can show its main content promptly but respond slowly when someone opens a menu. Another page can respond quickly while an image pushes the form down as it loads. Label the problem by the affected behavior rather than calling every issue a slow website. That makes the investigation more precise and the eventual change easier to evaluate.
Should you begin with field data or a lab score?
Field data describes experiences collected from actual users under varied conditions. A controlled lab test helps reproduce and investigate a page in a particular setup. They are complementary. Google's guidance notes that a standard Lighthouse page-load test cannot measure INP without user interactions; Total Blocking Time can be a useful lab signal, but it is not the same metric. Do not relabel one as the other.
Record exactly what the report represents. Is it a specific URL, a broader origin or a page group? Is it mobile or desktop? What period does it cover? If real-user data is unavailable, say so and use the available diagnostic evidence carefully. A small site can still improve an obvious problem, but a single synthetic result should not be presented as a measured account of all customer experiences.
How do you choose the first page to investigate?
Start with pages that matter to the business and represent the site's common layouts. A home page, service detail, product page and contact flow may use different assets and scripts. One good home-page result does not establish that every other journey is healthy. Identify whether a problem appears across a shared template or only on one destination before deciding how broad the change should be.
Write a concise issue statement. For example: the mobile service page's main image appears late, or the product filter stops responding while a large list updates. Include the URL, device or test conditions and the action that reveals it. A developer can investigate that more effectively than a request to make the score green. Keep a before-change record so the comparison has a defined starting point.
What should you investigate for a poor LCP result?
Identify the element being measured and the stages that delay its appearance. The problem may involve server response, when a resource is discovered, how long it downloads or when the browser can render it. The web.dev LCP guide treats these stages separately. Compressing an image can help when transfer size is the constraint, but it cannot by itself solve a late-discovery or rendering delay.
For a business site, inspect the main visual and the resources it depends on. Ask whether the chosen asset is appropriate for the displayed size, whether a script delays important content and whether the page waits on something unnecessary. Avoid applying every optimization at once. A focused change with a clear hypothesis is easier to verify and less likely to hide a new problem behind a better aggregate score.
What should you investigate for slow interactions?
Find the interaction that is slow, such as opening navigation, filtering products or submitting a form. The INP guidance separates delay before processing, time spent in the interaction handlers and time before the next visual update. Heavy work on the browser's main thread can delay the response. A developer should identify which part is responsible rather than assuming the entire problem is network speed.
Consider whether the interaction performs work that can be reduced or scheduled differently. A filter may process more items than necessary; a click may trigger several unrelated scripts. Preserve the required behavior while reducing unnecessary work. Showing feedback matters, but a decorative loading state should not disguise a failed action. Test the actual result and the user's ability to continue, especially on less capable devices.
What causes content to move unexpectedly?
Common CLS causes include images or embeds without reserved dimensions, late-inserted content and font changes. The web.dev guidance recommends reserving appropriate space so the layout can account for content before it arrives. For example, an image can have known dimensions or an aspect ratio, while a late-loading embed may need a suitable reserved area. The correct choice depends on the design.
Inspect when the movement happens. A page-load screenshot can miss a shift that appears later as a banner, widget or remote content arrives. Review the important customer path from the start through interaction. Do not reserve an arbitrary huge blank area simply to suppress a metric; the layout still needs to be useful. A stable page should help visitors keep their place and activate the intended control.
What would a focused improvement look like?
Here is an original hypothetical example. A service business has a page with a large hero image, an embedded scheduling widget and a promotional banner. Staff report that mobile visitors sometimes lose their place before choosing an appointment. The team records the issue and finds that the widget expands after loading, pushing the next section downward. This is a planning example, not a measured Dappr project.
The first change gives the widget an appropriate layout space and checks how its loading and error states fit. The team tests the same journey on narrow and wider screens, including a slow-load condition. It confirms that the page remains readable and the booking action still works. It does not remove the widget merely because it is third-party content; the widget has a business purpose that the solution must preserve.
A separate investigation then examines the hero image's loading behavior. Keeping the changes distinct helps explain which issue each one addresses. If the controlled test improves, the team releases through its normal review process and watches available real-user evidence over time. The result is documented as a verified change under specified conditions, not a promise that every visitor or search ranking will improve.
Should you remove all third-party scripts?
Review them by purpose, cost and ownership. A site may have duplicate analytics, an abandoned widget or an old campaign tag that no one uses. Removing unnecessary code can simplify the page, but deleting a required booking or payment function would be a poor trade. Identify who owns each integration and what the business would lose if it changed.
Test timing changes carefully. Delaying a script can affect attribution, consent handling or a customer action. A performance task should therefore include functional checks, not only a new score. If the site depends on an external service that cannot be optimized directly, consider whether its placement or loading behavior can be improved while keeping the required user journey intact.
How do you know a fix has helped?
Repeat the relevant controlled test under comparable conditions and inspect the underlying behavior. Check the important page types affected by shared code. A change to an image component, font or navigation can influence more than the original URL. Confirm that forms, menus and other essential interactions still work, including understandable errors and keyboard access.
Then review the available field evidence with its reporting period in mind. Historical data does not become a fresh measurement immediately after deployment. Record the release date and avoid comparing incompatible windows or page groups. If the expected improvement does not appear, revisit the diagnosis rather than stacking more changes without understanding the result. Performance work should produce an explanation as well as a number.
How do you keep performance from slipping again?
Give recurring changes a small review process. New hero media, plugins, tracking tags and embedded tools can alter performance. Define who approves them and which important journeys need checking. Keep image guidance and content-editing instructions understandable for the people updating the site. A fast launch can become a slow site if ordinary publishing repeatedly bypasses the same constraints.
Dappr can discuss website performance within a scoped website or development engagement. Bring the affected URLs, available reports and the customer actions that matter most. The useful deliverable is a diagnosed problem, an implemented improvement and evidence of what was checked. A score alone does not describe the whole experience, and no performance change should be presented as a guaranteed ranking or revenue result.