[email protected]
0333 050 1245

Slow Website Fixes for Site Owners: Verify Before Hiring an Agency

  1. Home
  2. »
  3. Blog
  4. »
  5. Slow Website Fixes for Site Owners: Verify Before Hiring an Agency

Optimising images, enabling compression and caching, deferring non-critical JavaScript and checking hosting response time (TTFB) are the fastest ways to speed up most slow sites. Verify every change with Core Web Vitals (LCP, INP and CLS) plus a Lighthouse or WebPageTest run before and after. The prioritised checklist further down gives you the order to work in.

TL;DR:

  • Use the Network tab to distinguish slow server response from late rendering; high TTFB points to hosting, while quick TTFB points to images or scripts.
  • Aim for an origin response near 200 ms; test several pages at different times, and consider upgrading if resource limits throttle the site.
  • For WordPress, page caching skips rebuilding HTML, object caching avoids repeated database lookups, and opcode caching keeps compiled PHP in memory.
Kukoocreative
Build a Website That Works Better
Kukoocreative has partnered with business owners for over a decade to create websites that build brand recognition and connect with the people who matter.

Visit Kukoocreative

Table of Contents

Why is my website slow? A diagnostic checklist

Before you change anything, work out which class of problem you have. Fixing the wrong layer wastes a weekend and moves no metric. These are the usual suspects, and each leaves a recognisable fingerprint:

  • Unoptimised images: huge hero photos or uncompressed PNGs. Lighthouse flags oversized images, and visitors see the main banner pop in late.
  • Render-blocking JavaScript and CSS: scripts in the head that stop the browser painting anything. The page sits blank, then appears all at once.
  • Too many HTTP requests: dozens of small files, fonts and widgets. The network waterfall looks like a long staircase.
  • Slow hosting and high TTFB: the server takes too long to answer the first request. Every page feels sluggish, even simple ones.
  • Database problems: bloated tables or slow queries. Pages that pull lots of content, such as shops and archives, suffer most.
  • Excessive redirects: chains such as http to https to www to a trailing slash. Each hop adds a round trip before content starts.

Confirm the cause with two quick checks. First, open your browser’s developer tools, go to the Network tab and reload: look at the first request’s wait time (that is your TTFB) and scan the waterfall for giant files or long chains. Second, run the page through PageSpeed Insights rules, which cover redirects, compression, server response time, caching, minification, images and render-blocking scripts in one pass.

If the first request is slow, start with hosting and the backend. If it is quick but the page paints late, start with images and scripts. That single distinction saves hours.

Two routes distinguish slow response from late paint

Quick wins you can apply today: images, caching, compression and minification

These changes need little technical skill and usually deliver the biggest gains.

  • Resize and compress images before upload. A large photo displayed much smaller than its original dimensions wastes bytes.
  • Use WebP where you can, and always set width and height attributes so the browser reserves space and your layout does not jump (this protects your CLS score).
  • Enable Gzip or Brotli compression on the server so text files travel smaller.
  • Set proper cache headers. The GDS Way recommends fingerprinting assets so they can be cached for a long time using Cache-Control and ETag headers, with static assets cached for anything from one week up to one year.
  • Minify CSS and JavaScript, inline the critical CSS needed for the top of the page, and defer scripts that are not needed straight away.
  • Lazy load offscreen images and video so the browser only fetches what visitors can actually see.

Caching deserves a plain-English split, because the terms get muddled. A page cache stores finished HTML so the server skips rebuilding the page for every visitor. An object cache stores the results of database queries so repeated lookups are cheap. An opcode cache keeps compiled PHP in memory so the server does not re-read and re-compile code on every request. For WordPress, the official optimisation guidance says caching is the biggest fast win, and it pairs it with image optimisation and trimming unnecessary plugins.

If you are weighing up a caching plugin such as WP Rocket against an all-in-one service such as NitroPack, the principles above apply to both. Judge each by whether it gives you page caching, compression, minification and deferral you can verify in your own audits, then test the result rather than trusting a settings screen.

Pro Tip: Change one thing at a time and re-test after each change. If you switch on five optimisations at once and the site breaks, you will not know which one caused it.

