Web · Practical guide
Your website feels slow. Here is what to fix first
Understand loading, responsiveness and layout shifts without turning a performance score into the only goal.
Start where customers notice the delay
A visitor does not experience your website as a score. They notice that the main photo appears late, the menu ignores a tap or a button moves just before they press it. Start your investigation by describing the interruption in plain language. That gives the team something concrete to reproduce.
Choose three important pages: the main landing page, a service or product page, and the enquiry or checkout journey. Test them on a phone using a realistic connection. A fast empty homepage cannot compensate for a frustrating page where the customer makes a decision.
Read the three signals together
Core Web Vitals describe loading, responsiveness and visual stability. The current good thresholds are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less. Evaluate them at the 75th percentile, separately for mobile and desktop. Google’s web.dev documentation explains each measure.
Use these signals to locate problems, not to promise more sales. A field-data report reflects real visits; a controlled lab test helps investigate a specific change. A site with too little traffic may not have enough field data, so document that limitation instead of presenting a lab run as a real-user result.
Look at the largest visible image first
A huge image can carry far more detail than its display size needs. Ask whether the main visual has an appropriately sized source, efficient compression and reserved dimensions. A cover image should remain clear on a modern screen without forcing every phone to download the desktop original.
Do not solve weight by making the subject unreadable. Compare the exported image at the actual card size and on the article page. Keep important information in real text, rather than baking small paragraphs into an illustration that becomes tiny on mobile.
Find work that blocks the interaction
If tapping feels slow after the page has appeared, inspect what the browser is doing at that moment. Heavy scripts, repeated interface updates and unnecessary third-party tools can compete with the action the user is trying to take. Ask for a recording of the slow interaction before selecting a fix.
Review each external widget by purpose. Does it support an important task, and who owns it? Removing a tool nobody uses can be more valuable than tuning a decorative animation. Test menus, filters and form validation after any change so that a speed improvement does not break a useful feature.
Reserve space so the page stays still
Unexpected movement is often easy to describe: text jumps when a font loads, an image pushes content down or a banner appears above a button. Give media a stable display area and review content that is inserted after the first render.
Check the page with cached and uncached assets. A developer’s frequently visited browser can hide a first-visit problem. Re-test at narrow widths, where a longer title or translated button can reveal movement that was not obvious on a desktop.
Measure one change at a time
Record the page, device, connection assumptions and starting observations. Make a focused change, repeat the same task and compare the result. Keep a note of what improved and what did not. This is more useful than collecting unrelated screenshots from different testing tools.
The outcome should be a website that lets customers read, decide and act comfortably. Keep performance checks in the release routine, especially when adding new media, marketing tools or interactive sections. Good performance is something to maintain, not a badge earned once.