Case study Original Research

Timing 3,200 sites before and after their move to Kinsta

Buyers moving to Kinsta from 23+ hosts kept asking Sales one thing. Would their site load faster? I helped set the migrations team’s speed test, then analyzed the results in Google Sheets and published them, slower ones included. Several of Kinsta’s comparison pages still quote the numbers in 2026.

Read the study

Client: Kinsta
Role: Technical Writer / Data Analyst / Copywriter
Year: August 2022
Disciplines: Test design, Spreadsheet modelling, Speed measurement

Proof at a glance

Every migration timed, the slower ones published too

Every number here is one a reader can check against the August 2022 capture or the CSV below.

3,200+

sites tested before and after

migrating to Kinsta over 3 months, by Kinsta’s count
72

before-and-after comparisons

4 metrics, 2 views, across the 9 published tables
23

of the 72 slower after migrating

published with the rest, not held back
14

kinsta.com pages quoting it

in their 2025–2026 versions, recounted September 2026

If I move my site to Kinsta, how much faster will it load, and does that depend on where it’s coming from?

The question Sales kept being asked

The problem

Buyers asked how much faster, and nobody had measured

Sites got quicker after migrating to Kinsta and everyone knew it, but nothing had been recorded before or after. A dozen hand-picked wins would have said nothing about the next site on the list.

What Sales kept being asked

Sales needed numbers the migrations team hadn’t been recording

Customers moved their sites to Kinsta from all kinds of hosting in 2022, from cheap shared plans to self-managed cloud servers. The migrations team could see those sites get quicker after migrating.

They just hadn’t been recording it, before or after, so Sales had no number to give a buyer who asked.

I could have taken a dozen of the best migrations and shown their before-and-after screenshots. Hand-picked wins say nothing about the next site on the list.

So the team tested every migration the same way. Each site got one test just before its move and another right after it.

Over 3 months, that came to 3,200+ sites from more than 23 hosts. By my count in the published study, the team was finishing more than 2 migrations an hour on workdays.

Sites: 3,200+
Previous hosts: 23+
Collection: 3 months

One configuration

Setting one WebPageTest configuration for all the migrations

Several of us set the speed-testing criteria, and my part included suggesting WebPageTest’s free speed test and when to run it.

The migrations team then worked with us to collect the results as they moved each site.

Three rules kept the numbers comparable

Same settings: The settings matched on both sides of a migration. A test from another city or connection would have looked like a change of host.
Around live work: The tests had to fit around live migrations. As far as I remember the testing ran by hand, before and after each move. The team may have automated some of it.
A 10-site floor: A host needed 10 migrated sites to get its own table.

Who did what

My share of a test several teams ran

I suggested the tool and the timing, then analyzed the results and wrote the study. The migrations team collected every measurement.

Tested: Every migration, not a sample

Each party, and what they did

Sales: Brought the buyers’ question and used the results afterward
Migrations team: Moved the sites and collected the results
Speed testing team, me included: Set the test criteria
Me, before collection: Suggested WebPageTest and when to run it
Me, after collection: Analyzed the results and wrote the study
Me, after publishing: Suggested a speed section for Kinsta’s comparison pages
Marketing: Reused the findings on landing pages and social posts

The work

One test configuration, every migration, for 3 months

A free tool anyone could rerun, the same settings on both sides of each move, and a 10-site floor before a host got its own table.

How it was built

Turning thousands of test results into 9 host tables

Picking WebPageTest and the moment to run it

Once collection ended, I took the results into Google Sheets and built every grouping and formula myself (this was 2022, before AI could do any of it for me).

WebPageTest was my suggestion, and I gave my reasons in the published study.

It’s free, and it runs tests in Chrome and other browsers from locations around the world. Its API and its side-by-side comparison tool also suited a test we’d repeat thousands of times.

Timing mattered as much. One test ran just before a migration, and the after test ran as soon as it finished. The site had no time to change in between, so the difference between the 2 tests reflected the move to new hosting.

