When a website is slow, the conversation usually starts with the wrong tool: “install a cache plugin”, “switch hosting”, “add a CDN”. Sometimes it works. Almost never is it the diagnosis.
Speed is a chain. If the bottleneck is a database query, compressing images does not fix it. If the problem is a font blocking the render, changing servers does not either. That is why the first question is not which tool, but who needs to look at this.
These are the five profiles involved, what each one solves and how to know which one you need.
01Quick summary
- FrontendCSS, JavaScript, fonts, images and everything that happens in the browser. It usually has the biggest visible margin for improvement.
- Backend / WordPressPHP, queries, plugins and server response time. If the HTML is slow to arrive, the browser cannot do magic.
- Hosting and infrastructureServer, PHP version, object cache, CDN and WAF. It is the foundation; it does not replace the rest.
- Content and designImage weight, fonts, videos and third parties. Editorial decisions with technical consequences.
- Business and analyticsWhat “fast enough” means, what is measured and what is prioritized. Without this, you optimize blind.
02How speed is measured
Before touching anything, three things that usually get mixed must be separated:
- Lab: controlled conditions. Useful for comparing and finding bottlenecks, not for representing all users.
- Field: real data from people with their network, their device and their location. This is the reference that matters.
- Perception: when the page appears to respond. A blocked render can make a site “feel” slow even when the server responds fast.
The metrics I use to order the work are LCP (when the main content appears), INP (how long the interface takes to respond) and CLS (how much the layout jumps). TTFB helps separate the server problem from the browser problem.
Do not optimize a metric that has not been measured twice: before and after. And do not promise a 100/100 Lighthouse score as a business result.
03The five profiles
1. Frontend development
What it solves: the browser’s critical path. CSS and JavaScript that block, fonts that take too long, images that load when they should not, animations competing with interaction.
When it steps in: TTFB is reasonable, but LCP is slow; the page “jumps” on load; INP worsens when interacting.
What you can ask of it: prioritize above-the-fold content, reduce third-party JS, load fonts with discipline, reserve space for images and measure the result in the field.
The HTML arrives fast, but the browser is slow to paint the main content or the interface does not respond to clicks.
2. Backend and WordPress
What it solves: the time the server takes to build the response. Slow queries, plugins that run on every load, heavy hooks, badly built loops, missing object cache.
When it steps in: TTFB is high, the site is equally slow in incognito, or the problem appears only with certain plugins or pages.
What you can ask of it: profile queries, review plugins, separate the problem of the theme from the core, and leave a reproducible diagnosis.
The server takes longer than reasonable to return the HTML, or the slowness changes depending on the page and the active plugin.
3. Hosting and infrastructure
What it solves: the base on which everything runs. PHP version, memory limits, page and object caching, CDN, WAF, database and backups.
When it steps in: there are 5xx errors, TTFB is unstable, the cache misses or the server falls short in spikes.
What you can ask of it: a configuration consistent with the stack, server metrics, caching that does not break the site and a rollback plan.
The slowness is intermittent, affects the whole site or coincides with traffic spikes. A plugin is not going to fix an undersized server.
4. Content and design
What it solves: the weight decided before coding. 4 MB images, unnecessary fonts, embedded videos, third-party widgets and sections that load things nobody sees.
When it steps in: the design is approved and performance is discovered at the end; or every new landing reintroduces the same problem.
What you can ask of it: image formats and sizes, limited fonts, loading criteria for videos and embeds, and a review of what the first viewport actually needs.
The page weighs several megabytes before any interaction and the design screenshots include resources that do not contribute to the user’s decision.
5. Business and analytics
What it solves: priority. It defines which page matters, which metric moves and how much each millisecond costs in conversion. It avoids optimizing the homepage while the checkout stays broken.
When it steps in: several things are slow and nobody knows where to start; or you want to justify the investment with data, not with a score.
What you can ask of it: an order of intervention, a baseline and a way to measure the impact after the change.
Everyone has a different theory about what is “slow” and nobody has defined which page, device or user is the priority.
04Which profile for which symptom
This table does not replace a diagnosis, but it prevents the first wrong call.
| Symptom | Profile that steps in first | First check |
|---|---|---|
| The HTML is slow to arrive | Backend / hosting | TTFB and query time |
| Content appears late | Frontend | LCP and blocking resources |
| The page jumps on load | Frontend / content | Image and font dimensions |
| Slow only on mobile | Frontend / content | Real weight and third parties on mobile |
| Slow at times | Hosting / backend | Spikes, errors and caching |
05What nobody can fix
There are limits worth stating before charging for an optimization:
- A plugin does not replace a diagnosis. Caching helps, but it does not fix a slow query or excess JavaScript.
- There is no universal “100/100”. Lighthouse changes with the device, the network and the version. The goal is the real user, not the score.
- You cannot optimize everything at once. Every decision has a cost: fewer effects, fewer fonts, fewer widgets, more editorial discipline.
- Speed does not compensate for a broken site. If the checkout fails, the problem is not LCP.
If someone promises a specific position in Google or an exact load time without measuring your case, they are selling a template, not a diagnosis.
If you want someone to measure, prioritize and execute with this criterion, the speed optimization and WPO service starts from a measurement and a closed scope. And if you first need to know what you have, the WordPress audit documents the state and the cost of the next phase.
06Frequently asked questions
Do I need to hire all five profiles?
No. Most projects need one or two depending on where the bottleneck is. The logical sequence is to measure, identify the origin and add the profile that applies.
Does a cache plugin fix speed?
It can improve TTFB and relieve the server, but it does not reduce the JavaScript that blocks the browser or fix a slow query. It is a layer, not the diagnosis.
How long does an optimization take?
It depends on the scope. A diagnosis separates what can be fixed in an afternoon from what requires touching the theme, plugins or infrastructure. Without measuring, any deadline is an empty promise.
Can I do it myself?
Some things, yes: images, fonts and obvious plugins. Others require touching production with backup, staging and rollback. If there is no safety net, the saving can cost more than the intervention.