Page Speed Optimization Is a Funeral Director. The Racket of Making the Dying Walk Faster.

There is a particular kind of consultant who arrives at the funeral wearing a stethoscope. He does not save the patient. He does not even pretend the patient can be saved. He simply makes the corpse look presentable enough that the family keeps paying for the open casket. In the WordPress economy, this consultant is the page speed optimization specialist. His job is not to build a fast website. His job is to make a slow website appear slightly less embarrassing on a Google report card while the client continues to write cheques.

The industry has been thriving for a decade. It has conferences. It has certifications. It has agencies that charge five thousand dollars to install WP Rocket, swap in a CDN, and disable the emoji script. It has freelancers who will sell you a 'Core Web Vitals remediation package' that consists of a single caching plugin and a polite email explaining that your page builder is the real problem. The economics are extraordinary because the underlying problem is permanent. WordPress is slow by design, and the design has not changed in twenty years.

The diagnosis. Why the patient was always terminal.

WordPress was built in 2003 to publish blog posts. That is not a criticism. It is a description of the architecture. A post is a row in a posts table. A category is a row in a terms table. A thumbnail is a row in a postmeta table. A relationship is another row in a term_relationships table. The entire platform is a relational database pretending to be an application, and every page load is a series of joins across tables that were never designed for the workloads modern sites impose on them.

“You are not optimizing a website. You are teaching a horse to drive a motorway while charging consultancy fees for the saddle.”

Then came the page builders. Elementor, Divi, WPBakery, Beaver Builder, and the dozens of smaller entrants that learned to mimic the same model. Each one ships with a CSS file the size of a novella and a JavaScript bundle that treats the browser like a rented warehouse. The builder has to be available in the editor, so it loads in the frontend. The theme is built inside the builder, so the theme loads inside the builder. The plugins are built to extend the builder, so they add their own CSS and JavaScript, which then have to be enqueued, which then have to be minified, which then have to be deferred, which then have to be cached, because the alternative is admitting the stack is fundamentally unfit for the purpose.

The orange-to-green economy. How a colour scale became a mortgage.

Google's PageSpeed Insights does not measure whether a site is fast. It measures whether a site passes a set of synthetic thresholds that correlate, imperfectly, with user experience. A score of fifty is orange. A score of ninety is green. The difference between those two numbers has launched entire agencies.

The playbook is well understood. Run the audit. Present the screenshot of the orange bar to the client, preferably with a red Largest Contentful Paint number. Explain that this is costing them rankings, conversions, and self-esteem. Sell a package. Install a caching plugin. Add lazy loading. Minify CSS and JavaScript. Defer non-critical scripts. Optimize images. Maybe throw in a CDN. Run the audit again. The bar is now green. The invoice is paid. Everyone congratulates each other on a problem solved.

• →Caching plugin: hides the fact that the database query is slow by remembering the result.
• →Minification: compresses the bloated CSS that the page builder emitted for no good reason.
• →Lazy loading: delays the loading of images that should not have been that large anyway.
• →CDN: moves the static assets closer to the user because the server cannot generate them quickly enough.
• →Defer JavaScript: waits to execute the framework the site does not need until after the paint.
• →Database optimization: deletes the revision history the client never asked to keep.

Each of these is a mitigation for a decision made somewhere upstream. The page builder decided to ship forty stylesheets. The theme decided to load six web fonts. The plugin decided to enqueue jQuery on every page for a widget that appears in the footer. The optimization specialist does not fix any of those decisions. He is paid to wallpaper over them. He is the second most profitable person in the supply chain, after the person who sold the original bloat.

The mortician's toolkit. What the invoice actually buys.

A typical speed optimization audit is a performance in three acts. First, the consultant uses the tools of authority: GTmetrix, WebPageTest, Chrome DevTools, Lighthouse. The numbers are presented with the gravity of an oncologist reading a scan. Second, the consultant proposes a set of interventions, each with a price, each justified by a plausible-sounding technical claim. Third, the consultant applies the interventions and produces a new report showing improvement. The client is relieved. The consultant is paid. The site remains slow for real users, because the synthetic score was never the real problem.

“A green Lighthouse score on a WordPress site is like a participation trophy at a funeral. It does not mean the body is alive. It means you are all very polite.”