If you want to tidy up your wider approach to conversions at the same time, our guide to website optimisation steps shows how speed work and conversion work reinforce each other.

Hosting and server checks: measuring TTFB and resource limits

Hosting is the root cause more often than owners expect. You can have perfect images and still crawl if the server is starved of resources. The GDS guidance starts with a methodical review of server response time and resource usage, and we do the same.

  1. Measure TTFB. Use the Network tab, WebPageTest or PageSpeed Insights. As a working target, aim for an origin response under roughly 200 ms. Test several pages, not just the home page, and at different times of day.
  2. Open your hosting dashboard or cPanel and check CPU, RAM, I/O and entry process usage. If you keep hitting limits, the server is throttling your site, and no front-end tweak will cure that.
  3. Run a slow-plugin check on shared hosting. This shared hosting troubleshooting guide suggests tools such as PHP X-Ray to find slow plugins and queries, then upgrading to a VPS if resource limits are consistently reached.
  4. Decide whether to upgrade. Moving from shared hosting to a VPS or managed hosting gives you dedicated CPU and RAM, and SSD or NVMe storage makes disk-heavy work noticeably quicker. If you are running a busy shop or a membership site on an entry-level shared plan, this is often the single most effective step.
  5. Keep the stack current. Enable the opcode cache and keep PHP and server software up to date, since newer versions are generally faster and safer.

If the numbers say hosting is the bottleneck, be honest about it. Spending weeks on micro-optimisations while the server is overloaded is the classic way to burn time and budget.

Plugins, scripts and third-party resources: audit and reduce bloat

Every plugin, tracking pixel, chat widget and embedded video adds weight, requests and processing. The cumulative effect is what turns a snappy site into a slow one.

  • Isolate slow plugins. On WordPress, deactivate plugins one at a time (on a staging copy if you can), re-run your speed test after each, and note which one moves the numbers. Re-enable the ones that are not guilty.
  • Audit third-party scripts. List every external script your pages load: analytics, ads, heatmaps, chat, fonts. Remove what you do not use and load the rest with async or defer so they do not block rendering.
  • Use a persistent object cache where your host supports it. It reduces repeated database work, which helps most on dynamic pages.
  • Split code and trim requests. Load only the JavaScript a page needs, and combine or remove files where it makes sense. Fewer round trips means faster paint.
  • Check mobile specifically. Phones have slower processors and patchier connections, so a script that feels fine on your desktop can stall a mid-range handset.

The aim is not zero third-party code. It is knowing what each script earns for you and making sure the expensive ones do not delay what visitors came to see.

CDN and protocol upgrades: benefits and configuration pitfalls

A content delivery network (CDN) stores copies of your static files on servers closer to your visitors, which cuts latency and takes load off your origin. Cloudflare’s speed tips highlight DNS, CDN, image optimisation and caching features as effective levers, and note that free and low-cost plans can include many of them.

  • Edge caching serves images, CSS and JavaScript from a nearby location, which helps visitors far from your server.
  • HTTP/2 and HTTP/3 let multiple resources share one connection and compress headers, reducing round trips.
  • Watch for coalescing and cross-origin issues. The Gov shows the caveat clearly: HTTP/2 can bring large gains but may worsen performance if Subresource Integrity and CORS are not handled correctly. Their fix involved removing SRI for CSS and JavaScript and changing asset hosting so connections could be coalesced.
  • Test after switching on. Check that fonts, scripts and images still load, then re-run your audits and refine the cache rules.

A CDN is not magic. It helps most when your assets are cacheable and your visitors are spread out, so get the cache headers right first.

Database and backend optimisation: cleanups and caching

When TTFB is high and the front end is already tidy, the backend is the next place to look. Dynamic sites build pages from database queries, so a heavy or untidy database slows everything.

  1. Trim autoloaded options. On WordPress, a large autoload set is read on every request. Remove leftovers from deleted plugins and keep autoload size small.
  2. Add a persistent object cache and schedule regular maintenance: clear old post revisions and expired transients so tables stay lean.
  3. Separate services when you outgrow one box. If the database and web server compete for the same resources, moving the database to its own service, or adding read replicas on larger setups, spreads the load.
  4. Watch slow queries. Enable slow query logging, find the worst offenders and add indexes where they make sense.

