A slow website: what to check before moving to a new server

“The website is slow” describes an impression, not a cause. One visitor waits for the main image, another cannot open a menu and a third watches a button move just before tapping it. These problems need different fixes.

Describe the symptom

Record the page, device, connection and action that exposes the problem. Compare a first visit with a repeat visit. A developer’s workstation does not represent an ordinary phone on a mobile connection.

Ask the person reporting the issue to describe the expected result. A repeatable sequence is more useful than a general score.

Separate loading, response and stability

Within Core Web Vitals, LCP concerns the appearance of the largest visible content element, INP concerns interaction responsiveness and CLS concerns layout shifts. Read the definitions on web.dev.

Measure first, then examine the page resources. For a large image, compare file size with its actual display size. For a delayed interaction, investigate JavaScript work. For shifting blocks, check whether space is reserved for media and embedded content.

Change one cause at a time

Keep a baseline, then try one change: a lighter cover, removal of an unnecessary widget or explicit media dimensions. Repeat the same scenario several times. One good run does not establish a lasting improvement.

If the document itself arrives late, investigate the server and network. If it arrives quickly but the interface takes time to assemble, changing hosting alone may not solve the problem.

Test the useful action

After optimisation, open the page, read the offer, complete the form and receive its response. A fast site with broken submission still fails the visitor. Make sure removing scripts has not removed required behaviour.

Keep a short log of the symptom, change, measurement and outcome. It can help prevent the same problem returning during the next release. Once speed is acceptable, review how understandable your enquiry form is.