How Much to Charge for Website Speed Optimization

You can’t quote website speed work with guesswork. Clients hear “make it faster,” but they’re really asking for a mix of audits, fixes, and proof.

This guide helps you price website speed optimization with deliverables, scope boundaries, and ready-to-use packages you can sell confidently.

Start with deliverables: what “speed optimization” really includes

Before you talk numbers, define what the client gets. Speed projects fail when deliverables are vague, like “optimize images” without the “how we’ll verify it worked” part.

Use this deliverables flow (it maps to how most speed work is actually done):

1. Audit + baseline metrics
   • Run performance tests and record results.
   • Identify likely bottlenecks.
2. Prioritized fix list
   • Explain what you’ll change first and why.
   • Group items by impact and risk (low-risk fixes vs deeper refactors).
3. Implementation
   • Apply fixes in the agreed scope.
   • Track what changed and where.
4. Re-test (verification)
   • Re-run the same tests so results are comparable.
5. Report + handoff
   • Summarize changes.
   • Provide ongoing recommendations and maintenance notes.

The pricing “secret” is simple: you’re not charging for speed. You’re charging for a defined process and measurable outcomes.

Typical pricing by effort level (quick wins vs deeper work)

Pricing depends mostly on two things:

• How much you can change without touching core code.
• How much iteration and rework you expect.

Here are three common effort levels you can package and price. (You can adjust your rate based on your market and how specialized you are.)

1) Quick wins (low access, light changes)

Best for: marketing pages, landing pages, smaller sites, and clients who can’t give deep code access right away.

What’s usually included:

• Image optimization (resize/compress, modern formats where applicable)
• Basic caching and compression checks
• Removing obvious heavy scripts
• Asset cleanup (where it’s safe)
• Simple template/config changes

Typical scope shape: 4–8 hours to assess + 4–12 hours to implement + 1–2 cycles of re-testing.

How to price: charge a fixed package if the client provides enough access and the site is not wildly complex.

2) Mid-level optimization (mix of fixes + some code or architecture work)

Best for: sites with performance issues that aren’t purely “asset” problems.

What’s usually included:

• Improving Core Web Vitals (Core Web Vitals are Google’s user-focused performance measures)
• Script loading strategy (e.g., deferring non-critical scripts)
• Template improvements and smarter asset bundling
• Staged refactors (example: performance improvements in key templates before the rest)

Typical scope shape: 12–30 hours total, often with 2–3 re-test rounds depending on how quickly changes move through staging/production.

How to price: fixed project plus an “if needed” add-on for deeper investigation.

3) Deep optimization (refactors, CMS changes, or performance engineering)

Best for: slow sites where the real bottlenecks are structural.

What’s usually included:

• Larger refactors (page rendering changes, component-level optimization)
• CMS changes (e.g., theme/plugin adjustments that affect output)
• Custom performance work that needs careful testing
• Ongoing monitoring setup (in more advanced packages)

Typical scope shape: 30–60+ hours, and sometimes more if the site is complex or the client’s release process is slow.

How to price: hourly or milestone-based (audit → plan → implementation → verification). Milestones protect you when “simple speed work” turns into a bigger engineering effort.

Use the right metrics—but don’t let them drive scope chaos

Most website speed optimization work ties back to common tools and metrics. You want to use them consistently so re-test comparisons mean something.

Metrics you’ll typically see

• Core Web Vitals: focuses on user experience—things like load stability and responsiveness.
• Lighthouse: a widely used performance audit report.
• Field vs lab data: lab tests are controlled; field data reflects real users.

How these metrics affect pricing:

• If the fix list is mostly low-risk assets/config changes, the work is easier to estimate.
• If the Lighthouse/field issues point to rendering strategy or CMS/plugin behavior, expect more engineering time.

Scope control tip: define “what counts as improved”

Clients often expect a specific score, but speed outcomes can be noisy (device, network, third-party scripts, and traffic patterns).

Instead of promising a single number, define acceptance in plain terms:

• “Re-test using the same tool and configuration.”
• “Show improvement in the targeted metrics for the specified page templates.”
• “Prioritize improvements to the pages we listed in the scope.”

