Why your WordPress site is slow, and the seven fixes that matter
Most slow WordPress sites share the same handful of causes. Where the weight comes from, how to find the culprit, and what to change first.
On this page 7 sections
Key takeaways
- The median mobile home page weighed 2,311 KB in 2024, and images and JavaScript made up most of it.
- Measure first: field data in PageSpeed Insights tells you which metric real visitors struggle with.
- Full-page caching and properly sized images are the two fixes with the biggest effect on most sites.
- Query Monitor shows which plugins, hooks and database queries slow down each page.
- Run a supported PHP version. PHP 7.4 lost security support in November 2022.
We audit a lot of WordPress sites, and the slow ones are rarely slow for exotic reasons. They are slow because of the same few things, roughly in the same order.
1. Measure before you change anything#
Open PageSpeed Insights and look at the field data first. It tells you whether real visitors struggle with loading (LCP), responsiveness (INP) or layout shifts (CLS). Each has different causes, so this decides where to start. Then install Query Monitor on a staging copy: it shows the slowest database queries, hooks and plugins for every page.
2. Images#
Images are the largest share of bytes on most pages. Upload sensible sizes, let WordPress generate responsive versions, use WebP or AVIF, and give the hero image priority:
// In a template: the hero image loads eagerly and first.
echo wp_get_attachment_image( $image_id, 'large', false, array(
'loading' => 'eager',
'fetchpriority' => 'high',
) );
3. Full-page caching#
Without caching, every visit runs PHP and queries the database. With it, the server returns a ready-made page in milliseconds. Use your host’s page cache or a caching plugin, and add a persistent object cache such as Redis for logged-in and dynamic pages.
4. Plugins#
Every active plugin is code that runs on every request. Remove the ones you do not use, replace heavy ones with lighter alternatives, and be suspicious of plugins that load their CSS and JavaScript on every page when you only use them on one.
5. Third-party scripts#
Chat widgets, heatmaps, extra analytics and tag managers compete for the browser’s attention and are the most common cause of poor INP. Audit them every quarter, and load the survivors after the first interaction or when they scroll into view.
6. Fonts#
Three font families in nine weights from a third-party service is a common pattern. Self-host one or two variable fonts instead, preload the main file, and use font-display: swap so text appears straight away.
@font-face {
font-family: "Brand Sans";
src: url("/fonts/brand-sans.woff2") format("woff2");
font-weight: 300 800;
font-display: swap;
}
7. Hosting, PHP and the database#
- Run a supported PHP 8 version. PHP 7.4 stopped receiving security fixes in November 2022 and is noticeably slower.
- Limit post revisions so the database does not grow forever:
define( 'WP_POST_REVISIONS', 10 );
- Check Tools → Site Health. It warns when autoloaded options, data loaded on every request, grow too large.
Measure again on a mid-range Android phone over a throttled connection after each change. Desktop numbers flatter everyone.
None of this requires new hosting to start. It needs measurement, a short list of changes, and someone who owns the result.
Sources and further reading
- Web Almanac 2024: Page Weight — HTTP Archive almanac.httparchive.org
- Optimization — WordPress Developer Resources developer.wordpress.org
- Query Monitor plugin — WordPress.org wordpress.org
- Supported PHP versions — php.net php.net
- Optimize resource loading with the Fetch Priority API — web.dev web.dev