Why your WordPress site loads slowly, and what to check first

A slow site is not a cosmetic problem. Research from Google has found that as visits load time goes from one second to three seconds, the probability of a mobile visitor leaving increases by 32%, and by five seconds it more than doubles. Every second a page takes to load is a second your visitor spends deciding whether to stay or hit back. Speed also feeds directly into Google’s Core Web Vitals, which is a confirmed ranking signal. So a slow site does not just lose the visitors who arrive, it earns fewer visitors in the first place.

When a client asks us to look at a slow WordPress site, we do not start by guessing. We work through the same short list of causes, in the same order, because in practice they account for almost every slow site we have audited.

Start with hosting, before touching anything else

Cheap shared hosting is the single most common cause of a genuinely slow WordPress site, and it is the one most people check last. If your server takes 800ms or more just to respond before the browser has downloaded a single byte of your page (this is called Time to First Byte, or TTFB), no amount of plugin tuning will fix that. You are paying for a server that is shared with hundreds of other sites, all competing for the same limited resources.

You can check TTFB yourself in your browser’s DevTools under the Network tab, or with a free tool like GTmetrix. If it is consistently over 500-600ms, the fix is hosting, not a caching plugin.

Images are almost always the biggest single win

After hosting, images are where we find the most weight to remove. A photo straight out of a phone camera can easily be 4-8MB. Displayed on a page at 800 pixels wide, almost all of that data is wasted. The three things that matter are: resizing the image to the dimensions it is actually displayed at, compressing it properly, and serving it in a modern format like WebP or AVIF instead of an unoptimised JPEG or PNG.

WordPress will generate multiple image sizes automatically, but only if the original file was reasonable to begin with. Uploading a 6000-pixel-wide original and letting WordPress “handle it” is one of the most common ways a site quietly gets heavy over time.

Plugins: it is not the count, it is what they do

A common myth is that having “too many plugins” slows a site down. Thirty well-written, narrowly scoped plugins are rarely a problem. Three badly-written ones can be. What actually matters is what each plugin loads on every page: a page builder that ships its own copy of jQuery UI, a slider plugin loading its scripts and styles sitewide instead of only where the slider appears, or an SEO plugin duplicating output that another SEO plugin already produces.

The practical test is not “how many plugins do I have,” it is “does this plugin load its assets on pages where it is not even used.” A query monitor plugin, run temporarily, will show you exactly that.

Caching and a CDN

WordPress builds most pages dynamically from the database on every request, which is expensive to repeat for every visitor. A page caching layer serves a pre-built copy instead, which is usually the single fastest change you can make after fixing hosting and images. If your visitors are spread across regions, a CDN (content delivery network) then serves those cached pages and static assets from a location physically closer to each visitor, which matters more than people expect for a site with any international or out-of-town traffic.

What Core Web Vitals actually measure

Core Web Vitals are three specific metrics Google uses to judge real user experience, and they map closely to the causes above:

• LCP (Largest Contentful Paint) — how long the biggest visible element (usually a hero image or heading) takes to render. Driven mostly by hosting response time and image weight.
• INP (Interaction to Next Paint) — how quickly the page responds when someone actually clicks or taps something. Driven mostly by JavaScript, usually from plugins and third-party embeds.
• CLS (Cumulative Layout Shift) — how much content jumps around while the page is still loading. Usually caused by images or ads without a reserved size, or fonts loading late.

You can see your own site’s real-world scores for free in Google Search Console under the Core Web Vitals report, using actual visitor data rather than a lab test.

The order we actually check things in

• Server response time (TTFB) — is the hosting itself fast enough.
• Image weight — are images resized, compressed, and served in a modern format.
• Plugin and script weight — what is loading on pages that do not need it.
• Caching and CDN — is a built page being reused instead of rebuilt every visit.
• Core Web Vitals in Search Console — confirming the fix actually moved real-user numbers, not just a lab score.

Every one of these is checkable in under an hour. If you want a second pair of eyes on where your site is actually losing time, that is exactly the kind of audit we do as part of a website build or rebuild — get in touch and we will tell you honestly what is worth fixing first.