How to Speed Up Your WordPress Site

This guide shows you how to make a WordPress site load faster, in plain language and in the order that actually gets results. A slow site costs you real visitors: people leave pages that take too long to appear, and since Google measures page-load experience through its Core Web Vitals, speed also affects where you rank in search. The work described here is often called page speed, site speed, site performance or web performance optimisation; they all mean the same thing. You will start by measuring your site honestly with the same tools professionals use, then work through the changes that give the biggest return for the least effort: running a current version of PHP, adding caching, optimising images, trimming plugins, choosing a lean theme, putting a CDN in front of your assets, cleaning up the database, and letting the browser lazy-load what it does not yet need. Most of it needs no code, and it is written for anyone running WordPress on Noiz hosting, from a solo blogger to a small team. Specific tools are named only as examples of a category, never as recommendations.

One thing to settle first: the server and network layer, the part that decides how fast the very first byte reaches the browser (opcode caching, HTTP/2, compression, fast storage, and the network path), is tuned for you at the Noiz hosting level. This guide concentrates on the application layer, the part you control from inside WordPress and your hosting control panel, because that is where most of the avoidable slowness on a WordPress site actually lives.

Last reviewed: 27 July 2026, against WordPress 7.0.2 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress documentation linked below.

Official Documentation Reference

• WordPress Optimization (Advanced Administration Handbook), the official overview of caching, database and image optimisation.
• WordPress Requirements, the recommended and minimum PHP and database versions.
• Image performance enhancements in WordPress 6.3, how core decides lazy-loading and fetchpriority.
• Core Web Vitals (web.dev), the definitions and target thresholds Google measures.

Prerequisites

• Administrator access to your WordPress dashboard. If you are not sure how to reach it, see How to log in to the WordPress admin dashboard.
• A recent, restorable backup taken before you change anything. Several steps here (PHP version, caching, database cleanup) can expose an incompatibility, and a backup is what turns a scare into a five-minute rollback.
• Ideally a staging site (a private copy of your live site) to test changes on first. If you do not have one, test during a quiet period and be ready to undo.
• Access to your files by SFTP or the control panel File Manager, and to your database through phpMyAdmin. On a managed plan you can ask the Noiz support team to make server-side changes for you.

Step 1: Measure before you touch anything

Optimising without measuring is guesswork. Take a baseline now so that every later change can be judged against it, and so you spend effort where it counts rather than on whatever the internet told you to worry about this week. The single most important idea here is the difference between two kinds of measurement.

• Lab data (synthetic) is a single test run in a controlled environment. It is repeatable and good for diagnosis, but it is not what your visitors experienced. Chrome's built-in Lighthouse, and tools that generate a waterfall chart of every request, produce lab data.
• Field data (real users) is collected from actual people who visited your site in real conditions. This is what Google uses to rank, and it is the number that ultimately matters.

A perfect lab score with poor field data is common and misleading, so always look at both. The tools worth knowing:

• PageSpeed Insights (pagespeed.web.dev) shows lab and field data side by side and is the closest thing to Google's own verdict on your pages. Test your home page and a typical inner page, on mobile and desktop.
• Lighthouse, built into Chrome's developer tools, runs a lab audit in your own browser and lists specific opportunities.
• A waterfall tool (the category includes several free web-based testers) shows every file the page loads, in order, so you can see exactly what is slow or oversized.
• A query-profiling plugin such as Query Monitor, a free developer tool, is the kind to reach for when a site feels sluggish for logged-in users. It breaks page-generation time down by plugin and shows slow database queries, so it tells you which component is the culprit instead of leaving you to guess. Deactivate it again once you have your answer.

The three Core Web Vitals are the metrics to write down. As of 2024 they are:

• Largest Contentful Paint (LCP), how long the main content takes to appear. Aim for 2.5 seconds or less.
• Interaction to Next Paint (INP), how quickly the page responds when someone taps or clicks. Aim for 200 milliseconds or less. INP replaced the older First Input Delay metric in 2024, so any guide still talking about "FID" is out of date.
• Cumulative Layout Shift (CLS), how much the layout jumps around while loading. Aim for 0.1 or less.