This keeps you from arguing about the wrong thing at the end.

Scoping around access and what changes you’re willing to make

A speed project can be small or huge based on what you’re allowed to change. Quote accordingly.

Ask upfront what you have access to

• Staging environment access (or only production?)
• CMS editor access vs theme/code repository access
• Control over tags and third-party scripts
• Whether the client will remove/replace heavy plugins

Split work into buckets: “content tweaks” vs “code/refactors”

Use this boundary in your proposal. It protects both sides.

Bucket A: content/asset changes

• Images, fonts, media sizing
• Script cleanup (where changes don’t require engineering)
• Basic caching/CDN settings

Bucket B: code and refactors

• Template rendering changes
• Component-level optimization
• Build pipeline changes (bundling/minification strategy)
• CMS/theme/plugin output changes

If the site needs Bucket B work, you’ll often need either:

• more hours, or
• milestones, or
• a discovery step that ends with a more accurate plan.

Example: how you can phrase it in a contract

• “We will optimize within the agreed scope (Bucket A).”
• “Bucket B changes require approval after we deliver the prioritized plan.”

This reduces scope creep. It also reduces the chance you do engineering you can’t verify or deploy.

Speed optimization packages you can sell (with add-ons)

Below are example packages you can adapt. The goal is not the exact price. The goal is that the client can see what they’re paying for.

Package 1: Speed Snapshot (Audit + Quick Wins Plan)

Deliverables

• Baseline audit (Lighthouse/Core Web Vitals-style outputs)
• Bottleneck summary
• Prioritized fix list for the selected pages
• Implementation estimate + effort notes

Included

• 1–10 low-risk fixes (asset/config level)

Great when the client is unsure if speed work is worth it.

Package 2: Performance Boost Sprint (Quick Wins + Implementation)

Deliverables

• Audit + baseline
• Implementation of quick wins
• Re-test + results report

Included

• 10–25 fixes depending on complexity
• 2 re-test rounds

Optional add-on

• Deeper investigation for one main bottleneck (paid discovery)

Package 3: Core Vitals Improvement Project (Mid-level optimization)

Deliverables

• Audit + prioritized plan
• Implementation (bucket A + selected bucket B)
• Re-test + verification report
• Hand-off notes for ongoing monitoring

Included

• 2–3 milestones depending on release needs

Optional add-ons

• Additional page templates
• Third-party script optimization support
• CMS/plugin optimization (if relevant)

Package 4: Performance Engineering (Deep refactors)

Deliverables

• Audit + root-cause analysis
• Refactor plan with risk notes
• Implementation across templates or key layouts
• Re-test + regression checks

Included

• Multiple iterations and staged rollout

Optional add-ons

• Ongoing monitoring setup and monthly tune-ups
• Performance regression testing for future releases

A “process pricing” mindset (and why it helps you get paid on time)

Clients pay faster when they understand the rhythm:

• audit → plan → build → re-test → report.

If you find you’re constantly chasing approvals, missing files, or forgetting what changed where, your project becomes harder than it should be.

Tools like Jolix can help you centralize proposals, contracts, deliverables (files), and client communication so speed work doesn’t turn into messy back-and-forth. If you want a quick gut-check on your freelance systems, take a look at the Freelance Business Check.

How to choose your final number

When you’re ready to set a quote, start with your time estimate, then adjust with scope risk.

Use this quick checklist:

• How many page templates are in scope (not just URLs)?
• Do you expect 1 re-test or 3+?
• Is third-party code part of the bottleneck?
• Do you have staging access and fast deployment?
• Does the work cross into refactor territory?

Then pick a pricing model:

• Fixed price for quick wins and clear deliverables.
• Milestones for anything likely to shift.
• Hourly when access, root cause, or client release process is uncertain.

---

Related reading: How Much to Charge for Website Maintenance · Freelance Web Developer Pricing: A Playbook

Closing advice: quote the plan, not the promise

“Make it faster” is too vague to price. Your client is buying your plan, your judgment, your implementation time, and your verification.

If you want, reply with: your target platform (WordPress, Webflow, Shopify, custom), number of page templates, and what access you’ll get. I can help you pick a package structure and the right scope boundaries for your situation.