Website is slow

My website is slow. Here is how to find out why.

Slow has two very different meanings, and the fix depends on which one you have. Work through this in order and you will know whether the problem is your images, your plugins, or the server you are paying for.

Answer these four first

  • Is it slow for everyone, or only on your computer? Open it on a phone with Wi-Fi off.
  • Is every page slow, or one page? One slow page is a content problem, not a hosting problem.
  • Was it always slow, or did it change on a specific date? Something was installed that week.
  • Is it slow to start, or slow to finish drawing? Those are two separate faults.

The checks, in the order that actually narrows it down

Every step below is something you can do yourself in a browser. Write the numbers down as you go, because the comparison between them is what tells you where the time is going.

  1. Split the wait into "before the first byte" and "after"

    Time to first byte (TTFB) is how long the browser waits before the server sends anything at all. That number belongs to your host, your database, and whatever PHP runs before the page is built. Everything after it belongs to the page: images, scripts, fonts, stylesheets. Run our speed test and look at TTFB on its own. Under about 600ms is healthy for a small business site. Consistently over a second on a simple page means the problem is the server, and no amount of image compression will fix it.

  2. Load the page twice and compare

    Open the page, wait for it to finish, then hard-reload it. If the second load is dramatically faster, caching is working and you were seeing a cold start. If both loads are equally slow, there is no page cache in front of the site, which is one of the cheapest wins available.

  3. Find the heaviest file on the page

    The speed test reports total page weight and the biggest assets. The single most common cause we see is a hero image uploaded straight off a phone at 4000 pixels wide and several megabytes, displayed in a box 1200 pixels wide. If total page weight is over roughly 2MB and most of it is images, stop here. That is your problem.

  4. Count the requests, not just the bytes

    A page pulling 90 separate CSS and JavaScript files is slow even when each one is tiny, because each has to be fetched. Page builders, sliders, icon packs, and half-used plugins each add their own. If the request count is high, the fix is removing plugins, not compressing images.

  5. Check the real-visitor numbers, not only the lab score

    PageSpeed Insights shows two things: a lab test run once on a simulated device, and field data from real Chrome visits. A page can score badly in the lab and be fine for real people, or the reverse. The field data is the one Google uses. If the site has too little traffic to have field data, the lab score is all you get and you should treat it as a rough guide.

  6. Test from a phone on cell data

    Your office Wi-Fi and desktop browser hide a lot. Most people finding a local business are on a phone, often on a weak signal. Turn Wi-Fi off and load the site. If it is unusable there, that is the version of your site most customers actually get.

The likely causes, roughly in the order we find them

This is the order these turn up in real Ohio small business sites, not a textbook ranking. Most slow sites have two or three of these at once.

Most common

Images that were never resized

How to check: Look at the largest assets in the speed test. Anything over about 300KB for a single photo is oversized. A 4MB hero image is not unusual on a site nobody has audited.

The fix: Resize each image to the size it is actually displayed at, save as WebP, set width and height attributes so the layout does not jump, and lazy-load anything below the first screen. On WordPress an image optimization plugin does most of this once and then keeps doing it.

Very common

Plugin and page builder bloat

How to check: Count the active plugins. Then look at how many CSS and JS files load on the home page. Many page builders and slider plugins load their whole library on every page, including pages that do not use them.

The fix: Deactivate anything you cannot name a use for, one at a time, checking the site after each. Replace a heavy slider with a single static image. If a plugin was installed for one page, restrict it to that page.

Very common

No caching in front of the site

How to check: If the second load of a page is no faster than the first, there is no page cache. On WordPress, check whether any caching plugin is active and whether the host does caching at the server level.

The fix: Turn on page caching, and object caching if the host supports it. This is usually the largest single improvement on a database-driven site and it costs nothing.

Common

Oversubscribed shared hosting

How to check: TTFB stays above a second even on a cached, mostly static page. The hosting control panel also feels slow. Traffic spikes make it worse in a way that looks nothing like an image problem.

The fix: Move to a plan with dedicated resources, or a different host. This is the one cause you cannot fix from inside WordPress.

Common

Third-party scripts loading on every page

How to check: Chat widgets, heat maps, two analytics tags because nobody removed the old one, ad pixels, review widgets, and fonts fetched from a third-party network. Each one is a connection to a server you do not control.

The fix: Remove duplicates, self-host fonts, and load chat widgets on click rather than on page load. Keep the tracking you actually read reports from.

Less common

Database bloat

How to check: Sites that have run for years accumulate post revisions, expired transients, and options set to autoload on every single request. The symptom is a high TTFB that gets worse over time with no obvious cause.

The fix: Clean out revisions and transients, and look at what is set to autoload. Take a backup first. This is safe work but it is work you cannot undo by hitting back.

Less common

Redirect chains

How to check: Type the bare domain with no https and no www, and watch the address bar. If it goes through three hops before it settles, every visitor pays for all three round trips.

The fix: Collapse the chain to one redirect: whatever a visitor types should land on the canonical version in a single hop.

When it is worth handing over

Some of this is a Saturday afternoon with a coffee. Some of it is not, and pushing on regardless is how sites break.

  • TTFB is still over a second after caching is on and the images are fixed. That is the host, and moving hosts means moving DNS and email without dropping either.
  • The site is only slow for logged-in users. That points at something running server-side on every request, which needs profiling rather than guessing.
  • You cannot disable a plugin to test it because you do not know what depends on it, and there is no staging copy to try it on.
  • The theme itself is the bottleneck, and getting the page fast means rebuilding it rather than tuning it.
  • You have made changes and it got slower, and there is no backup from before you started.

Questions people ask about slow websites

What do Core Web Vitals actually measure?

Three things, per Google web.dev documentation. Largest Contentful Paint (LCP) is how long until the biggest visible thing finishes drawing, and 2.5 seconds or less counts as good. Interaction to Next Paint (INP) is how long the page takes to visibly respond after someone taps or clicks, and 200 milliseconds or less counts as good. Cumulative Layout Shift (CLS) measures how much the page jumps around while it loads, and 0.1 or less counts as good. Google assesses them at the 75th percentile of real Chrome visits over a rolling 28-day window, so they describe your slowest quarter of visitors, not an average.

Is a PageSpeed score of 100 the goal?

No. The lab score is a simulation on one simulated device, and chasing the last few points usually means breaking something a customer cares about. The field data from real visits is the number that matters, and a site can be genuinely fast for real people with a lab score in the 70s.

Will moving hosts make my site faster?

It fixes exactly one category of slowness: a high time to first byte from an overloaded server. If your problem is a 4MB hero image or forty plugins, that image and those plugins move with you and the site is just as slow on the new host. Measure TTFB first.

How fast should a small business website be?

For a normal service business page, aim for the page being usable in about two seconds on a phone on a decent connection, with a TTFB under about 600ms. That is achievable on ordinary hosting with ordinary care. You do not need anything exotic.

Does image compression hurt quality?

Not at the level most sites need. Going from a 4MB camera original to a properly sized 200KB WebP is invisible on a screen at normal viewing size. The quality loss people worry about happens at much more aggressive settings than anything you need here.

Can you tell me what is wrong without me giving you access?

Usually yes for the first pass. Everything on this page can be measured from outside the site. I need access when the fix involves changing files, plugins, or hosting settings, not to work out what is wrong.

Send me the URL and I will tell you which of these it is.

No login required for the diagnosis. You get the actual cause, what it would take to fix, and an honest note about which parts you could do yourself.