These targets are measured at the 75th percentile of your visitors, meaning three out of four page loads should meet them. Note your figures now, then re-run the same tests after each change so you can prove what helped.

Step 2: Run a current version of PHP

This is the highest-value change on the list and the one most often overlooked. WordPress is written in a language called PHP, and every page your site builds is assembled by PHP on the server. Each major PHP release has been substantially faster than the one before, so simply moving from an old version to a current one can cut page-generation time noticeably with no change to your site's content or design. Newer versions also receive security fixes that end-of-life versions do not.

WordPress recommends PHP 8.3 or greater. It will still run on 7.4 and up, but those older versions have reached end of life and no longer get security updates, so treat them as something to move off, not a comfortable place to sit.

Check the version you are on

In the dashboard go to Tools > Site Health > Info, open the Server section, and read the PHP version. Site Health will also warn you outright on its Status tab if the version is outdated.

Change it on Noiz hosting

You set the PHP version per site in your hosting control panel, which one depending on your plan:

• Plesk (on neo.noiz.co.za): open your domain, then PHP Settings, and pick the version from the PHP version menu.
• DirectAdmin: use the PHP version selector for the domain.
• ISPConfig: edit the website and choose the version from its PHP Version field.

If you are on a Noiz managed plan, you do not need to touch the panel at all: ask the support team to move your site to the current PHP version and they will handle it.

Before you switch: update WordPress core, your theme and all plugins first, then test on staging if you can. The only thing that breaks under a newer PHP version is old, unmaintained code, so an up-to-date site almost always upgrades cleanly. If a page does error after the change, revert to the previous version in the same panel screen, identify the outdated plugin or theme responsible, and deal with that before trying again.

Step 3: Add caching

Building a WordPress page from scratch means running PHP and querying the database on every single visit. Caching means saving the result of that work and handing out the saved copy instead of rebuilding it each time. It is usually the biggest front-end speed gain you can add, and there are several distinct kinds that solve different problems.

• Page caching saves the finished HTML of a page as a static file and serves that to visitors, skipping PHP and the database almost entirely. This is the big one for sites whose content does not change on every request, which is most sites. A page-caching plugin installs this in minutes.
• Object caching saves the results of individual database queries in fast memory so they are not repeated. A persistent object cache keeps those results between requests using an in-memory store such as Redis or Memcached, and pays off most on busy, dynamic or WooCommerce-style sites where full-page caching cannot be used. WordPress Site Health flags under Performance when a persistent object cache would help. This is a server capability, so on a managed plan ask Noiz support whether it can be enabled for your site.
• Browser caching tells visitors' browsers to keep a local copy of your images, CSS and JavaScript so repeat views load almost instantly. This is driven by HTTP headers and is generally configured for you at the hosting level.
• Opcode caching (OPcache) keeps PHP itself compiled and ready in memory. It is a server feature, enabled by Noiz, and needs nothing from you.

Two rules that save a lot of pain. First, never run two page-caching plugins at once; they fight each other and produce bizarre, hard-to-diagnose behaviour. Pick one. Second, whenever you make a change and do not see it on the front end, clear the cache before assuming the change failed, because you are very likely looking at a stored copy. Every caching plugin has a one-click purge for exactly this.

Step 4: Optimise your images

On a typical page, images are the single largest thing the browser has to download, which makes them the most reliable place to claw back load time. Four habits do most of the work.

