Page Speed Test Online — Free Page Speed Test Tool
CodexFuse Team · 2026-11-02T18:58:51.185Z · 10 min read min read
Run a free page speed test on any URL, read your Core Web Vitals, and fix the biggest slowdowns first — with a worked example and honest limits.
A page speed test measures how quickly a web page loads and becomes usable, scoring that experience so you can see exactly what is slowing visitors down. Instead of guessing whether your site feels slow, you get numbers for load time, visual stability, and responsiveness — plus a ranked list of fixes.
That matters because visitors rarely complain about speed. They simply leave. A page that stutters, jumps as it loads, or freezes while scripts run loses enquiries and sales long before anyone reports a problem.
What is a page speed test?
A page speed test loads a URL in a simulated mobile or desktop browser, records how the page renders frame by frame, and turns that recording into a performance score with Core Web Vitals metrics. It also lists optimisation opportunities, such as oversized images or render-blocking scripts, with an estimated time saving for each fix, so you know where to start.
The free page speed test from CodexFuse works this way. You enter a URL, choose mobile or desktop, and click Analyse. You then see a performance score dial, a Core Web Vitals tab, category scores, and a visual timeline filmstrip showing how the page appeared as it loaded.
Why a slow page costs more than a slow feeling
Speed shapes trust. A visitor who waits for a hero image, then watches the checkout button jump down the screen, does not think about JavaScript bundles. They think the business is careless, and they go back to the search results. Search engines read the same signals, so slow pages can rank below faster competitors for the same query.
- Lost conversions: every extra second of load time gives visitors another reason to abandon a form, a booking, or a basket.
- Wasted ad spend: paid clicks that land on a slow page bounce before they ever see the offer.
- Quiet reputation damage: a juddering, shifting page feels unprofessional even when the product behind it is excellent.
- Compounding technical debt: uncompressed images and unused scripts pile up with every redesign until nobody remembers what each one was for.
How to run a page speed test in under two minutes
Open the CodexFuse page speed test, paste the full URL — your homepage first, then your most important landing page — and select Mobile or Desktop. Mobile is the right default for most sites, because that is where constraints are strictest and most visitors are.
Click Analyse, then work through the report in this order:
- Read the score dial first: Fast, Needs Improvement, or Poor tells you how urgent the problem is at a glance.
- Open the Core Web Vitals tab: check which metric is failing rather than chasing the headline score.
- Open Optimisation Opportunities: sort by estimated saving and start with the largest one.
- Watch the filmstrip: the visual timeline shows what a real visitor actually sees second by second.
- Save the report: use Copy Summary or Export JSON so you can compare before and after your changes.
Test the same page twice: once on mobile and once on desktop. A page that scores well on a fast office connection can still fail badly on a mid-range phone, and the mobile result is usually the one that decides whether visitors stay.
A worked example: one shop, one slow homepage, one fix list
Consider a clearly fictional scenario. Leaf & Loom, a small online plant shop, runs a homepage with a full-width hero photograph, an Instagram feed widget, a chat widget, and three tracking scripts. The owner suspects the site is slow but has no numbers, so she runs a mobile page speed test on the homepage.
The first result is blunt: a score of 52, rated Poor. Largest Contentful Paint — the time until the main content appears — is 4.8 seconds. Cumulative Layout Shift, measuring how much the page jumps as it loads, is 0.28. The filmstrip shows a blank header for nearly two seconds, then the hero image, then text reflowing as web fonts arrive.
| Opportunity | Estimated saving | What it means |
|---|---|---|
| Serve images in next-gen formats | Around 1.9 seconds | The hero is a 2.4 MB JPEG; a compressed WebP version is roughly a third of the size. |
| Eliminate render-blocking resources | Around 1.2 seconds | Two scripts delay the first paint though they are not needed until later. |
| Reduce unused JavaScript | Around 0.8 seconds | The chat widget loads on every page, including pages where nobody opens it. |
| Properly size images | Around 0.4 seconds | Thumbnails are served at full resolution and shrunk by CSS. |
Leaf & Loom compresses the hero image, defers the two scripts, and loads the chat widget only after the visitor scrolls or clicks. A retest shows a score of 88, Largest Contentful Paint down to 2.3 seconds, and layout shift down to 0.05. Nothing about the design changed. The page simply stopped making visitors wait for work that did not need to happen first.
How do you read the Core Web Vitals?
Core Web Vitals are three user-centred measurements: Largest Contentful Paint tracks how fast the main content becomes visible, interaction responsiveness tracks how quickly the page reacts to a tap or click, and Cumulative Layout Shift tracks how much visible content moves unexpectedly while the page loads. Together they describe what loading actually feels like, not just how fast a server responds.
| Metric | What it measures | Typically good |
|---|---|---|
| Largest Contentful Paint (LCP) | When the largest visible content appears | 2.5 seconds or less |
| First Contentful Paint (FCP) | When the first text or image appears | 1.8 seconds or less |
| Total Blocking Time (TBT) | How long the page is unresponsive to input | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps as it loads | 0.1 or less |
| Time to First Byte (TTFB) | How fast the server first responds | 800 milliseconds or less |
| Speed Index | How quickly content is visually displayed | 3.4 seconds or less |
One failing metric usually explains most of the damage. A high LCP points at images, fonts, or server response. A high CLS points at images without dimensions or web fonts that swap in after text has rendered. A high blocking time points at heavy JavaScript.
Do not chase a perfect 100. A score in the high 80s or 90s with all Core Web Vitals in the green is a strong result for a real business site. The last few points often cost disproportionate effort and rarely change visitor behaviour.
What should you fix first?
Work down the Optimisation Opportunities list by estimated saving, not by what looks easiest. The largest saving is usually the fix visitors will feel most.
- Compress and resize images: serve modern formats, size images to their display dimensions, and lazy-load anything below the fold.
- Defer non-critical scripts: anything not needed for the first paint — chat widgets, tracking, social embeds — can load after the page is usable.
- Reserve space for late content: give images, embeds, and ad slots explicit width and height so the layout cannot jump when they arrive.
- Trim unused code: remove plugins and scripts that no longer serve a purpose; each one is weight every visitor downloads.
- Check the server, not just the page: if Time to First Byte is high on every page, the bottleneck is hosting or server configuration, not your images.
After each round of fixes, retest the same URL in the same mode and save the new report. For a deeper dive into the vitals, see the Core Web Vitals checker guide, and if your connection itself is suspect, a download speed test helps separate your broadband from your website.
Run the free CodexFuse page speed test on your most important page, then move the hosting, fixes, and ongoing care to one fully managed platform on credits — no subscriptions, no server babysitting.
Get Started with CodexFuseWhat this tool will not tell you
Honest limits matter here. The CodexFuse page speed test produces simulated estimates in the browser, not a live Google PageSpeed Insights measurement, so its scores can differ from data collected from real visitors. Treat it as a fast diagnostic and a before-and-after comparison tool, not as the final word on your ranking.
It also cannot see what happens after login, behind a checkout, or on a weak 4G signal on a low-end phone. Verify the worst pages with real-device checks before committing to a large rebuild. Note too that the tool page asks you to sign in with a free CodexFuse account before use — worth knowing before you send a client a link expecting an instant result.
If slow pages are part of a wider hosting problem, read what to do first, second, and third for website speed and the page authority checker guide for the authority side of the same visibility problem.
When speed points to hosting, not just images
There is a pattern worth recognising. If you compress every image, defer every script, and Time to First Byte is still high on every page, the server is the bottleneck. No front-end tidying fixes a slow host or an overloaded shared server.
On CodexFuse, the concrete workflow is: run the page speed test and export the JSON report, then bring that report when you move the site over — the managed team handles migration, hosting setup, and ongoing care on a credits basis, so you pay as you go rather than signing a subscription. Retest the same URLs after migration and compare the saved reports. If Time to First Byte falls without touching the design, hosting was the constraint. A quick internet speed test can rule out your own connection before you blame the host.
Frequently Asked Questions
Is the CodexFuse page speed test free?
Yes, it is free with unlimited tests. The tool page asks you to sign in with a free CodexFuse account, and from there you can test any public URL in mobile or desktop mode and export the report.
What is a good page speed test score?
A score in the high 80s or 90s with Core Web Vitals in the green is strong for a real business site. Scores below 50, rated Poor, usually mean visitors wait several seconds for usable content and fixes should be a priority.
Why do mobile and desktop scores differ?
Mobile tests simulate a slower device and connection, so the same page almost always scores lower on mobile. That gap is normal and useful: it shows what most of your visitors, who browse on phones, actually experience.
Can a page speed test improve my Google ranking?
Not directly. The test itself changes nothing. The fixes it recommends — faster images, less blocking JavaScript, stable layouts — improve the experience signals search engines use, which can support better visibility over time.
How often should I test my site?
Test after every significant change — a redesign, a new plugin, a new widget — and retest your homepage and top landing pages monthly. Speed degrades gradually as content and scripts accumulate, and regular tests catch that drift early.
What if my score is poor even after optimising images?
Look at Time to First Byte and Total Blocking Time next. High server response points to hosting, while high blocking time points to JavaScript. If both are clean, the remaining opportunities list shows the next largest saving to work through.
Stop guessing about your site speed
Run a page speed test on your homepage today, fix the largest opportunity first, and retest to prove the improvement. If the report keeps pointing at the server — slow first-byte times on every page, no matter what you optimise — move your hosting to CodexFuse and let a fully managed platform on credits carry the performance work, so you can get back to running your business instead of babysitting a server. Get started with CodexFuse now, bring your saved test report, and make your fastest page the one every visitor lands on.
