On this page
The problem
A slow website is money lost, and in the case of WordPress, a slow WordPress site usually performs very poorly. Every extra second of load time on mobile noticeably lowers conversion, and since Core Web Vitals became a ranking signal (SEO), it lowers traffic too. Noticing speed problems is an interesting thing: the usual approach is simply to look at numbers (PageSpeed) or at “how long it takes” to load on the phone or computer, and while that isn’t wrong, it doesn’t take into account the user experience (sections that shift around, poor display) that tends to come with loading problems, and on top of that, load speed problems usually come with two traps:
The first: the cause is almost never the one people assume. The typical response is to install a caching plugin with the default settings, hope it “fixes itself” and assume the biggest problem is the server or hosting. Going after it only with a caching plugin doesn’t really make a big impact and often causes a lot of display problems, when the real problem is somewhere else: render blocking, heavy images, external fonts or a saturated database. Without a real diagnosis (what is blocking the LCP, which script triggers the INP, which CSS is critical per template), any optimization is closer to guessing.
The second trap is chasing a 100 on PageSpeed as if it were the goal. It isn’t. The number is only useful when there’s a business goal behind it that justifies it: selling more, getting more inquiries, ranking better. Optimizing correctly is done for a goal, and it requires a broader, overall view than a number.
Core Web Vitals
Since Core Web Vitals became a Google ranking signal and affects your rankings (SEO), speed stopped being only about user experience, and LCP, INP and CLS measured in production have a direct impact on your site and your business.
I measure and report on mobile because that’s where Google evaluates the site and where slowness is usually most noticeable; desktop is measured and improved too.
What I do
- Before and after measurement: every URL I optimize is measured at least 3 times in production under the same conditions, and I report the median. A single PageSpeed run varies too much and misleads, for better and for worse.
- Critical CSS per template: extracted with my own customized pipeline (home, category, product); I don’t use a generic “automatic optimization” plugin.
- Removal of render-blocking CSS/JS, identified by measuring the real load in desktop and mobile browsers, and optimized so it doesn’t break any basic functionality or visual element of the site.
- Optimized images: conversion to AVIF/WebP with fallback, correct lazy loading, explicit dimensions to avoid layout shift.
- Self-hosted fonts with preload, removing the blocking effect of external fonts (Google Fonts or others) on the initial render.
- Minification and Brotli compression at the server level: precise configuration rather than a generic caching plugin.
- Staging before production: full backups and incremental changes with validation at each step.
If you only need speed for WordPress: WP Rápido (site in Spanish) is my load speed optimization service specific to WordPress: the plan depends on the size of the site and on the problems that show up when measuring it. If instead speed is part of a broader project or the site calls for something custom (a store with thousands of products, a homemade theme, a server that needs reconfiguring), in that case I take the project on here. If your case fits WP Rápido, I’ll tell you in the diagnosis and we continue that way.
What’s left out: if what the site needs is to be rebuilt from scratch, then we’re no longer talking about an optimization process but about WordPress development. I’ll let you know in good time if that’s your case, instead of forcing patches or optimizations onto a foundation that really can’t take any more. The diagnosis matters for this, and it’s also worth mentioning that WordPress isn’t necessarily the answer to your needs, and it could also be a web design project.
Real case
This case is proof that what matters is what changes behind the number. The toughest rescue in the portfolio is 2eme, a WordPress services site that went from 45 to 94 on mobile PageSpeed, with the home page LCP dropping from 13.3s to 2.3s and the worst page from 28.2s to 2.2s, measured with medians of at least 3 runs so as not to report noise.
At PMK Autopartes I brought mobile LCP down from 11.0s to 6.14s (-44%) with my own per-template Critical CSS pipeline, and at Comercial Moya, −92% in server response time (2.60s to 0.20s) after finding the root cause (bots saturating PHP-FPM) plus the upgrade from PHP 7.4 to 8.2, with the new site set up in an isolated staging environment, without cutting off production.
Three published rescues with three different problems (LCP out of control, render-blocking CSS, saturated server) and the same method: measure seriously, find the root cause and verify that the improvement holds. A site that loads fast isn’t a vanity achievement: slowness on mobile costs sales, and bringing these numbers down means you stop losing them.
Speed also has to be sustained: an optimized site that nobody maintains degrades again with every plugin and update. That’s what the monthly maintenance plan is for.
How I do it
- 01
Diagnosis
I measure in production (real waterfall, LCP, INP, CLS) and find what is blocking the site's load at the root.
- 02
Optimization
I go after the cause of the problems: Critical CSS per template, smaller image weight and dimensions, self-hosted fonts, deferred JS and server-level compression, in staging and in planned steps.
- 03
Verification
I measure before and after and show you the impact on the metrics that matter for the business, beyond the synthetic score.
What you get
- A site that loads fast on both mobile and desktop and works well, rather than just a green number in the demo.
- Before and after metrics measured in production under the same conditions, so you can see exactly what changed. Each optimized URL is reported as the median of at least 3 measurements.
- The root cause of the speed problems explained clearly and simply: what was slowing the site down, and why?
- Changes made in staging with a backup, so your live site is never down.
Why is my WordPress site slow?
There are many possible answers, and usually it isn't the one everyone assumes at first, the server. PageSpeed gives us a good first diagnosis, and after that what matters is analyzing that information, the site and the server. Common causes tend to be CSS and JavaScript that block rendering, heavy images served in an old format, external fonts that slow down the load, or a specific plugin saturating the database. That's why installing a caching plugin and hoping it fixes things doesn't usually work, and it often causes more visual problems than the performance problems it solves. Without measuring in production what is really hurting, we're guessing. The first thing I do is a real diagnosis, rather than a blind change.
Isn't a caching plugin like WP Rocket enough?
It helps, but it's rarely the complete solution. A caching plugin works when the bottleneck is exactly what that plugin targets, but when the problem is something else (render blocking, images, database), you leave it configured and the site is still slow. The difference lies in measuring the cause before touching anything, rather than installing the tool blindly and crossing your fingers.
How much faster can you make it?
It depends on the starting state of the site and the type of site, so I don't promise a number blindly. As a real reference: a corporate site went from 45 to 94 on mobile PageSpeed, in a store I brought mobile LCP down from 11.0 to 6.14 seconds, and on another site server response time dropped 92% once I found the root cause. In the free diagnosis I show you your site's waterfall and tell you what improvement is realistic and where it starts.
Is there any point in scoring 100 on PageSpeed?
Only if that number has a real consequence for how your business works. A 100 that doesn't translate into more sales, more inquiries or better rankings looks nice but isn't really useful. I don't optimize for the meter, I optimize so the site stops costing you customers. If someone offers to inflate the number with tricks that don't improve the real experience, they're not really selling you something you need.
How much does it cost to optimize the speed of a WordPress site?
It depends on the problem and how complex it is. For custom builds and other platforms I don't have standard prices: the cost depends on what the problem is, and that's why the free diagnosis is essential to the process. For WordPress I do have them, published on my WP Rápido service (site in Spanish): the plan depends on the size of the site and on the problems that show up when analyzing it. During the diagnosis I review your site live and tell you what your site needs.