• Resize before you upload. A photo straight off a phone or camera can be several thousand pixels wide and several megabytes in size. If it is only ever displayed at 1200 pixels wide, uploading the full-size original wastes bandwidth on every view. Scale it down to a sensible maximum first.
• Compress. Image compression removes detail the eye cannot see and can shrink a file by half or more with no visible loss. Image-optimisation plugins do this automatically as you upload, or you can compress before uploading.
• Use modern formats. The WebP and AVIF formats produce much smaller files than the older JPEG and PNG at the same quality. WordPress core has accepted WebP uploads since 2021 and added AVIF support in version 6.5, so you can use them directly; many optimisation plugins will also generate modern-format copies of your existing library.
• Serve the right size. WordPress already creates several sizes of each upload and, through srcset, lets the browser pick the one that fits the visitor's screen. Deleting the intermediate sizes to "save space" undoes this, so leave them in place.

A media library full of unused, oversized originals also bloats your backups and your disk usage. Clearing it out is a performance and housekeeping job in its own right, covered in the companion guide How to clean up your WordPress media library.

Lazy loading

Lazy loading means the browser only downloads an image when the visitor scrolls near it, rather than fetching everything up front. WordPress does this for you: since version 5.5 it automatically adds loading="lazy" to images below the fold. Version 6.3 refined it further, so that instead of lazy-loading the large image at the top of the page, core flags that one with fetchpriority="high" to fetch it first, which typically improves LCP. The two attributes are opposites and core never puts both on the same image, so the important thing is simply not to fight this with a plugin setting that force-lazy-loads every image, including the first one, as that pushes your LCP the wrong way. The same lazy-loading idea applies to embedded videos and iframes, which are heavy: load them on interaction, or use a lightweight preview thumbnail that only pulls in the real embed when clicked.

Step 5: Use fewer, better plugins

It is not the number of plugins on its own that slows a site, it is what each one does on every request. A plugin that adds database queries, makes calls to an external service, or loads its own CSS and JavaScript on every page is a tax you pay on every view, whether that feature is used on the page or not. The goal is to keep only what earns its place.

• Audit what is active. Deactivating a plugin is not the same as removing it; deactivated plugins still sit in your install. Delete the ones you are genuinely not using.
• Find the expensive ones. This is where the query-profiling plugin from Step 1 earns its keep: it attributes page-build time to specific plugins, so you can see which one is actually costing you rather than guessing.
• Prefer built-in features. WordPress core now does natively many things people still reach for a plugin to do. Every plugin you can replace with a built-in feature or a small code snippet is one fewer thing loading on every page.
• Be wary of do-everything plugins. A single large "all-in-one" plugin can load more code than the three focused plugins it replaced. Judge by measured impact, not by plugin count.

Trimming plugins has a second benefit beyond speed: every plugin is also code that could carry a vulnerability, so a smaller, well-maintained set is a smaller attack surface as well as a faster site.

Step 6: Choose a lean theme

Your theme decides how much code every visitor downloads before they see anything, so it has an outsized effect on front-end speed. The heavy end of the market is the "multipurpose" theme that bundles a page builder, sliders, icon fonts and several JavaScript libraries, and loads most of them on every page even when a given page uses none of it. The result looks impressive in a demo and drags on real Core Web Vitals.

The lightest option is a modern block theme (the kind edited through the Site Editor), including the default themes that ship with WordPress. Block themes tend to render leaner markup and lean on core features rather than bundling their own frameworks. If you are attached to a heavier theme, at least avoid stacking a bloated theme on top of a bloated page builder, since that doubles the weight. When you are choosing or changing a theme, test the candidate on staging and compare its Core Web Vitals against your current one before committing. A well-built lightweight theme with good content will out-perform a heavy, feature-stuffed one every time.

Step 7: Put a CDN in front of your site

A content delivery network (CDN) is a network of servers spread around the world that keep copies of your static files (images, CSS, JavaScript, fonts) close to your visitors. Someone loading your site from another continent is then served those files from a nearby location instead of making the full round trip to the origin server, which cuts latency. Many CDNs go further and cache your full HTML pages at the edge, compress and convert images on the fly, and absorb sudden traffic spikes.

A CDN sits in front of your hosting rather than replacing it, and most providers offer a free tier that is more than enough for a typical site. It helps most when your audience is geographically spread out or your site is image-heavy. This guide stays neutral on which one to use; if you want a recommendation suited to your traffic and audience, the Noiz support team can advise.

