WordPress speed optimization cost: what the job is, what it should include and what moves the price

What WordPress speed optimization costs depends on what is making the site slow. Some causes are settings: a page cache, images at the right size, a current PHP version. Some need development: a heavy theme or page builder, slow database queries, too many scripts. One is not a speed job at all: hosting that cannot serve the site. A quote given before anyone has measured your pages is a guess.

This page gives no going rate, names no company and ranks nobody. It sets out what the job is, how it is sold, what a complete one includes, and how to tell afterward whether you got what you paid for.

What the job is, cause by cause

"Speed optimization" is a label for removing whatever is slow. The cause decides the size of the job.

Quotes run from the price of a plugin to the price of a rebuild because they are quotes for different rows. Measuring shows which rows are yours. How to speed up a slow WordPress site takes the causes in the order that pays off.

How the work is sold

A plugin's options need checking one at a time. On a store, WooCommerce's documentation says to keep the Cart, My Account and Checkout pages out of the page cache, because they show information specific to one customer. WordPress caching plugins compared covers what to check before adding one.

What a real optimization includes

Six parts. Hold each quote against the list.

• Measurements before, on pages you name. The quote states the pages, the tool, mobile or desktop, and the number of runs. Name one page of each kind that matters: the home page, a landing page, a post, and for a store a product page, the cart and the checkout.
• The causes, in writing. Someone reads the test reports against the site and says which cause each page has, before any change is made.
• The changes. They are made one at a time where possible, so that each can be measured and undone, and on a staging copy first when the site has one.
• Measurements after, on the same pages, in the same way. That means the same tool, the same device and the same number of runs.
• A written list of what was changed and how to undo it. Every plugin installed or removed, every setting switched on, every file edited, and any license bought and in whose name. Without it, the next fault on the site cannot be traced to its change.
• What was found and not fixed, and why. Hosting that sets a floor, a script you chose to keep, a page builder that would have to be replaced. This part tells you what the next spend would be.

The two kinds of measurement, and what each can prove

PageSpeed Insights, Google's testing tool at pagespeed.web.dev, reports two kinds of figures for a page.

That has three consequences for a quote.

Mobile or desktop. The two tests give different figures for the same page. For its mobile run, Lighthouse, the tool behind the lab test, by default slows the processor to a quarter of its speed and holds the connection to about 1.6 megabits a second. A page that feels quick on your own phone can still test slow.

The number of runs. Lighthouse's documentation says its scores change from run to run even when nothing on the page has changed, and that the median of five runs is twice as stable as one run. "Before" and "after" should each be the middle result of five.

Which figures. The score out of 100 is a summary of lab figures. What Google assesses is three field figures, each at the 75th percentile of visits: main content on screen within 2.5 seconds (LCP), a reaction to a click or tap within 200 milliseconds (INP), and a layout shift score of 0.1 or less (CLS). Ask for these as well as the score. WordPress Core Web Vitals explains each one.

Checking the work yourself

• Put the same pages through PageSpeed Insights yourself, five times each, and compare the middle results with the "before" figures.
• Hold the list of changes against the Plugins screen. Nothing should be there that the list does not mention.
• Use the site as a customer does: the menu, a form, and on a store the cart and the checkout.
• Four weeks later, read the field data for the same pages, if they have any.

What moves the price

What nobody can honestly promise

Three promises are common in quotes. Google's own documentation rules out each one.

A particular score. Lighthouse's documentation says scores change between runs with no change to the page, because networks, servers and devices vary. It also says a "perfect" score of 100 is extremely challenging to achieve and not expected, and that going from 99 to 100 takes about as much improvement as going from 90 to 94.

A ranking. Google says its ranking systems use Core Web Vitals. It also says that good results in a report do not guarantee a place at the top, and that it tries to show the most relevant content even when the page experience is below par. Its advice on hiring help with search is blunter: "No one can guarantee a #1 ranking on Google."

A result on real visitors' phones within days. Field data is a rolling average of the previous 28 days, so a change made today is not fully reflected for four weeks. "Start Tracking" in Search Console's Core Web Vitals report opens a 28-day monitoring session for the same reason. The result also depends on your visitors' own devices and connections, which no seller controls.

What can be promised is narrower and can be checked: named changes, and figures measured before and after on agreed pages by an agreed method. WP Ministry's own service is held to the same line. It reports what was measured and does not promise a number.

Why a "100 score guarantee" is a warning sign

The score is one simulated load of one page, and it changes from run to run. PageSpeed Insights' documentation says that good lab data does not necessarily mean real-user experiences will also be good.

A seller held to a number has a reason to work on the number: the one page that is tested, on the test's device, on the day of the test. Google itself says that trying to get a perfect score just for SEO reasons may not be the best use of your time. A guarantee worth having names the pages, the method, and what you get back if the figures do not move.

Questions to put to anyone quoting

Send these as they are. The written answers are the scope.

1. Which pages will you measure, and do I choose them?
2. Which tool do you use, on mobile or desktop, and how many runs is each figure taken from?
3. Are the figures lab data, field data or both? If my pages have no field data, what do you report?
4. What happens if the cause turns out to be the hosting? Do you stop, and what do I pay for the work done so far?
5. If a plugin or the theme has to be replaced, is that in the price? Who pays for a license, and in whose name is it held?
6. Will anything a visitor sees change: fonts, sliders, animations, chat, the order in which things appear?
7. Do you work on a staging copy first? If I have none, who makes one?
8. What do I get in writing: the figures before and after, the list of changes, how to undo each one, and what was found and left?

Doing it yourself first

The settings rows of the first table are within reach of an owner who is comfortable in the dashboard. Take a backup before you start.

The cost is your hours. No published figure can tell you how many, so time the first change and count the hours at what they are worth to the business. The risk is a setting that breaks a form or the checkout without anyone noticing, so use the site as a customer does after every change.

When to spend the money on hosting or a rebuild instead

Hosting. Google's guidance on server response time says hosting is the first thing to consider. Shared hosting is generally slower, it says, which is fine for a small site of mostly static pages. The choice becomes critical for a site with many users, personalization and database work. The signs that the server is the limit:

• The server is slow to begin its answer on pages no cache serves, such as the cart, the checkout and the dashboard. Google counts 0.8 seconds or less as good and more than 1.8 seconds as poor. Its guidance warns that a cache can mask a slow backend, so test a page that is not cached. How to reduce server response time shows how.
• The site returns errors when it is busy. WordPress hosting problems shows how to tell whether a fault is the host's or the site's.

WordPress's documentation says that paying more for a higher level of service at a hosting provider can be very effective. Ask the host what the next plan up would change before you pay anyone to tune the site on the current one.

A rebuild. The sign is the same cause on every template: each page's report points at the theme's or the builder's own files. A rebuild is the largest spend of the three, so it comes last, after the settings are done and the hosting is ruled out, with measurements that show what is left.

How to work out your own figure

What a slow page costs is in your own numbers and nowhere else.

This page gives no percentage for how many visitors leave a slow page. A figure of that kind describes other sites and other visitors. Your analytics, before and after, describe yours. Set them beside the quotes you have and the pricing page.