What the job needed

Choosing the test

A tool anyone could run for free, with repeat runs and a cached view

Building the tables

Sites grouped by previous host, then 4 metrics split by view

Writing it up

A method a reader could rerun, and what each metric measures
Grouping the results by previous host in Google Sheets

My first pass grouped the sites by the host they came from. Eight named hosts got their own table, and a ninth table pooled the niche hosts as Other.

Within a group, I split the numbers by metric and by view. That’s 4 metrics times 2 views, which makes 8 comparisons per host. Across the 9 tables, that comes to 72.

Those comparisons showed the old host’s time, Kinsta’s time, the difference in seconds, and the difference as a percentage.

Kinsta’s purple marked the faster cells. The slower ones stayed plain, so readers could count the losses themselves.
Writing the method so readers could rerun it

I laid out the method before any result, with screenshots of the WebPageTest settings so you can set up the same test.

For instance, I explained that First View loads a page with an empty browser cache, like a new visitor, and Repeat View loads it again with the cache kept, like a returning one.

Likewise, I asked readers to give LCP the most weight, and I noted that TBT depends mostly on a site’s own code.

What stayed fixed

The settings every test shared

The settings matched on both sides of every migration. A test from another city or connection would have looked like a change of host.

tool: WebPageTest, free and rerunnable by anyone
same each time: test location, browser, connection matched on both sides of every migration
timing: just before each migration, again right after it the site had no time to change in between
metrics: TTFB, LCP, TBT, Fully Loaded Time each split into First View and Repeat View
period: 3 months, published August 2022
floor: 10 migrated sites per host for its own table more than a dozen hosts fell below it

The method

Keeping one slow run or a cold cache from deciding a result

Runs

3 runs, median kept

WebPageTest ran each test 3 times and we kept its median run, so one slow run on a busy network couldn’t decide a site’s result.
Cache

Warmed before each after test

A site’s first request after a cache clear builds the page from scratch, which is slower than what visitors get. I never wrote the warm-up into the study’s method section.
Reporting

Both views, and seconds beside every percentage

A returning visitor’s cached files would have hidden what a new visitor waits for, so no metric was averaged across the 2 views. And a big percentage on a tiny number looks worse than it is: Bluehost’s First View TBT rose 60.66%, the biggest jump in any table, and in seconds that’s 0.11.

The anomaly

First View LCP got slower for 4 of 9 host groups

Before migrating

DigitalOcean, First View LCP

3.26 s

SiteGround, First View LCP

2.21 s

First View LCP for the 2 groups that lost the most, from the published tables.

After migrating

DigitalOcean, First View LCP

4.21 s, up 0.95 s

SiteGround, First View LCP

2.75 s, up 0.53 s

What happened

Published with the losses in, and quoted ever since

23 of the 72 comparisons were slower after migrating and all 23 went up. Four years on, 14 kinsta.com pages still quote the numbers.

The findings

Server response got faster in 17 of 18 comparisons

Time to first byte, mostly the server’s share of the wait, got faster in 17 of 18 comparisons. SiteGround’s First View was the one exception.

Bluehost LCP: First View −47.20%, Repeat View −38.68%
HostGator LCP: First View −34.51%, Repeat View −29.35%
Liquid Web LCP: First View −22.83%, Repeat View −32.24%
DreamHost LCP: First View −6.57%, Repeat View −11.01%
Other LCP: First View −5.15%, Repeat View −25.11% The ninth table pooled the hosts below the 10-site floor.
Cloudways LCP: First View +1.71%, Repeat View −2.26%
Amazon AWS LCP: First View +7.71%, Repeat View −25.75%
SiteGround LCP: First View +24.01%, Repeat View −13.09%
DigitalOcean LCP: First View +29.25%, Repeat View −26.15% TTFB dropped from 0.93 to 0.54 seconds, so something after the first byte got slower.

