Launching a slow website costs you first impressions, search rankings, and conversion rate from day one, and recovering from a poor performance baseline after launch is significantly harder than preventing it before the DNS switch.
Loading Website Speed Test…
Pre-launch performance audit
Core Web Vitals pass/fail check
Actionable recommendations before go-live
No sign-up required
Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="Website Speed Test by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
Launching a website with poor performance is significantly harder to recover from than preventing the performance issues before launch in the first place. Post-launch speed fixes require careful staged rollouts to avoid disrupting live traffic, and the period between launch and fix means real users and Googlebot encounter poor performance at the critical moment when first impressions, first conversions, and first crawl data are established. CrUX field data also begins accumulating from the moment your site goes live, which means a poor first month can influence Search Console reporting for weeks even after the underlying issues are fixed. A pre-launch performance audit takes 30 to 60 minutes and should be treated as a non-negotiable part of the launch checklist alongside DNS configuration, SSL setup, and content proofreading. The minimum pre-launch performance bar should be a Lighthouse mobile score of 75 or higher and all Core Web Vitals in the Good or Needs Improvement range.
A comprehensive pre-launch speed audit covers five layers in sequence. First, server configuration: verify TTFB is under 500ms, HTTP compression using gzip or Brotli is enabled, and browser caching headers are set with appropriate max-age values for static assets. Second, images: confirm all images are compressed, converted to WebP where supported by the visitor's browser, and have explicit width and height attributes that prevent CLS. Third, JavaScript: confirm render-blocking scripts are deferred or marked async, unnecessary scripts are removed entirely rather than just hidden, and total JavaScript weight is under 300KB compressed for the typical landing page. Fourth, CSS: confirm render-blocking stylesheets are either inlined for critical above-fold content or loaded with appropriate priority hints. Fifth, third-party integrations: every analytics, chat, and advertising script adds measurable load time, so confirm each one is genuinely justified and loaded with async or defer.
Test performance under realistic conditions before launch rather than on your development machine where the comparison is meaningless. Development environments with local servers and uncached builds produce artificially fast or artificially slow performance depending on the specific configuration, and the numbers cannot be relied upon as a predictor of production behaviour. Staging environments running on the actual production hosting infrastructure with the production CDN and caching configuration enabled are the most accurate pre-launch proxy you can build. If your staging environment does not have CDN and caching enabled to match production, you will discover performance issues that only appear in staging but not production, or worse, the inverse case where staging appears fast but production is slow because nobody noticed the caching layer was never enabled in the live environment.
The pre-launch audit is also the right moment to establish a documented performance baseline that you can defend against future regressions. Capture the Lighthouse report for each key page template, save screenshots of the Core Web Vitals values, and record the page weight and request count for each test. Store these artefacts in the project documentation alongside the launch sign-off, because they become the reference point against which any post-launch performance regression can be measured. A team that ships at 85 on mobile but drifts to 65 within a year cannot easily diagnose what changed without that baseline, while a team with documented pre-launch numbers can quickly identify which deployment, plugin, or third-party addition pushed the score down and revert it before the regression compounds further.
Enter your staging URL to run a complete pre-launch speed test. Fix any failing metrics before switching to your live domain.
Step-by-step guide to test website speed before launch:
Test on staging before launch
Run the speed test on your staging URL, not your live production site, so any issues you discover can be fixed without disrupting real traffic. The staging environment should mirror production hosting, caching, and CDN configuration so the test results actually predict production behaviour rather than reflecting a development-only environment that bears no resemblance to what users will experience after the DNS switch goes live and traffic starts flowing.
Test all key page templates
Test the homepage, a product or service page, a blog post or article, and any page with heavy media, embeds, or third-party widgets. Each template has different performance characteristics because each has different content types, different image weights, different scripts, and different layout complexity. Testing only the homepage gives a misleading picture of overall site performance and risks launching with hidden issues on the templates that actually drive traffic and revenue.
Ensure all Core Web Vitals pass
Check LCP, CLS, and INP against the Good thresholds of 2.5 seconds, 0.1, and 200ms respectively on every tested template. Failing any single Core Web Vital at launch means starting with a Page Experience penalty applied from the very first moment Google crawls the site, which delays the eventual ranking benefit that good performance provides and creates an avoidable handicap your competitors do not have to overcome.
Target 80+ on mobile before go-live
Do not launch with a mobile Lighthouse score under 70 unless there is a specific business reason that outweighs the SEO and conversion cost of doing so. Address the top failing opportunities shown in the audit report until you reach at least 80 on mobile, and aim higher than that if the site competes in a performance-sensitive category such as e-commerce or news where rival sites already score in the 85-plus range. Delaying launch by a week to hit the target is almost always cheaper than launching at 60 and trying to recover later.
Common situations where this approach makes a real difference:
Agency handover quality gate
A web agency includes a documented speed test report as part of their formal launch sign-off process, embedding it directly into the project handover checklist that the client must counter-sign before go-live. The client must approve a mobile Lighthouse score of at least 80 and passing Core Web Vitals on every key page template before the agency authorises the live DNS switch. This contractual quality gate prevents under-optimised sites from launching, protects the agency's reputation against future complaints about slow performance, and gives the client a clear baseline against which they can measure any future regression caused by their own post-launch changes.
WooCommerce redesign
A developer relaunching an e-commerce site on a new theme tests the staging environment and discovers a mobile score of 42 caused by the new theme loading 22 font variants at first paint. The font weight inventory is reviewed, the design team agrees that only two of those weights are actually used in the visual identity, and the remaining 20 are removed from the theme configuration. Mobile Lighthouse jumps to 76 within a single deployment cycle, the launch proceeds on schedule, and the team avoids the much harder post-launch task of explaining to the client why the new site loads more slowly than the old one it replaced.
Startup MVP launch
A startup founder preparing their first marketing website uses the pre-launch speed test to discover that their auto-playing hero video is causing a 7-second LCP on mobile, which would have given visitors a terrible first impression of a product that depends on quick judgement to acquire users. They replace the video with a static hero image paired with a play button that loads the video only on user click, and the page now launches with a 2.1-second LCP instead. The change takes one afternoon, costs nothing, and protects the launch campaign from being undermined by a performance problem that would have been invisible to the founder until users started bouncing.
Use this as a mandatory step in your website launch checklist, before switching DNS to a new site or deploying a major redesign.
Get better results with these expert suggestions:
Test on the actual hosting environment before launch
Development machines and staging servers often differ significantly from production hosting in CPU speed, available memory, caching configuration, and CDN presence. Always run your pre-launch speed test on the actual production hosting environment, or on an identical staging environment that mirrors production in every relevant dimension, to get representative results rather than testing locally on a machine that bears no resemblance to what real visitors will encounter. The test is only as good as the environment it runs in, and a misleading test result is worse than no test at all.
Set a performance budget before development begins
A performance budget defines maximum acceptable values for page weight, number of requests, and load time before development starts, making performance a design constraint rather than an afterthought. Establishing these constraints upfront prevents the steady accumulation of just-one-more-plugin and just-one-more-script changes that quietly add seconds to load time over the course of a build. Reasonable budgets for most marketing sites are under 500KB total compressed page weight, under 50 HTTP requests on initial load, and LCP under 2 seconds on desktop with an equivalent target for mobile.
Include third-party scripts in your pre-launch test
Many performance issues only appear in production because third-party scripts such as analytics, chat widgets, heatmaps, and advertising tags are conditionally loaded and not present in early development testing. Run at least one pre-launch test with the full complement of production scripts enabled to see how they affect performance under realistic conditions. Third-party scripts commonly add 300ms to 800ms to mobile load time and can shift Core Web Vitals from Good to Poor on their own, so testing without them gives a falsely optimistic picture of launch readiness.
Document your baseline before launch for comparison
Record your pre-launch Lighthouse scores, Core Web Vitals values, and page weights as a documented baseline saved alongside the launch sign-off. After launch, re-test the same pages weekly for the first month so any significant performance regression is immediately visible against the documented baseline. This practice allows quick identification and remediation of post-launch changes that degraded performance, and it produces a permanent record that protects the original launch quality against drift over time as new content and plugins accumulate.
Test on staging before switching DNS
Run all performance tests on your staging URL before pointing your domain to the new site. This lets you fix issues in a safe environment without affecting live traffic or current search rankings.
Include all page templates, not just the homepage
Performance issues often appear on specific page types, product pages with image galleries, long-form content pages, or pages with embedded videos. Test one representative page of each template type.
Target a mobile performance score of 80+ before launching
A score under 70 on mobile at launch means you are starting with a Page Experience disadvantage that will take weeks to fix. Delay launch if needed to get mobile performance to at least 80.
More use-case guides for the same tool:
Open the full Website Speed Test — free, no account needed, works on any device.
Open Website Speed Test →Free · No account needed · Works on any device