Why Webflow Designers need this
A Webflow site can look flawless in the Designer and still feel heavy once it is live. Interactions pile up, a Lottie animation sits in the hero, and a CMS image uploaded at full camera resolution ends up in a collection template. Add a webflow.io staging address that may be indexed next to the live domain, and hand-pasted JSON-LD nobody has verified, and it gets hard to know what the published page really serves. Before handing a build to a client, it helps to read numbers from a live request instead of guessing from the canvas. Paste the published URL into the Page Speed & Size Test and it makes one server-side request, then reports first-byte time, HTML download time, HTML weight, compression, and how many scripts, stylesheets and images the markup references. It does not run interactions, fetch Lottie files or report Core Web Vitals, so read it as a check on the document and on what that document calls for.
Webflow Designers specific guidance
What to check first
Start with the published page, not the Designer preview. Publish to your custom domain, then paste a deep URL such as https://example.com/blog/summer-launch-checklist, because CMS template pages often carry different embeds than the homepage. Run it twice and compare, since cache state shifts a single result. In Site settings, under Publishing, check which domain is the default one and make sure you are testing that address rather than the webflow.io one; testing both shows whether staging serves the same markup. Then glance at Resource Breakdown: the counts of External scripts, Stylesheets and Images come straight from the HTML. What this run does not prove is how heavy your Lottie files or background videos are, because it never downloads them.
How to read the result
Look at Time to First Byte first: under 200 ms is good, under 600 ms is a warning, anything above is bad. Server time on a hosted platform is mostly outside your control, so a bad value is worth rerunning rather than redesigning around. Then read Page size (HTML) and Compression. A collection page that renders many items inline can push the HTML up, and a long custom code embed shows up here too. Render-blocking is scripts plus stylesheets, and the related check allows up to 25 files. A passing score does not mean the page is light for visitors, because images and animation data load after the HTML and are not part of these figures.
What to fix, in order
If Images lands near the limit of 40, deal with that first: on a collection list, reduce how many items render per page and use pagination, and re-export oversized uploads at the size they are displayed before replacing them in the Assets panel. Next, trim interactions, removing page-load animations on elements far below the fold, and swap a decorative Lottie for a static image where motion adds nothing; these changes help visitors but will barely move this report, because it never runs or downloads them. Last, review Site settings, Custom code, since every external script you paste there raises the External scripts and Render-blocking counts. Republish and run the same URL again to compare. The test cannot tell you which interaction or embed caused a change, so alter one thing at a time, or compare a heavy page against a light one.
Example scenarios
1. Homepage with a hero Lottie
- Situation
- Illustrative example: a designer adds a hero Lottie, scroll interactions on four sections and three custom code embeds for chat, analytics and a cookie banner, then publishes the homepage.
- Input
https://example.com/- Reading the result
- The report might show Time to First Byte around 450 ms (warning band), Page size (HTML) near 180 KB, Compression on, 9 External scripts, 2 Stylesheets and 14 Images. The HTML is healthy, but the Lottie file itself is not measured here, so check its exported file size separately and watch the script count.
2. CMS blog post template
- Situation
- Illustrative example: a blog post template contains a Collection list that shows all 60 related posts, each with a cover image, instead of three.
- Input
https://example.com/blog/summer-launch-checklist- Reading the result
- Expect Images to read roughly 62, above the 40-image check, while Page size (HTML) might be 640 KB, still under 1 MB. The pattern points to the collection list, not the server. Limit the items shown, republish and compare the Images count on the same URL.
3. Staging and live compared
- Situation
- Illustrative example: before a client launch, the team wonders whether the webflow.io address serves the same heavy markup as the custom domain, which would mean two copies of a page with 12 scripts and 30 images.
- Input
https://example-studio.webflow.io/work/rebrand-case-study- Reading the result
- Run it, then run the matching live URL. Similar Time to First Byte (say 420 ms on both) and identical counts of 12 External scripts and 30 Images mean both addresses serve the same page, which is why duplicate indexing matters. The test does not show whether Google has indexed either one.
Common mistakes
- Testing the Designer preview. Only the published URL reflects live hosting, compression and custom code. Test after publishing, not on the canvas.
- Trusting one run. A single result moves with cache state and network conditions. Run the URL at least twice before changing the build.
- Expecting Lottie weight in the numbers. Only the HTML document is downloaded, so animation JSON, images and video are not counted. Check those files in the Assets panel and in your export.
- Testing only the homepage. CMS template pages carry collection lists and embeds that the homepage may lack. Test one deep post or item URL as well.
- Treating a pass as a speed guarantee. A good score means the document is delivered well, not that interactions feel smooth on a phone. Follow up with a Core Web Vitals check.
Frequently asked questions
Is Webflow good for SEO if my pages feel heavy?
Platform choice rarely decides page weight; what you add does: interactions, Lottie files, large CMS images and custom code embeds. Run the Page Speed & Size Test on a published page to see Time to First Byte, HTML size, compression and the counts of scripts, stylesheets and images. It cannot show image or animation file sizes, so review those in the Assets panel too. A good result removes one doubt; it does not decide rankings.
Does the test show how big my Lottie file is?
No. It downloads only the HTML document of the URL you enter, so Lottie JSON files, images, videos and CSS are never fetched. What you can see is indirect: Page size (HTML) and the number of scripts, stylesheets and images referenced. To judge a Lottie, check the size of the file you uploaded, then run the test on a page with the animation and one without.
How do I disable webflow.io subdomain indexing, and can this tool check it?
In Site settings, open the SEO tab, switch on the option that disables indexing of the webflow.io subdomain, then publish. Robots.txt only controls crawling, so pages already in Google may linger. This speed test cannot verify indexing; it only tells you how fast the staging URL responds. Use the robots tester for crawl rules and Search Console for what Google actually holds.
What is a good TTFB for a Webflow page?
Under 200 ms is rated good, under 600 ms lands in the warning band, and anything higher is bad. Server time on hosted platforms is largely out of your hands, so run the URL several times at different hours before drawing conclusions. If it stays high, compare a CMS template page with a static page, and check whether a proxy or redirect sits in front of the site.
Why does my Webflow page pass but still feel slow?
The score reflects the HTML response, compression, caching headers and counts of scripts, stylesheets and images. It does not render the page, so slow interactions, heavy Lottie playback, large images and layout shifts are invisible to it. Treat a pass as proof the document is delivered well, then test on a real phone and use a Core Web Vitals report for user numbers.
Reference: SiteGuru's guide to SEO for Webflow explains that the platform has no built-in schema markup feature, so structured data needs custom code and the work is more hands-on than on plugin-based platforms.