How to Measure TTFB Before and After a Website Migration

Time to First Byte (TTFB) is one of the most misunderstood metrics in migrations.

It is not the whole performance story.

But it is the cleanest signal of backend response change.

If you are replatforming, rebuilding, switching CDNs, or migrating infrastructure, you should measure TTFB before and after launch.

Here is how to do it correctly.

What TTFB Actually Measures

TTFB is the time between:

Client request
First byte received from the server

It includes:

DNS lookup
TCP/TLS negotiation
Server processing time
Initial response generation

It does not include:

Full document download
Script execution
Image loading
Layout rendering

TTFB answers one question:

Did backend responsiveness change?

Why TTFB Matters During Migrations

Platform migrations frequently change:

Hosting environment
Application stack
CDN provider
Caching behavior
Server-side rendering strategy

You may improve:

Database performance
Cache hit rate
Edge distribution

Or accidentally degrade:

Cache headers
Origin routing
App-level latency

Without side-by-side measurement, you cannot know which occurred.

Step 1: Establish a Pre-Migration Baseline

Before launching:

Export your legacy URL list.
Select a representative sample:
- Homepage
- Top category pages
- High-traffic product pages
- Blog template (if applicable)

For example:

/natural-beard-oils/clove-citrus-beard-oil
/beard-oil
/blog/That-Uncomfortable-Itchy-Beard-Feeling

Measure:

Mean TTFB
Median TTFB
P75 TTFB

Single measurements are noise.
Use multiple runs and aggregate.

Step 2: Measure Under Consistent Conditions

TTFB is environment-sensitive.

To compare correctly:

Use the same geographic region
Use the same concurrency level
Avoid local dev environments
Avoid browser devtools one-off tests

Ideally:

Headless Chrome
Controlled network profile
Identical request headers

If methodology changes between tests, comparison loses integrity.

Step 3: Measure Post-Migration

After staging deployment (and again after DNS cutover):

Repeat the same test set.

You are looking for:

Mean delta
Distribution shift
Outliers

Example interpretation:

Mean: 327ms → 139ms (improvement)
Median: stable
P75: sharp improvement

This suggests backend performance improvement.

If instead you see:

180ms → 450ms
Large P75 spikes

You have introduced latency.

Step 4: Separate Backend From Frontend

TTFB can improve while total load time worsens.

Common migration pattern:

Backend faster
Theme heavier
More JS
More CSS

This is not contradictory.

Measure both:

TTFB (backend)
Total load time (frontend + assets)

If you only measure one, you miss the story.

For full domain comparison methodology: How to compare your old and new website before launch

Step 5: Watch for CDN and Cache Artifacts

Common pitfalls:

Testing warm cache only
Testing cold cache only
CDN propagation delay
DNS TTL inconsistencies
Origin misconfiguration

Best practice:

Run multiple test batches
Note first-run vs repeat-run differences
Confirm consistent caching headers

Step 6: Evaluate in Context of Core Web Vitals

TTFB affects:

LCP potential
Overall responsiveness

But TTFB alone does not define user experience.

After measuring TTFB, evaluate:

Especially during theme rebuilds or platform migrations.

Why Manual Testing Is Not Enough

Opening DevTools and reading a single number is insufficient.

Migration validation requires:

Structured URL corpus
Aggregated metrics
Comparable methodology
Side-by-side domain comparison
Repeatable output

Without that, you are observing anecdotes.

Practical Migration Standard

Before migration:

Record TTFB baseline.
Document distribution.

After migration:

Compare aggregate results.
Identify regressions.
Re-test after fixes.

TTFB should not be guessed.

It should be measured, compared, and documented.

During migrations, performance is not a feeling.

It is a delta.