A site that opened instantly yesterday may take several seconds today. Visitors leave before the page appears, paid traffic fails to turn into enquiries, and the business is left wondering what changed: hosting, a new plugin, a large image or a third-party script.
This guide takes a systematic approach: measure first, find the cause, then fix it. That avoids random changes and helps you start with the work most likely to make a difference.
Why website speed matters to a business
A slow page loses visitors before they see the offer. For an online store, that means abandoned orders; for a services site, fewer calls and enquiries; for advertising, spend that attracts people but does not bring them to action. Speed affects both usability and how search engines assess visitors’ experience.
The goal is not a perfect score in every test. Important pages should load quickly and reliably on real phones and computers. Start by recording baseline measurements, then change one factor at a time.
Measure first: tools and metrics
Check the homepage and key service or catalogue pages with PageSpeed Insights. Lighthouse in Chrome is useful for lab measurements, while WebPageTest reveals the request waterfall and helps identify which resource delays loading. Compare mobile and desktop, and save dated results.
TTFB is the time until the server begins responding. A high value points toward the server, database or server-side code. LCP measures when the largest visible element appears; INP measures responsiveness to user actions; CLS measures unexpected layout shifts. Good Core Web Vitals guidelines are LCP up to 2.5 seconds, INP up to 200 ms and CLS up to 0.1. Check Google’s current guidance before evaluating a site.
First ask: was the site always slow, or did it slow down recently?
If the site has been slow since launch, inspect its foundations: image sizes, scripts, caching, database queries and hosting capacity. If performance worsened recently, the date narrows the search. Compare it with a CMS, plugin or theme update, a new widget, heavy media, a hosting change or increased advertising traffic.
Do not change several things at once or it will be hard to tell what helped. When possible, reproduce checks on a staging copy. Before changes, make a backup and save your measurements.
Six common causes of a slowdown
Large images and video
Camera photos are often much larger than their displayed size. Resize and compress them, use suitable modern formats, and lazy-load images below the first screen. Check background video and sliders too: they can transfer a lot of data before a visitor interacts with the page.
Third-party scripts and widgets
Analytics, ad pixels, chat, maps and pop-ups add requests and code execution. Inventory integrations and remove anything no longer used. Load necessary scripts without blocking rendering; optional tools such as chat can wait until a visitor interacts.
Server, database and caching
A high TTFB may point to overloaded hosting, limited CPU or memory, inefficient queries or slow page generation. Check hosting metrics and logs. Cache pages and frequent queries, investigate slow queries, review indexes and clear unnecessary temporary data. A CDN can help when visitors are far from the server or the site has many static files.
Plugins, theme and outdated software
On a CMS, unused extensions can still add code and database work. Remove what is unnecessary, update the platform, and test questionable plugins one at a time on staging. Back up before updates and check compatibility with supported runtime versions.
Bots, attacks or malicious code
Unexplained load spikes, suspicious requests, unknown files, redirects or browser warnings may indicate bot activity or a compromise. Review logs and traffic sources. If there are signs of a breach, first contain unauthorized access and have security checked by a specialist; ordinary performance tuning will not remove the root cause.
Ask a question or leave a request
We can review performance, identify the bottleneck and prepare a fix plan.
By submitting the form, you agree to the processing of personal data.
A step-by-step diagnostic plan
- Record PageSpeed Insights results for the homepage and key pages on mobile and desktop.
- Find when the slowdown began and compare the date with updates, integrations and traffic changes.
- Compare TTFB with resource load times; use the waterfall to find the slowest and largest requests.
- Check server load, error logs, the database and unusual request sources.
- On staging, disable optional plugins and scripts one at a time, measuring after each change.
- Fix the confirmed cause and repeat the same measurements for a fair comparison.
What to fix first and how to prevent another slowdown
Start with quick, reversible improvements: compress images, remove unused integrations, enable caching and compress responses. Then investigate queries, configure a CDN, optimize code or change server resources if measurements point there. Record the result after every change.
Set alerts for availability and response time. Recheck key pages regularly and after significant changes such as updates, a redesign, a new widget or an ad campaign. Give the team a simple rule: optimize uploaded images and check new code’s impact before release.
Common mistakes and a quick checklist
Do not install a random “speed booster” before measuring: it may introduce conflicts without addressing the cause. Do not check only on a powerful computer or mistake a single lab score for the experience of real visitors. Measure again after a fix to see whether it worked.
- Baseline mobile and desktop measurements are saved.
- It is clear when and after what change loading worsened.
- TTFB, heavy resources, server load and logs have been checked.
- Images are optimized and unnecessary scripts and plugins removed.
- Caching, the database and signs of suspicious activity have been reviewed.
- Measurements were repeated after changes and monitoring is in place.