Intermittent slowdowns, such as fast in the morning and sluggish at peak times, often point here. Our piece on website maintenance explains why scheduled upkeep stops these problems creeping back.

Measuring, testing and monitoring: Core Web Vitals, Lighthouse and RUM

You cannot improve what you do not measure, and you cannot prove an improvement without a baseline. Core Web Vitals give you three numbers to track: LCP (how fast the main content appears), INP (how quickly the page responds to interaction) and CLS (how much the layout shifts).

  • LCP: good is 2500 ms or less, poor is over 4000 ms.
  • INP: good is 200 ms or less, poor is over 500 ms.
  • CLS: good is 0.1 or less, poor is over 0.25.
  • Use synthetic tools such as Lighthouse and WebPageTest for repeatable lab tests, and run them from locations that match your audience.
  • Add real-user monitoring (RUM) so you see what actual visitors experience, then prioritise by real impact.
  • Check key journeys by hand, such as checkout, contact forms and search, because automated scores miss broken flows.

Web, and a page is judged at the 75th percentile of page views. In practice, that means three in four visits need to hit the “good” mark, so fix the slow tail, not just your best-case run.

Field data matters more than lab data. As web.dev’s Web Vitals overview explains, synthetic tools miss the variability of real networks and devices, so treat them as a diagnostic aid rather than the final verdict. Our guide on performance budgets shows how to turn these targets into limits your whole team can work to.

Prioritised action checklist: step by step from diagnosis to verification

Work through this in order. Each step builds on the one before, and each ends with a measurement.

  1. Run baseline audits. Use Lighthouse, WebPageTest and any RUM data you have. Record LCP, INP, CLS and TTFB so you have a before picture.
  2. Fix images, compression and cache headers. Resize and compress images, switch on Gzip or Brotli, set long cache times with fingerprinting, and lazy load offscreen media.
  3. Cut script weight. Defer or remove heavy scripts, disable suspect plugins one by one, and add object and opcode caching.
  4. Test hosting resources. Check CPU, RAM and I/O usage. Add a CDN, or upgrade your hosting, if the limits are being hit.
  5. Re-test and monitor. Re-run the same audits, compare against your baseline and set up continuous monitoring so regressions get caught early.

Pro Tip: Keep a simple log with the date, the change and the before and after numbers. It stops you repeating failed experiments and gives an agency a clear starting point if you later need help.

Before you ask anyone for a quote, a proper audit pays for itself, as we explain in why website audits matter.

When to fix it yourself and when to hire an agency

Image compression and basic caching are very doable on your own. Server configuration, complex database tuning and protocol coalescing problems are where a developer earns their fee. Bring your audit data and admin access when you get in touch, and we will show you where the biggest gains sit. We combine design and technical delivery, so speed work and the look of your site stay in step.

— Kukoo

Let us handle the heavy lifting on your site speed

If you would rather have the work done than learn every setting, we can help. Here is what we offer for speed and performance:

To get started, send us your site address, admin or hosting access, any recent Lighthouse or WebPageTest reports and a short note on your goals. We will come back with clear next steps. Request your speed improvement now and we will get to work.

Kukoocreative

FAQ

How do you fix a slow website?

Start by measuring: run Lighthouse or WebPageTest and note your LCP, INP, CLS and TTFB. Then work through images, compression, caching, deferred scripts and hosting in that order, re-testing after each change.

Why is my website slow when my internet is fast?

Your connection is rarely the problem. Slow pages usually come from a slow server response, oversized images or heavy scripts. Check your TTFB and network waterfall to see which one it is.

What are the most common reasons a website is slow?

The usual causes are unoptimised images, render-blocking JavaScript and CSS, too many requests, weak hosting and a bloated database. PageSpeed Insights rules cover most of these checks.

What is a good Core Web Vitals score?

Good means an LCP of 2500 ms or less, an INP of 200 ms or less and a CLS of 0.1 or less, judged at the 75th percentile of page views, per web.dev’s thresholds.

Sources