Questions to ask before you hire a speed optimizer

How to use this list

Put the questions to every candidate in the same order, and note the answers. Ask for them in writing, since a written scope is also what you can check the work against. The answers do not need to be technical. You are listening for four things:

• Specific. Does the answer name pages, numbers, tools and steps?
• Evidence-based. Does it say how the result will be measured?
• Honest about limits. Does it say what could go wrong, or what they cannot change?
• Respectful of your site. Does it protect forms, checkout, tracking and search visibility?

Measuring

• 1. Which pages will you measure, and which numbers? A good answer names your most important pages (home, a service or product page, a form or checkout) and the numbers: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, plus page weight and server response time. See what to fix first.
• 2. Do you use lab data, field data, or both? A good answer uses both. Lab tools such as Lighthouse are for diagnosing and testing changes, and field data shows what real visitors get. See lab and field data.
• 3. Will you guarantee a score? A good answer is no. Lighthouse's own documentation says scores change between runs without any code change, so a promise of a particular number cannot be kept honestly. A good optimizer promises targets for named metrics on named pages, measured as medians of several runs. See why scores change.
• 4. How long until real visitors see the difference in the data? A good answer says weeks. The Chrome UX Report covers a rolling 28-day window, so field data catches up slowly. They should also say what they will watch in the meantime.
• 5. Will you test on real phones, not only in a tool? A good answer says yes, and names the devices or types of connection. See testing on real phones.

Doing the work

• 6. What exactly will you change, and what will you leave alone? A good answer is a written scope: for example images, caching, fonts, scripts, hosting settings and plugin choices, and what is out of scope, such as the design or the content. Ask what they would need your approval for.
• 7. How will you protect the live site while you work? A good answer mentions a full backup, a staging copy where possible, one change at a time, a test after each change, and a way to undo it. The WordPress Handbook gives the same advice for upgrades: test compatibility first and use a staging environment if you have one. See how to test speed changes safely.
• 8. What will you check after each change? A good answer lists forms, search, login, checkout, tracking tags and the main page layouts, not only the speed numbers.
• 9. What will you do about third-party scripts, and who decides? A good answer says they will list every script, ask what each is for, and let you decide which to remove, delay or keep. See third-party scripts. A poor one removes tags without asking, or delays everything until the first click, which can leave payment buttons and forms dead.
• 10. How will you handle plugins, themes and page builders? A good answer is a review of which are needed, with the cost of each, before any are removed. See themes and plugins and page builders.
• 11. How will you handle images and video? A good answer covers sizes, formats, lazy loading below the first screen, and no lazy loading of the main image. See image optimization and video.
• 12. Will you change my hosting or CDN, and who owns those accounts? A good answer explains why a change would help, what it costs, and that the accounts stay in your name. See choosing hosting.
• 13. How will you protect my search visibility? A good answer mentions checking that nothing is blocked from search engines, that canonical links, redirects and language links still work, and that the site is still indexable afterwards. See robots.txt and noindex and redirects.

Afterwards

• 14. What will I receive at the end? A good answer is a before and after report with the same pages and the same method, a list of every change, and a note of anything left unfixed and why.
• 15. How will the gains last? A good answer mentions a page weight budget, monitoring, and a review on a schedule, because sites slide back. See why websites get slower and automated testing and budgets.
• 16. What could prevent this from working, and what do you need from me? A good answer is honest. It may name a theme that cannot be slimmed, a tracking tool you want to keep, a host that limits caching, or access and decisions they need from you.

Red flags

What a good proposal contains

• The pages and metrics to be measured, and how, before and after.
• A written scope and a list of what is excluded.
• How the site will be protected during the work.
• Who decides about marketing and tracking tags.
• What you will receive, and when.
• How the gains will be kept.
• The risks and unknowns, in plain words.

Check your own page

Run the free audit before you talk to anyone, and keep the report. It gives you the pages and numbers to ask about, and a baseline to compare with afterwards.

Sources

• Score variability in the Lighthouse documentation: why scores change without code changes.
• Chrome UX Report methodology: the rolling 28-day window of field data.
• PHP in the WordPress Advanced Administration Handbook: testing for compatibility and using a staging environment.