A minus sign means LCP dropped, so the main content showed up sooner, and you can check every row yourself in the 72-comparison CSV.

A returning visitor got the clearer win: Repeat View LCP improved for all 9 groups, by 22.63% with the groups weighted equally, against 5.95% on a First View. Counting all 4 metrics, First View comparisons got faster in 19 of 36 cases and Repeat View in 30 of 36.

What this page doesn’t claim

Kinsta ran the study on its own migrations, and I wrote it as a Kinsta employee. That makes it first-party evidence.
WebPageTest measured lab loads from one location, browser, and connection. Visitors on other networks and devices would see other numbers.
The after test measured Kinsta’s whole setup in 2022, caching and CDN included. Edge Caching only reached its WordPress plans that December.
I no longer have the sheet, so I can’t show how I weighted the 20% headline across 3,200+ sites.
The public reuse is what I can show. I have no sales, conversion, or revenue numbers for the study.

The DigitalOcean table The DigitalOcean table as published in August 2022, from the Wayback Machine capture. First View LCP 0.95 seconds slower after migrating Source: Kinsta Open the source
First View and Repeat View My screenshot comparing WebPageTest’s First View and Repeat View results, from the study. The 2 views every metric was split into Open the source

What the tables look like

The chart I drew from the 9 published tables

Drawn in 2026 from the study I published in 2022. Every value in it is in the CSV below.

Drawn 2026, from the 2022 tables First View and Repeat View LCP change for each host group, drawn from the 9 published tables. Chart by me, 2026. See the published tables

Then and now

Comparison pages quoted the study within weeks and still do

After I published the study, I suggested a speed section for Kinsta’s comparison pages, each with its host’s number. Wayback Machine captures show them on 7 comparison pages between August 5 and August 23, 2022, and on June 29, 2023 a Kinsta LinkedIn post promoted the study.

By now it is in 8 languages, and later Kinsta articles still reach for it — the 3,200+ migrations are its best performance evidence in an October 2025 article on do-it-yourself VPS setups. In their 2025–2026 versions, at least 14 kinsta.com pages quote it: 10 use the overall 20%, and the other 4 keep their host’s own number.

What I got wrong

Mistakes I found in my own study 4 years on

I described the numbers in the 9 summary bullets at the end of my study as mean improvements in page load time. All 9 are their host’s Repeat View LCP change, rounded.

Kinsta’s comparison pages kept that wording next to the numbers. Sites from DigitalOcean loaded 26% faster on average, says the DigitalOcean page — that is their Repeat View LCP, and on a First View the same group’s LCP got 29.25% slower in my own table.

Errors in my text: In the results section I explained the minus signs by writing that slower times are better, when I meant lower times.

In my takeaway on Fully Loaded Time I named Cloudways as the only First View exception. Four groups got slower on a First View, and SiteGround’s 10.56% was the largest.
Numbers left unexplained: I wrote “32,000+ data points” and never said what one was. That works out to 10 data points per site.
Names and punctuation: I misspelled 3 host names in the table headings (BlueHost, Dreamhost, and Digital Ocean).

I left a parenthesis out of the Amazon AWS bullet.
What I’d label better: Print the site count next to the host tables.

Label summary numbers with their metric and their view.
What I’d set differently: Set WebPageTest’s medianMetric to its LCP metric, since the headline was an LCP number. Its API reference lists loadTime as the default.

Write down how the after test reached the new copy of a migrated site.

Keep the raw export and the sheet alongside the published study.

Every error above was checked word for word against the August 2, 2022 capture.

Sources and credits

The capture every number here comes from

Sources

Credits

Published: Kinsta, August 1, 2022
Test design: Kinsta’s website speed testing team, me included
Collection: Kinsta’s migrations team
Illustrations: Kinsta’s design team
WebPageTest screenshots: Salman Ravoof
Analysis and writing: Salman Ravoof

Since I left, Kinsta has changed the live study’s product sections. Its method, tables and takeaways still match the August 2022 capture.