Describe exactly when the delay happens
“The site is slow” can describe several different experiences. A blank first screen, a late product image and a delay after pressing Add to cart are separate observations. Record the page URL, device, connection and the action that leads to the wait. Find out whether several people see the issue or it occurs on one connection only.
Compare the home page, a catalogue category, a product and a form. Try mobile and desktop, both normally and without browser extensions. A single run is not enough: connectivity, a background update or temporary load may affect it. Equally, a fast repeat visit does not prove that the first-visit experience is good.
Break loading into understandable stages
The browser first connects and receives the initial data. It then loads documents, images, fonts and scripts, and still needs to assemble and draw the page. Some resources load in parallel, so the total loading time is not the sum of every resource’s loading time.
Time to First Byte, or TTFB, measures the wait for the first bytes of the response. It is a diagnostic clue, not a measurement of PHP or database time alone: the network and redirects can also contribute. If the response arrives promptly but the main image appears late, inspect that resource’s loading and rendering. A larger server does not by itself explain that delay.
Check both content appearance and responsiveness
Largest Contentful Paint, or LCP, helps describe when the largest visible image or text block appears. It is a useful view of the main screen, not a timer for every function becoming ready. Interaction to Next Paint, or INP, concerns responsiveness when people interact. Fast initial loading does not guarantee that filters and menus will respond promptly.
Follow a normal customer journey. Can you read the heading immediately? Does a button move as a banner appears? Is it clear that a click was accepted? These observations connect technical delays to the visitor’s task. A test score can support diagnosis, but it cannot replace this journey through the working website.
Capture a reproducible example
A precise URL and a short sequence are more useful to a specialist than a request to speed everything up. Describe the steps: open a category, select a filter, then open a product. Note where the wait occurs and its approximate duration. A screen recording can help, provided it contains no personal information. Do not publish passwords, account contents or an unchecked network archive.
Save several comparable checks with their dates and devices. A laboratory test uses defined conditions; field data describes the experience of the available real-user sample. Our existing article explains why Lighthouse results and Core Web Vitals can disagree. These different views should be understood together rather than treated as competing verdicts.
Address the measured cause in a controlled sequence
When most time passes before the response, investigate redirects, request processing, caching and external calls. For a delayed image, examine size, format, discovery and loading priority. For a freeze after a click, examine script execution and the interface update. These are different problems with different checks and remedies.
Do not disable every script, cache or protection feature on a live site at once. You may remove payment, analytics, enquiry forms or data exchange along with an unnecessary resource. Prioritise the work, review dependencies and implement related changes carefully. A CDN may help deliver appropriate resources, but it does not automatically repair application problems or replace diagnosis.
Verify the same pages and actions afterwards
Repeat the original journey under comparable conditions after implementation. Check speed and the affected menus, filters, forms, cart and other workflows. Record both the changes and the results. A remaining delay is a reason to refine the diagnosis, rather than install another optimisation module without understanding the cause.
Request a technical review when an issue repeats, interferes with enquiries or purchases and is not explained by one connection. An audit can start with a URL, an observation and your goal; passwords are not needed for an initial discussion. The review helps establish whether the next work belongs to a page, the application, the infrastructure or several parts together.
Common questions
Should we pursue the highest PageSpeed score at any cost?
The score can reveal issues, but the objective is a usable, functioning website. Assess improvements alongside real experience and working features. Removing a necessary form or analytics solely for a score is not a sound trade-off.
Will moving hosting solve the problem?
It may help if the measured cause is infrastructure capacity or operation. If images, scripts or rendering create the delay, a hosting move alone may not be enough.
What should I prepare before contacting you?
The affected URL, device, check time and a short sequence of actions. A reproducible journey is often more useful than one service’s score.
Sources and documentation
From understanding to action
Connect the decisions in one plan.
A focused check helps identify a cause. When changes involve structure, development, content and analytics, agree them together with priorities, ownership and verification.
Tell us about your website, priorities and the issue you have observed. We will discuss whether you need a focused stage or coordinated promotion and what the initial scope should include.
Discuss coordinated promotion