Website speed test
Enter any URL to get its Google PageSpeed Insights score for mobile and desktop, the six core load metrics, and the biggest speed wins.
Run a full graded audit for the whole site.
Enter any URL to get its Google PageSpeed Insights score for mobile and desktop, the six core load metrics, and the biggest speed wins.
A website speed test measures how fast your pages load and identifies which elements are slowing them down. Enter any URL to see load time, Core Web Vitals scores, resource breakdown, and a detailed analysis of performance bottlenecks—from uncompressed images to render-blocking scripts—so you know exactly where to focus optimization efforts.
A website speed test doesn't just measure how many seconds a page takes to fully load. It breaks down what happens during that load into distinct phases, measuring when specific milestones occur and how much each resource contributes to total time. The tool captures DNS lookup time (time spent finding your server's IP address), connection time (establishing the network connection), server response time (how long your server takes to send the first byte of data), and download time (how long it takes to receive all the page's HTML, CSS, JavaScript, and images). It also measures browser rendering time—how long it takes to process and display the content once downloaded. Each of these phases tells you something different about where your performance problem lives.
Beyond timing, the test analyzes your page's resource composition: total size in kilobytes, number of HTTP requests, breakdown by file type (images, scripts, stylesheets, fonts), and identifies which resources are largest. It also checks for issues like uncompressed files, missing caching headers, and resources requested multiple times. This level of detail means you see not just "slow" but specifically "slow because of three unoptimized JPEGs" or "slow because JavaScript blocks page rendering."
Google measures website quality using three Core Web Vitals metrics—specific performance thresholds that directly impact search rankings. These metrics appear in your speed test results and are the most important numbers to watch.
| Metric | Measures | Good Score | Poor Score |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Time until the largest visible element (text block, image, or video) appears on screen | Under 2.5 seconds | Over 4 seconds |
| Interaction to Next Paint (INP) | Delay between a user's click/tap/keystroke and the browser's response | Under 200 milliseconds | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much elements move around after the page loads (visual instability) | Under 0.1 | Over 0.25 |
A score in the "Good" range means you rank favorably for performance; a "Poor" score signals both user frustration and ranking penalties. The speed test calculates each metric by simulating a page load and tracking exactly when these events happen. If LCP is 5 seconds, your largest element takes too long to appear. If CLS is high, buttons or text are shifting after you try to click, causing accidental clicks on the wrong target.
A page's performance on a desktop computer with a fast network connection is almost always faster than on mobile. The speed test reports both. Desktop testing assumes a high-speed connection and modern hardware; mobile testing simulates a real smartphone on a slower 4G network, using less processing power. The mobile result is closer to what most of your visitors actually experience. A page that loads in 1.5 seconds on desktop might take 4+ seconds on mobile due to smaller processing power, slower networks, and additional mobile-specific overhead like rendering delays and JavaScript parsing.
Pay attention to mobile scores first. If desktop and mobile scores diverge dramatically—say, 1.2 seconds versus 5.1 seconds—the gap usually points to JavaScript or large images that hit mobile processing harder. Conversely, if mobile scores are close to desktop, your bottleneck is likely a slow server or network issue affecting both equally.
Google confirmed that page speed affects search rankings. Sites with poor Core Web Vitals scores may rank lower than faster competitors, especially on mobile. Speed is tied directly to the user experience Google prioritizes—a slow page is more likely to frustrate visitors and cause them to leave before your content even loads. But speed's business impact extends beyond search. Users are less likely to complete purchases, sign up, or spend time on a slow site. A site taking 6 seconds to load instead of 3 typically sees measurably lower engagement and conversion rates.
Beyond users, slow pages consume more bandwidth, generate more server load, and increase hosting costs. A page serving uncompressed images or render-blocking scripts burns through CDN bandwidth quota faster. Improving speed often reduces infrastructure costs while simultaneously improving both search visibility and user behavior.
Your test results show metrics at the top (LCP, INP, CLS, overall load time) and a waterfall chart below. The waterfall shows every resource your page requested, in order, with a horizontal bar representing how long that resource took to download. Resources with extra-long bars are your biggest time sinks. The chart also uses colors to show different phases: gray bars are time spent looking up DNS, green bars are connection time, blue bars are waiting for the server response, and orange bars are downloading the actual file.
Below the waterfall is a breakdown by file type—total size of all images, total size of all JavaScript, etc. This tells you immediately if your slowness is image-related (common) or code-related. A page with 5MB of images but only 200KB of HTML and CSS has a clear optimization target. Look for any resource larger than 500KB; these are usually candidates for compression or removal.
Pay special attention to files marked "Render-blocking"—these stop the browser from displaying anything until they finish downloading. A render-blocking stylesheet or script appearing early in the waterfall directly delays when users see your page. These are high-priority fixes.
After making changes, run the speed test again to measure improvement. Core Web Vitals should improve first—these are what Google measures and what users notice. Load time improvement follows from fixing the largest bottlenecks identified in your waterfall.
Aim for a page to be interactive (ready for user clicks) in under 3 seconds on desktop and under 5 seconds on mobile. First Contentful Paint (when the first content appears) should happen in under 1.8 seconds. Times over 4-5 seconds on mobile see higher bounce rates and lower engagement. The faster, the better—even differences between 1 second and 2 seconds correlate with measurable behavioral differences.
Test after any significant changes—adding new features, plugins, images, or content. Test before and after making optimization changes to verify improvements. For ongoing monitoring, weekly or monthly tests catch performance regressions (when speed suddenly worsens). If your site is in active development, testing before each deployment prevents shipping a faster version that silently broke performance.
Largest Contentful Paint should be under 2.5 seconds (2.5 seconds is Google's "good" threshold). Interaction to Next Paint should be under 200 milliseconds—anything over 200ms feels sluggish to users. Cumulative Layout Shift should be under 0.1—this means the sum of all unexpected element movement is minimal. Scores below these thresholds are considered "good" by Google and rank-favorable. Scores between the good threshold and 4 seconds (LCP) or 500ms (INP) or 0.25 (CLS) are "needs improvement."
Yes. Google confirmed page experience (which includes Core Web Vitals) as a ranking factor. A site with poor Core Web Vitals may rank lower than a faster competitor. Speed isn't the only factor—content quality, authority, and relevance matter too—but all else equal, the faster site ranks better. Mobile speed has more impact than desktop speed since most searches now come from phones.
The speed test simulates average user conditions, not your personal setup. Your computer likely has cached files from previous visits, a faster internet connection than the median user, and more processing power. The test clears the cache and uses median network speeds (like a typical 4G mobile connection). Testing this way reveals what most visitors actually experience, not what you experience as the site owner on your home network.
This tool tests from a single location. If you need to see how your site performs in specific geographic regions, other speed test tools like WebPageTest or GTmetrix offer global testing locations. However, using a Content Delivery Network (CDN) is a more practical solution—it automatically serves your content from servers near your users worldwide, reducing latency everywhere.
Slow server response often indicates inefficient code or database queries, not always hardware limitations. Have your developer profile the server response time to see where the delay occurs—is it database queries, rendering template files, or external API calls? Often optimization within your existing code removes the delay without needing to upgrade. A caching layer like Redis can also speed up repeated operations. Only after profiling should you consider faster hosting.