Step 8: Clean up the database

Over time a WordPress database accumulates data that no longer serves any purpose but still has to be read, backed up and searched through. Clearing it out keeps queries quick and backups small.

• Post revisions. WordPress saves a copy every time you save a draft, so a single much-edited page can hide dozens of old revisions. You can cap them by adding a line such as define( 'WP_POST_REVISIONS', 5 ); to wp-config.php (keeping the five most recent), and clear the historic build-up with a maintenance tool.
• Auto-drafts, trashed posts and trashed comments. These linger until emptied.
• Spam comments. Delete them rather than leaving them queued.
• Expired transients. These are temporary cached values; stale ones pile up and can safely be cleared.
• Autoloaded options. This is the quiet one worth knowing about. A set of rows in the wp_options table is loaded on every page request, and plugins that were removed carelessly often leave large entries behind that are still being autoloaded for no reason. WordPress advises keeping the total autoloaded data under roughly 800KB. A cleanup plugin, or Site Health, can show you when this has grown out of hand.

Doing it on Noiz

The safe route for most people is a reputable database-maintenance plugin, which handles the above from inside the dashboard. If you prefer to work directly, you can reach your database through phpMyAdmin in your control panel: there you can run an Optimize table on your WordPress tables to reclaim space and tidy their storage. Whichever route you take, export a backup of the database first, from phpMyAdmin or through your panel's backup tools, because database edits are not something you want to undo by hand. Managed-plan clients can simply ask the Noiz support team to run the cleanup and optimisation.

Step 9: Measure again and keep it that way

Re-run the exact tests from Step 1 on the same pages, and compare against the baseline you saved. Field data (real-user Core Web Vitals) takes time to catch up because it is gathered from actual visits over a rolling window, so give it a few weeks before judging the real-world outcome, while the lab tools will show the improvement immediately. Performance is not a one-off task: new plugins, a redesign, a heavier theme or a growing database can all erode it, so re-check after any significant change and revisit every few months.

Troubleshooting

• Symptom: the site broke or a page shows an error right after changing the PHP version. An outdated plugin or theme does not support the newer PHP. Revert to the previous version in the same panel screen, then update or replace the component responsible before trying again.
• Symptom: your change does not appear on the front end. You are almost certainly seeing a cached copy. Purge the page cache (and your CDN cache, if you use one), then reload. Test in a private browser window to rule out your own browser cache.
• Symptom: layout looks broken or scripts stop working after adding a caching or optimisation plugin. Features that combine or defer CSS and JavaScript can occasionally clash with a theme or plugin. Turn those specific options off one at a time to find the culprit, and exclude that asset rather than disabling caching entirely.
• Symptom: two caching plugins are installed. Deactivate and delete one. Running two produces unpredictable results that are very hard to diagnose.
• Symptom: a great lab score but the site still feels slow to visitors, or fails Core Web Vitals in Search Console. You are comparing lab and field data. Trust the field data, and look especially at INP (real interactivity) and LCP on mobile, which lab tests on fast connections tend to flatter.
• Symptom: Site Health warns that no persistent object cache is in use. That store (Redis or Memcached) is a server feature. On a managed plan, ask Noiz support whether it can be enabled for your site; on a busy dynamic site it is worth having.
• Symptom: images are still huge after installing an optimisation plugin. Most plugins only optimise new uploads automatically. Run its bulk or "regenerate" action to process the images already in your library.

Getting Noiz to help

Several of the highest-impact steps here (moving to a current PHP version, enabling server-side and object caching, and running a safe database cleanup) are exactly the kind of thing the Noiz team does day to day. If you are on a Noiz managed hosting plan, you do not need to perform them yourself: contact the support team and they will handle the server-side work and advise on the rest. If you self-manage your hosting, support can still help on a billable basis, and can point you to the right settings for your specific control panel.