Your WordPress site is almost certainly slow because of one of eight things: unoptimized images, render-blocking CSS and JavaScript, plugin bloat, outdated PHP, no caching, an overloaded host, heavy web fonts, or a bloated database. Find the culprit in that order and you can cut load time dramatically without a redesign. On the site you’re reading this on, we found four of the eight and went from a slow first paint to a 99 performance score on Google’s PageSpeed test.
How do you know your site is actually slow?
Run the site through Google PageSpeed Insights and look at the field data first, lab numbers second. The three Core Web Vitals that matter are Largest Contentful Paint (LCP, should be under 2.5 seconds), Total Blocking Time (TBT, under 200 ms) and Cumulative Layout Shift (CLS, under 0.1). Then open the Network tab in your browser’s dev tools, reload, and sort by size: whatever downloads the most bytes is usually the start of the story.
1. Unoptimized images, the most common cause
Most slow sites we audit are carrying hero images of 2 to 5 MB straight out of a camera or design tool. Resize images to their display size, convert to WebP or AVIF, and lazy-load everything below the fold. A 2 MB hero can become 80 KB with no visible difference. This is the single highest-return fix available.
2. Render-blocking CSS and JavaScript
Every stylesheet and script that blocks the first paint pushes your content down the page. Inline the critical CSS, defer non-essential JavaScript, and delete unused CSS rules. A single render-blocking file can add a full second to first paint on mobile.
3. Plugin bloat
Every plugin adds scripts, styles and database queries to your page load. Sites with 60 or 70 plugins are common. Deactivate everything, measure the speed, then re-enable plugins one by one to see what each one costs. Most sites only need five to ten plugins, and the ones you don’t need should be deleted, not just deactivated.
4. Outdated PHP and WordPress core
PHP version is one of the biggest speed levers that gets ignored. PHP 5.6 runs WordPress two to three times slower than PHP 8.2 on the same server. Check yours under Tools, Site Health in the dashboard. The update schedule for core, plugins and themes is covered in detail in our note on how often to update WordPress.
5. No caching layer
Without a page cache, every single visitor makes WordPress regenerate the whole page in PHP and hit the database. A page cache stores the finished HTML and serves it instantly. Server-level caching is best, and a caching plugin is a decent second option. We measure this constantly on the sites we look after.
6. An overloaded shared host
Unlimited plans are shared, and shared means neighbors. If your Time to First Byte is consistently above 500 to 800 ms, your host is the bottleneck and no plugin will fix it. Moving to a managed WordPress host is usually the move.
7. Heavy web fonts
Font files and their CSS are render-critical. Stick to one or two families, load two or three weights at most, and subset the font files so you’re not shipping every glyph on earth. We once measured a client site where fonts alone delayed first paint by 900 ms.
8. Database bloat
Post revisions, expired transients and leftover plugin tables accumulate over the years and slow every query. Clean old revisions, delete transients, and optimize the tables. It’s maintenance, not magic.
How much does speed actually matter?
Research has repeatedly tied every extra second of load time to measurable drops in conversions and revenue, and Google’s own guidance on web performance treats speed as a quality and brand factor. Users perceive slow sites as untrustworthy, and Google ranks fast ones better. Speed is not a technical footnote, it’s revenue on the table.
Quick answers
How long should a WordPress site take to load?
Aim for an LCP under 2.5 seconds and a total load under 3 seconds on mobile 4G. Most well-optimized sites we run land at 1.5 to 2 seconds.
Do I need a paid speed plugin?
No. The eight checks above are free and fix the root causes. Paid plugins help at the margin, but nothing beats images, caching and clean code.
How do I know if my host is the problem?
Measure Time to First Byte. If it’s consistently over 500 to 800 ms on an empty page, the server is the bottleneck and a faster host will do more than any optimization.
Should I switch page builders to get faster?
Only if the builder is the confirmed bottleneck. A lean, hand-coded theme is always faster, but start with the eight checks above before rebuilding anything.
If you’d rather not run this checklist yourself, our speed optimization service does the whole audit and fixes it for you, with a before and after Core Web Vitals report. Care plan clients get it as part of the monthly rhythm.