WordPress speed: getting to a 90+ score without a developer

Measure first, and know which number matters

Run your homepage and your most important inner page through PageSpeed Insights, on the mobile tab. You will see two kinds of results. The top section, when it appears, is field data: how real visitors on Chrome experienced your site over recent weeks. The score below it is lab data from a single simulated load on a slow phone.

The lab score is the one people screenshot, and it is useful for testing changes. But Google’s Core Web Vitals assessment uses field data — Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. A site can score 95 in the lab and still fail in the field if real visitors are on weak connections. Aim for both, and record the starting numbers before you touch anything so you know what each change did.

Hosting sets the ceiling

If the server takes a long time to send the first byte, nothing you do in WordPress fully recovers it. The cheapest shared plans often pack many sites onto one machine, and your site waits in line. PageSpeed Insights flags this as a slow initial server response.

You do not need expensive hosting. You need a plan with a recent PHP version, server-level caching or LiteSpeed support, and a data centre reasonably close to your visitors — for an Indian audience, a server in India or nearby in Asia rather than the United States. If your host offers a one-click PHP version change, move to the newest version your theme and plugins support; it is one of the easiest gains available.

Caching: one plugin, configured properly

A caching plugin saves a finished copy of each page so WordPress does not rebuild it for every visitor. Use exactly one. Two caching plugins fight each other and can make things slower or break the site. If your host runs LiteSpeed, its own cache plugin is usually the right choice; otherwise use a well-maintained alternative.

Turn on the settings in stages and check the site after each one, because some options break layouts or forms on certain themes.

• Page cache — the core setting. Turn it on first and confirm logged-out visitors get cached pages.
• Browser cache and compression — usually safe; lets repeat visitors reuse files.
• Minify CSS and JavaScript — small gain; test forms and menus afterwards.
• Delay or defer JavaScript — the biggest win for Interaction to Next Paint, and the most likely to break something. Exclude scripts one by one if it does.
• Remove unused CSS — powerful on page-builder sites, but check every template, not just the homepage.

Images: the fix that matters most on most sites

On the sites students bring to class, images are usually the largest part of the page. A phone photo uploaded straight from the camera can be several megabytes and thousands of pixels wide, displayed in a box a few hundred pixels across. The browser downloads all of it anyway.

Resize before upload to roughly the largest size the image is actually shown at. Serve modern formats: WordPress supports WebP natively, and recent versions also support AVIF if your server does. An image optimisation plugin can convert your existing library in bulk. Then make sure images below the first screen are lazy-loaded, and that the main hero image is not — it should load immediately, because it is usually your Largest Contentful Paint element.

Always set width and height on images, or let WordPress do it. Images without dimensions push content around as they load, which is exactly what Cumulative Layout Shift measures.

Page builders and the plugin audit

Page builders make design easy and pages heavy. Each section, animation and widget adds markup, styles and scripts, often loaded on every page whether used or not. You do not have to abandon the builder, but use its performance settings, avoid nesting containers inside containers, and drop entrance animations that delay content from appearing.

Then open the plugins list and ask of each one: is it active, is it used, and does something else already do this? Sliders, social share bars, multiple form plugins and old SEO tools are common culprits. Deactivate one at a time and re-test. A plugin that is deactivated but installed is not slowing pages, but delete it anyway if you no longer need it; outdated plugins are a security risk.

Fonts and third-party scripts

Custom fonts are a quiet cost. Each weight and style is a separate file. Use one or two families, only the weights you actually use, host them locally rather than pulling them from an external server on every load, and set font-display to swap so text appears immediately in a fallback font.

Third-party scripts — analytics, ad pixels, chat widgets, embedded maps and videos — are often the reason a well-optimised site still scores in the seventies. Load analytics with defer or delay it until user interaction through your caching plugin. Replace embedded YouTube videos with a lightweight click-to-load preview. Ask whether the chat widget actually produces enquiries; if it does not, a WhatsApp link does the same job for a fraction of the weight.

What a 90+ score does and does not mean

A high lab score is a good sign that the obvious problems are fixed. It is not a ranking guarantee, and chasing the last few points often costs more than it returns. A page that scores 88 and loads its main content quickly for real visitors is in better shape than one that hits 99 by stripping out the contact form.

Re-check field data a few weeks after your changes, because it updates on a rolling basis. Then make speed a habit: compress every new image before upload, test after every new plugin, and re-run PageSpeed Insights after any theme update. Sites rarely get slow in one go; they get slow one convenience at a time.