Installing a speed plugin raises the score on most sites but rarely cuts load time as much as expected. The real gains sit in four places: image format, the LCP element, layout shift and third-party requests.
Most measurable speed gain in WordPress comes from four interventions: (1) converting images to WebP server-side — on most sites the single largest item; (2) announcing the largest above-the-fold image (the LCP element) with preload and exempting it from lazy loading; (3) closing layout shift (CLS) by giving images and logos explicit dimensions; (4) moving third-party requests such as Google Fonts onto your own server. Installing a plugin does not substitute for these.
Before optimising, know what is slowing the site down; otherwise hours go into the wrong place.
The practical method: open the network tab in developer tools, disable cache and load the page. Then answer two questions:
Those two answers set the order of work.
This is the single largest gain on almost every site, and the most frequently skipped step.
A typical WordPress uploads folder swells over the years with unoptimised JPEGs and PNGs. In a real case, a café's image folder dropped from about 147 MB to roughly 10 MB — through format conversion alone, with no visible quality loss.
The correct approach has two parts:
Things to watch: do not delete originals immediately (you may need to revert), check that transparency survives on PNGs, and actually look at the site afterwards. Over-compression costs more than the second it saves.
Largest Contentful Paint measures when the largest above-the-fold element is painted. On most sites that is a hero image, and the problem is this: the browser only learns the image exists after downloading and processing CSS.
Announcing it early removes that delay:
<link rel="preload" as="image"
href="/uploads/2026/hero.webp"
fetchpriority="high" />Two mistakes are common here:
loading="lazy" to an above-the-fold image does not improve LCP, it directly worsens it. Lazy loading is for images below the fold only.Note that the LCP element is not the same on every page. It may be a hero image on the home page, a product photo on a product page, and a block of text on an article page. If it is text, there is no image to preload — the work moves to fonts.
Cumulative Layout Shift measures content jumping while the page loads. It is the most irritating behaviour from a user's point of view: the line you started reading slides away, the button you were about to tap moves.
The cause is nearly always the same: the browser does not know in advance how much space an element will take.
<img> should carry width and height. The browser derives the aspect ratio from them and reserves the space up front.font-display: swap plus a closely matched fallback stack reduces it.A page using Google Fonts connects to at least two extra servers: fonts.googleapis.com for the stylesheet and fonts.gstatic.com for the font files. Each new server connection means a DNS lookup, a TCP handshake and a TLS negotiation.
Moving fonts to your own server removes both connections entirely:
woff2 file it references and place them on your site.@font-face rules into your own stylesheet verbatim — keep the unicode-range lines.preload the fonts used above the fold.Dropping the unicode-range lines is a common mistake. They tell the browser which file covers which character range; without them the browser downloads alphabets it does not need. For Turkish there is an extra catch: characters such as İ, ş, ğ and ç live in latin-ext — take only the latin file and those letters fall back to another font, leaving the text visibly mixed.
The same principle applies to all third-party requests: every external server is a source of delay, and most are not truly necessary.
The most dangerous part of optimisation is breaking what you are not measuring while improving what you are.
The commonest example: a speed plugin deferring all JavaScript. The score rises, the page feels fast — and WooCommerce's block-based checkout stops working, so customers meet "your cart is empty". The details and the fix are in a separate note.
So after every optimisation, check the flow, not the score: in a private window, add a product, go to checkout, fill the form. Sites scoring 100 that take no orders are far more common than sites scoring 80 that sell.
The order is clear: convert images to WebP, then preload the LCP element and exempt it from lazy loading, then fix images without dimensions, then move third-party requests in-house.
After those four, a speed plugin's contribution is measurable but small. Installed without them, it mostly decorates the score and leaves the experience unchanged.
Usually not. Plugins handle caching, compression and concatenation, which help — but they do not fix the unoptimised images that make up most of the weight on most sites, a wrongly flagged LCP element, or images without dimensions. Installed before those four are done, a plugin mostly decorates the score.
At sensible settings, imperceptibly. In a real setup an image folder dropped from about 147 MB to roughly 10 MB with no visible quality loss. Watch three things: do not delete originals immediately, verify transparency survives on PNGs, and inspect the site visually after conversion.
No — the opposite. Applying loading="lazy" to an above-the-fold image makes the browser request it later and worsens LCP directly. Lazy loading is correct only for images below the fold; the LCP element should be preloaded instead.
Yes, it is a measurable gain because two external connections disappear. When moving them, copy the @font-face rules verbatim and keep the unicode-range lines. Critical for Turkish: letters such as İ, ş and ğ live in latin-ext, so taking only the latin file leaves them rendered in a fallback font.