How long does speed optimization take?

Two clocks run in speed work: the time to make the changes and the time before the evidence shows them. What sets each, the order of work, and when to look.

In this guide

Two clocks
The clock for the work
A typical order of work
The clock for the evidence
What "done" should mean
Why it is never finished
A simple calendar
Mistakes to avoid
Check your own page
Sources

Two clocks

People ask how long speed optimization takes and mean two different things: how long until the changes are made, and how long until they see the result. The first depends on the project. The second depends on how the measurements work, and a good plan accounts for both.

The clock for the work

No honest answer fits every site. These factors decide it:

Factor	Effect on the time
Size and variety	A site with five page types is quicker to fix than one with fifty. The number of templates matters more than the number of pages
Platform and theme	A clean, configurable platform leaves little to fight. A heavy theme or builder can take most of the time
Hosting	If the server must change, the move and the testing add steps
Third-party tools	Each script needs a decision from someone who knows why it is there
Images and video	A large library can be processed by tools, but needs checking
Testing needs	A store, a booking system or a member area needs more careful testing than a brochure site
Approvals and access	Waiting for logins, answers and sign-off is often the longest part
What you ask for	A targeted fix list is faster than a full rebuild. See optimize or redesign

As a rough guide from practice, not a measurement: the simplest fixes on a small site take hours to days. A typical business site takes days to a few weeks. A large store with many templates takes longer. Ask whoever quotes for a schedule that shows the steps, not only a total.

A typical order of work

Baseline and diagnosis. Measure the key pages, lab and field, and write down the numbers. See how to read a speed report.
Safe, large fixes. Images, caching, fonts and obvious waste. They give the biggest gains for the least risk. See what to fix first.
Decisions about scripts, plugins and tags. These need people from the business, so they often take longest.
Template-level changes. Layout shifts, slow sections, the main image on each page type.
Testing and rollout. Each change is tested, ideally on a copy first. See how to test speed changes safely.
Watching. Check lab numbers at once, and field numbers over the following weeks.
A routine. Budgets, monitoring and a review on a calendar. See automated testing and budgets.

The clock for the evidence

When a change shows up depends on what measures it:

Where you look	When it shows a change
A lab test (Lighthouse, PageSpeed Insights lab section)	Straight away, on the next run. Run it several times and compare medians, because scores vary. See why scores change
Your own server cache	After the cache is cleared or the page is rebuilt
A visitor's browser cache	When the cached copy's lifetime runs out. A file cached for a year stays until its name changes. See HTTP caching headers
A DNS change	Over the record's time to live, since caches around the world keep the old answer until then. See DNS performance
A CDN	After its cache is purged or the files expire
Field data (the Chrome UX Report, PageSpeed Insights' real-visitor section)	Slowly. The data covers a rolling 28-day window, so a fix shows in full only after the old data has rolled off. See the Chrome UX Report
Search Console's Core Web Vitals report	Also over 28 days, with a longer history behind it
Business numbers such as sales or sign-ups	Only when there is enough traffic to see a real difference. See speed and conversion rate

The practical lesson: if the lab shows a gain on day one and the field data has not moved on day ten, that is normal. Do not undo a fix because the report lags. Your own real user monitoring, if you have it, shows effects sooner. See real user monitoring.

What "done" should mean

Agree on it before the work starts, in numbers:

Targets for named metrics on named pages, such as Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
How they will be measured: which tool, how many runs, on which device profile.
When they will be checked: at the end of the work, and again after the 28-day window.
What is out of scope.

A target met in the lab and then checked in field data a month later is a much stronger finish than a screenshot of a score.

Why it is never finished

A fast site slides back as images, tags, plugins and software change. See why websites get slower over time. Plan for a light routine after the project: a monthly look at the numbers, a quarterly review of scripts and plugins, and a rule that changes are tested before they go live.

A simple calendar

When	What to do
Before	Write down the baseline numbers and the pages
The day it goes live	Run the lab tests again. Check forms, checkout and tracking
After a week	Look at errors, orders and support messages. Check the lab again
After a month	Compare field data with the baseline. Decide what to fix next
Every quarter	Review scripts, plugins and page weight

Mistakes to avoid

Judging the result on the first day, with field data that covers 28.
Expecting a single number of weeks from every quote.
Starting without a baseline.
No named person for approvals, which stalls the work.
Calling it finished with no routine afterwards.
Reverting a fix because the field report has not moved yet.

Check your own page

Run the free audit today and save the report, with the date. Put a reminder in your calendar for 28 days later and run it again on the same page.

Sources

Chrome UX Report methodology: the rolling 28-day window of field data.
Score variability in the Lighthouse documentation: why a single lab run is not enough.
Relating site speed and business metrics on web.dev: why a test needs enough traffic.