By Mehdi HassanWhat does a website speed optimization service include?
A website speed optimization service includes four parts: an audit of real-user performance data, fixes for whatever is failing, a cleanup of third-party scripts, and verification that the fixes worked for real visitors. Anything less is either a report or a guess.
The trap in this market is the Lighthouse score. It's easy to sell a jump from orange to green in a lab test, and it often has little to do with whether your site passes Core Web Vitals for visitors or converts better. If you're not yet sure what the metrics mean, read Core Web Vitals explained for marketers and founders first, then use this guide to scope and price the work.
- Field-data audit: Search Console and PageSpeed Insights field data, broken down by page group, metric and device.
- Diagnosis: lab profiling of the failing pages to find the cause behind each metric.
- Implementation: the actual fixes, not just recommendations.
- Script and tag cleanup: removing or deferring third-party code, agreed with marketing.
- Guardrails: component defaults and a budget so the site doesn't slow down again.
- Verification: a field-data check after the rolling 28-day window.
How much does website speed optimization cost?
Website speed optimization costs vary widely, because the same symptom can need a one-hour fix or a rebuild. Quotes we see are usually structured in tiers by scope rather than by page count, and prices differ a lot by provider and region, so use the tiers below to compare quotes like for like.
Scope tier | What's included | Relative cost | Good fit when |
|---|---|---|---|
Automated or one-off audit | Report from lab tools with a list of issues | Lowest | You have developers ready to implement |
Audit plus quick fixes | Field-data audit, image, font and script fixes | Low to moderate | Failures are in assets and tags |
Performance sprint | Audit, implementation across templates, script cleanup, verification | Moderate | Several page types fail one or two metrics |
Rebuild of key templates | Hero, navigation and section components rebuilt for performance | Higher | Problems live in the components themselves |
Architecture change | Moving from client rendering to static or server rendering, or changing platform | Highest | The site renders content in the browser or the platform is the limit |
Ongoing performance care | Monthly monitoring, tag reviews and regression fixes | Recurring | Marketing adds pages and tags every month |
- Designify trial week: one week of design and development, which can be spent on a scoped performance fix
- $1,000
- Designify monthly retainer: ongoing design and development, including performance work
- $6,000/mo
- Free intro call to look at your field data together
- 30 min
What drives the cost of page speed optimization?
The biggest cost driver is where the problem lives. Fixes to assets and configuration are cheap, fixes to shared components cost more, and fixes to how the site renders cost the most.
- Which metric fails. LCP and CLS fixes are often contained in the hero and images. INP fixes usually touch scripts and JavaScript across the site.
- Number of templates, not pages. Fifty blog posts share one template, so they're one fix.
- Platform access. Builders limit what you can change; coded sites allow everything but need developer time.
- Third-party dependencies. Removing a tag is easy technically but needs someone to agree it's no longer needed.
- Design constraints. Keeping heavy motion or video while passing vitals takes more engineering than removing it.
- Verification and guardrails. Monitoring and component defaults add time but stop the site sliding back.
How should a performance sprint be scoped?
Scope a performance sprint with field-data targets, a named list of page groups and an agreed list of what may be removed. That turns a vague brief like make it faster into work you can check.
Baseline the field data
Record LCP, INP and CLS at the 75th percentile for each important page group, on mobile and desktop, from Search Console and PageSpeed Insights.
Set targets per group
For example, pass all three vitals on the homepage, pricing and top landing pages. Leave low-traffic pages for later.
Agree what can change
List tags that may be removed or delayed, and design elements that may be simplified, before work starts.
Fix in order of impact
Hero and server response for LCP, scripts and hydration for INP, reserved space and fonts for CLS. Our guides to improving LCP and fixing INP cover the methods.
Add guardrails
Build defaults into components and set a performance budget so new pages inherit the fixes.
Verify after the window
Check field data again once the rolling 28-day window has passed, and report against the baseline.
Hypothetical example: scoping a sprint for a SaaS marketing site
For example, suppose a SaaS site fails INP on mobile across all pages and LCP on the homepage only. The scope would name three page groups: homepage, pricing and blog. The targets: pass INP on all three and LCP on the homepage, in field data.
The agreed changes: remove two unused tracking pixels, load the chat widget on click, replace the hero background video with a poster on mobile, and move a pricing toggle into a small client component. Out of scope: platform changes and the docs subdomain. Verification happens a month after the last change ships.
What should you ask a speed optimization provider?
Ask questions that reveal whether the provider works from field data and implements fixes, or sells reports and lab scores. The answers sort providers quickly.
- Which data will you use to set targets? You want field data, not only Lighthouse.
- Do you implement, or only recommend? Reports without implementation rarely get acted on.
- How do you handle third-party scripts? Look for a third-party scripts audit that includes marketing in the decisions.
- What happens if a metric still fails after the window? A good answer includes a follow-up.
- Will you change the design? Know in advance if they plan to remove motion or video.
- What stops it from regressing? Component defaults, budgets and monitoring.
Is a one-off speed project or ongoing care better?
A one-off project suits a site that rarely changes; ongoing care suits a site where marketing ships new pages, campaigns and tags every month. Most startup sites are the second kind, which is why speed often slips back after a one-off fix.
Ongoing care doesn't have to be a separate contract. It can be part of website maintenance, where every new tag and section is checked before release. Hosting matters too, since slow server responses hurt LCP on every page; our guide to website hosting cost compares current options. And if the site was built from a heavy template, compare the cost of fixing it with rebuilding, using template vs custom website.
