Your website is slow: how to find what is slowing it
Separate hosting delay from page weight and blocking scripts so you can find the real cause of a slow site before paying anyone to fix it.
Slow is a symptom and not a diagnosis
The report usually arrives as a sentence. The site is slow on my phone. In the office on wifi it opens immediately so nobody can reproduce it. Somebody runs a test, installs an optimisation plugin and the layout breaks. Two weeks later the site is still slow and now it is also fragile.
Slowness has three causes and they need separate measurement. The server can be slow to answer. The page can be too heavy to download. Or the page can arrive quickly and then refuse to show anything because something is blocking it. The same complaint comes out of all three and the fixes have nothing in common.
What diagnosis buys and what it does not
A diagnosis is not a fix. Finding the cause and resolving it are separate pieces of work with separate costs, and some causes cannot be resolved without replacing the theme. Image optimisation, a delivery network, better hosting and developer hours are billed separately. Third party scripts are usually the largest single contributor and they belong to tools you chose. Diagnosis of this kind sits alongside crawl and indexing work in a technical SEO audit and the written scope is published on the service page. GST at 18% applies to the fee.
Your own cost is decision time. Somebody has to say which chat widget, heatmap tool, remarketing tag and font family is worth the delay it adds. That list is rarely shorter after the conversation unless somebody with authority is in the room.
Who should not spend money on this
If a rebuild is already planned then do not optimise the current theme. The work will be thrown away. If your site receives little traffic and the enquiries you do get arrive fine then speed is not your constraint and the money belongs elsewhere. And if the site is slow only inside your own premises then the fault is probably your own network, so test from mobile data before you commission anything.
There is a harder case. A site on the cheapest shared hosting running a page builder with a dozen plugins has a structural problem rather than a tuning problem. Optimisation plugins layered on top produce a slightly faster site that breaks in new ways every month. The honest answer is a rebuild on a leaner stack or a move to better hosting, and that is a larger spend than the one you came in asking about. Anyone who sells you a tuning exercise instead is selling you a second bill.
How to locate the actual cause
Begin with the server. Measure how long the first byte takes and repeat the test on a plain static file such as an image. If the static file is also slow then the problem is hosting or the network path rather than your pages. If it is quick and the page is not then the delay is in the application, which usually means database queries, an uncached page or a plugin doing work on every request.
Next measure weight. Open the request waterfall and sort by size. Uncompressed hero images are the usual culprit and the giveaway is an image whose file dimensions are several times larger than the space it occupies on screen. Fonts come next, especially when four weights are loaded and two are used. Then count third party requests and run the test again with them blocked. The difference between the two runs is the price of your marketing stack.
Finally look at what blocks rendering. Scripts and stylesheets loaded in the head hold the page back until they finish. Redirect chains add a full round trip each. Throttle the test to a mobile connection and use field data from real visitors alongside the lab test.
How to judge whether it improved
The metric that matters is field data from real visitors on mobile. Largest Contentful Paint tells you when the main content appeared and Interaction to Next Paint tells you whether the page responded when somebody tapped. Watch the behaviour of visitors on your highest traffic pages alongside those numbers.
The metric that flatters is the lab score out of a hundred. It is a weighted summary of one test on a simulated device and it swings between runs. A desktop test from a nearby server flatters harder still. Chasing the number rather than the cause is how sites end up with lazy loading on the one image that should load first.
The mistake that costs the most
The common mistake is installing an all-in-one optimisation plugin and switching every option on. Combining and deferring scripts in bulk breaks sliders, forms and payment flows in ways nobody notices until a customer cannot check out. Worse, aggressive caching hides the underlying fault so the next person to investigate finds a fast page and no cause.
The expensive variant is buying a content delivery network to solve a problem it does not address. A delivery network shortens the distance to your static files. It does nothing about a heavy database query, a blocking script or a hero image nobody compressed.
Fix in order of contribution
Work on the largest contributor first and retest after each single change. When two changes go live together and the page gets worse you cannot tell which one to undo.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.