Making a WordPress site fast is less about one magic plugin and more about removing weight in the right order. Start at the server, then cache what you can, then shrink images, fonts and scripts. Skip a step and the later ones only half work: a caching plugin can’t rescue a site on overloaded hosting, and a fast server can’t hide a 4 MB hero image. This guide covers each layer and how to check that you have a fast WordPress site for real visitors as well as in a lab test.
What “fast” means in 2026
Google’s measure of real-world speed is Core Web Vitals. According to web.dev, a page is good when Largest Contentful Paint (when the main content appears) happens within 2.5 seconds, Interaction to Next Paint (how quickly the page responds to a tap or click) is 200 milliseconds or less, and Cumulative Layout Shift (how much things jump around) is 0.1 or less. Each is measured at the 75th percentile of page loads, separately for mobile and desktop. Check your field data in Search Console or PageSpeed Insights before you change anything, so you know which of the three you are fixing.
Hosting first: the floor under a fast WordPress site
WordPress’s requirements page recommends PHP 8.3 or newer and MySQL 8.0 or MariaDB 10.11 or newer. The same page warns that older versions which still run are past end-of-life and may expose your site to security problems, so check what your host runs; many control panels let you switch versions in a few clicks (test on staging first). If your server takes a long time to send the first byte even on a cached page, the hosting plan is the bottleneck and no plugin will fix it.
Caching: do the work once
Without caching, WordPress builds every page from PHP and database queries on every visit. A page cache stores the finished HTML and serves it directly. Many managed hosts include one at server level; otherwise a caching plugin does the job. Pick one, not two, since overlapping cache plugins cause odd bugs. Add a persistent object cache (such as Redis, if your host offers it) for sites with logged-in users, WooCommerce carts or heavy database work. A CDN then serves images, CSS and scripts from locations near your visitors, which helps a site in London with readers in Mumbai and Dubai.
WordPress itself helps here too. Since version 6.8, core uses speculative loading: by default, browsers that support it start fetching a linked page as soon as the visitor begins to click, which makes the next page feel quicker.
Images: usually the biggest win
On many business sites the largest element on the page is an image, which makes it the LCP element. Three fixes matter. Upload images close to the size they are displayed at, not straight from the camera. Use modern formats such as WebP and AVIF: WordPress has supported AVIF since version 6.5, provided your server’s image library does (Tools, then Site Health, then Info, then Media Handling shows the formats your server can process). And never lazy-load the main image at the top of the page. Google’s LCP guidance is explicit on this, and suggests marking the likely LCP image with fetchpriority=”high” instead. Give every image width and height attributes so the layout doesn’t shift as it loads.
Fonts: fewer, local, preloaded
Every font weight is another file. Two families with two or three weights each is plenty for most sites. Host fonts on your own domain rather than loading them from a third party: WordPress 6.5 added a Font Library that downloads Google Fonts to your server when you install them. Preload the font used in your main heading, and avoid font-display settings that hide text while the font loads, as web.dev advises.
Change one thing at a time and re-test. If you switch on five optimisation settings at once and the menu breaks, you won’t know which one did it.
Plugins and third-party scripts
Open your site with the browser’s developer tools and look at what loads on the home page. Contact form scripts loading on every page, a slider used on one page only, chat widgets, several analytics tags and social feeds all add up. Remove plugins you don’t use, replace heavy ones with lighter options, and load scripts only where they are needed. Third-party scripts hurt Interaction to Next Paint in particular, because they compete with the page for the browser’s attention after it has loaded.
If your site needs more than tuning, our website team rebuilds slow WordPress sites with speed set as a requirement from the start, and our digital marketing work ties speed to the search results that depend on it.
Frequently asked questions
Which caching plugin is best for WordPress?
The best choice depends on your host. Many managed WordPress hosts include server-level caching and recommend their own plugin or none at all, and adding another cache can cause conflicts. On basic shared hosting, a well-maintained page caching plugin makes a large difference. Choose one, configure it carefully, and test logged-out pages, forms and any shopping cart afterwards.
Why is my WordPress site slow on mobile but fine on desktop?
Phones have slower processors and often slower connections, so heavy images and JavaScript hurt far more. Desktop tests on office broadband hide the problem. Check the mobile figures in PageSpeed Insights or Search Console, then look at the largest image, the number of scripts and the fonts loading on mobile pages. Start with those three.
Does page speed affect Google rankings?
Google’s page experience documentation says Core Web Vitals are used by its ranking systems, but also that it aims to show the most relevant content even when page experience is poor. Speed matters most for visitors: slow pages lose people before they read anything, so treat it as a conversion problem as much as a search one.