The most honest speed optimization consultants will tell you, usually in private, that the real fix is to rebuild the site on a modern stack. They will say this, then they will sell the client the caching plugin anyway, because the client cannot afford the rebuild, and because the consultant has a mortgage. Nobody is evil here. The market simply rewards the appearance of health over the reality of health, and the consultant is responding to incentives.

The alternative. Platforms that do not need a mortician.

Compare this with the modern alternatives. A site built on Astro, Next.js, SvelteKit, or any of the static-first edge frameworks begins with a different assumption: the HTML is generated once, shipped from a server geographically close to the user, and does not require a database roundtrip for every visitor. There is no page builder emitting CSS. There is no plugin chain loading JavaScript. There is no session table to query. The site is fast because the architecture is fast, not because someone is paid to apologize for it.

AI-native platforms go further. They generate the site from a prompt, compile it, and deploy it to a global edge network. The content may be stored in a flat file, a managed headless CMS, or a database the platform hides from the developer. What the user sees is a pre-rendered HTML document with minimal JavaScript, served from the closest possible location, without the client needing to know what a database index is. The speed optimization specialist has nothing to do, because there is no speed problem to optimize.

• →No caching plugin because the page is already static.
• →No minification because the bundle is already small.
• →No database query optimization because there is no database query on the page load.
• →No CDN configuration because the edge network is included.
• →No JavaScript deferral because the JavaScript that remains is already deferred or absent.

This is not marketing. It is geometry. If a page is a static file and a server is a file system, the page loads quickly. If a page is a query to a database, a render through a PHP template engine, a filter through twenty plugin hooks, and a rehydration of a JavaScript framework, the page needs help. The question is not whether the second architecture can be optimized. It is whether the optimization is a sensible use of money compared to replacing the architecture.

The agency math. Why this will keep happening anyway.

Agencies are not stupid. They know the site is slow because of the stack. They also know that the client is not going to pay for a rebuild, because the client has just spent eighteen months and twenty thousand dollars getting the current site built. So the agency sells the next best thing: the appearance of improvement. The speed optimization package becomes a way to extract a few more billable hours from a project that is otherwise in maintenance mode. The client gets a green bar. The agency gets a retainer. The underlying stack continues to rot.

There is also a sunk-cost alliance between the client and the consultant. The client has already paid for the site, the hosting, the plugin stack, and the previous optimization package. Admitting that the entire foundation is wrong means admitting that all of that money was wasted. Selling another optimization package is emotionally easier than admitting the previous investment was a mistake. The funeral director is popular because the family does not want to hear that the patient died years ago.

“The most expensive sentence in web development is 'We've already invested so much in WordPress.'”

The punchline. You are racing a hearse.

The speed optimization industry is not a fraud in the criminal sense. Most practitioners do what they promise. They really do improve the synthetic score. They really do install the plugins. They really do write the reports. The fraud is structural. It is the pretense that the problem is on the surface when it is in the foundation. It is the pretense that the right way to make a horse fast is to keep feeding it oats while hiring an aerodynamics consultant to redesign the saddle.

If you are a developer still inside this economy, ask yourself what you are actually being paid for. Are you being paid to build fast sites? Or are you being paid to make slow sites pass a test that was designed to shame them into being replaced? If it is the second, your job is temporary. The moment the client realizes that a different stack makes the problem vanish, your optimization service becomes a line item they cannot justify. And the moment AI-native platforms make that realization obvious, the line item disappears entirely.

The page speed optimization specialist is a funeral director in a growth industry. The corpse is WordPress. The embalming fluid is caching. The open casket is the green Lighthouse score. The mourners are paying clients who have not yet noticed that the funeral is for their own business model. The dead do not walk faster because you paint them green. They walk faster because you stop pretending the dead should walk at all.

“Stop charging to make the hearse faster. Start charging to put the hearse in a museum where it belongs.”

The next decade belongs to builders that do not need an optimization specialist. They do not need one because they were not built to be slow. They were not built on a 2003 blogging architecture extended beyond recognition by page builders and plugin stacks. They were built for the speed that the web expects now, which means the speed is already there, baked into the foundation, not applied afterward like makeup on a corpse. The funeral directors will fight this. They will call the new platforms limited, toy-like, unsuitable for real work. They will be right in some cases and wrong in most. But they are not fighting for quality. They are fighting for the continued relevance of an embalming table. The body is already cold. The autopsy is over. The only question left is how long the family wants to keep paying for the view.