Page Speed Test

Page Speed Test (Mobile & Desktop) + Core Web Vitals

Test your website speed on mobile and desktop devices to measure Core Web Vitals, performance metrics, and loading times. This free page speed test analyzes your site's performance and provides actionable recommendations to improve loading speed and user experience.

Get detailed insights into LCP, INP, CLS, and other critical metrics that affect both user experience and search engine rankings.

Run a Free Page Speed Test

Testing your website's performance takes just seconds with this comprehensive speed analyzer.

Enter your page URL in the field above. Include the full URL with protocol (https://www.example.com/page). Test specific pages rather than just your homepage to understand performance across your entire site.

Select device type for testing. Choose mobile to see how your site performs on smartphones, or desktop to analyze performance on computers. Mobile speed is particularly important as Google uses mobile-first indexing and mobile page experience affects rankings.

Click Test to analyze your page. The tool measures loading times, evaluates Core Web Vitals, calculates performance scores, and generates specific recommendations for improvement.

Review your results showing Core Web Vitals (LCP, INP, CLS), additional performance metrics (FCP, Speed Index, TBT, TTI), overall performance score, and actionable suggestions for optimization. Results include both lab metrics from simulated testing and field data from real user experiences when available.

What You'll Get in the Speed Test Report

Your page speed test provides comprehensive performance analysis across multiple dimensions.

Core Web Vitals measurements show the three critical user experience metrics Google uses for ranking:

• LCP (Largest Contentful Paint) measures loading performance by tracking when the largest content element becomes visible
• INP (Interaction to Next Paint) measures interactivity by assessing how quickly the page responds to user interactions
• CLS (Cumulative Layout Shift) measures visual stability by quantifying unexpected layout shifts during page load

Additional performance metrics provide deeper diagnostic insights:

• FCP (First Contentful Paint) tracks when the first text or image appears on screen
• Speed Index measures how quickly content visually populates during page load
• TBT (Total Blocking Time) quantifies how long the main thread is blocked, preventing user interaction
• TTI (Time to Interactive) indicates when the page becomes fully interactive and responsive

Performance score summarizes overall page speed on a 0-100 scale, with 90-100 considered good, 50-89 needing improvement, and 0-49 poor. This score aggregates multiple metrics with weighted importance to provide a single performance indicator.

Actionable recommendations identify specific optimization opportunities like image compression, render-blocking resource elimination, JavaScript optimization, server response time improvement, and layout stability fixes. These suggestions help you prioritize performance improvements based on their potential impact.

Mobile versus desktop comparison (if testing both) reveals performance differences across devices. Mobile devices typically show slower speeds due to network constraints and processing power limitations, making mobile optimization particularly critical.

Core Web Vitals Explained (With Performance Targets)

Core Web Vitals are Google's standardized metrics for measuring user experience quality, directly impacting search rankings and page experience signals.

LCP (Largest Contentful Paint) measures loading performance by tracking when the largest content element (usually a hero image, video, or large text block) becomes visible within the viewport. This metric reflects perceived loading speed from the user's perspective.

Good threshold: LCP should occur within 2.5 seconds of when the page first starts loading. Between 2.5-4.0 seconds needs improvement. Above 4.0 seconds is considered poor and significantly impacts user experience.

Common causes of slow LCP: Slow server response times, render-blocking CSS or JavaScript, slow resource load times for images or videos, and client-side rendering delays. Optimizing your largest content element's loading priority improves LCP most effectively.

INP (Interaction to Next Paint) measures interactivity and responsiveness by assessing the latency of user interactions throughout the entire page visit. INP tracks all clicks, taps, and keyboard interactions, reporting the longest delay encountered.

Good threshold: INP should be less than 200 milliseconds. Between 200-500 milliseconds needs improvement. Above 500 milliseconds is poor and frustrates users waiting for pages to respond to their actions.

Why Google replaced FID with INP: First Input Delay (FID), the previous interactivity metric, only measured the delay of the first interaction. INP provides a more comprehensive view by tracking all interactions throughout the page lifecycle, better representing overall responsiveness. Google officially replaced FID with INP as a Core Web Vital in March 2024.

Common causes of poor INP: Long JavaScript tasks blocking the main thread, excessive JavaScript execution during interactions, large DOM sizes requiring significant processing time, and third-party scripts monopolizing computational resources. Reducing main thread work improves INP.

CLS (Cumulative Layout Shift) measures visual stability by quantifying unexpected layout shifts during the page's entire lifespan. Layout shifts occur when visible page elements change position after initial rendering, often due to images loading without reserved space or dynamic content insertion.

Good threshold: CLS should be less than 0.1. Between 0.1-0.25 needs improvement. Above 0.25 is poor and creates a frustrating experience where users accidentally click wrong elements as content shifts.

Common causes of CLS: Images and iframes without explicit width/height attributes, dynamically injected content (ads, embeds, pop-ups) without reserved space, web fonts causing text reflow (FOIT/FOUT), and animations triggering layout changes. Reserving space for all page elements eliminates most CLS issues.

Why Core Web Vitals matter for SEO: Google uses Core Web Vitals as ranking signals as part of the page experience update. While these metrics don't outweigh relevance and content quality, they serve as tiebreakers when multiple pages provide similar value. Good Core Web Vitals improve both user experience and search visibility.

Lab Metrics vs Real-User Data (Why Numbers Don't Match)

Understanding the difference between lab testing and field data explains why performance numbers vary across tools and over time.

Lab metrics come from simulated testing in controlled environments. Tools like Lighthouse (which powers Google PageSpeed Insights) run tests using emulated devices with fixed network speeds and processing capabilities. Lab testing provides consistent, reproducible diagnostics useful for development and troubleshooting.

Lab data appears immediately for any URL you test, includes detailed diagnostic information about what's slowing down your page, and remains consistent between tests using the same conditions. However, lab results don't reflect real-world variability in devices, networks, and user conditions.

Field data comes from actual users visiting your site, collected through the Chrome User Experience Report (CrUX). CrUX aggregates anonymized performance data from Chrome users who have opted into usage statistics, providing a 28-day rolling window of real-world performance.

Field data represents actual user experiences across diverse devices, networks, and locations. It shows how your site performs in the real world rather than idealized lab conditions. However, field data requires sufficient traffic volume to be available, updates on a 28-day cycle, and may not reflect very recent performance changes.

Why lab and field numbers differ: Lab tests use specific simulated conditions (like a throttled 4G connection) that may be faster or slower than your average real user. Field data reflects the full range of conditions your actual visitors experience, from fast fiber connections to slow mobile networks, from powerful desktops to budget smartphones.

Performance score variability is normal. Running the same test multiple times produces slightly different scores due to measurement variability, network fluctuations, server load variations, and non-deterministic JavaScript execution timing. Differences of 5-10 points between runs are expected. Focus on trends over multiple tests rather than individual scores.

"No field data available" message appears when CrUX hasn't collected enough real-user samples for your specific URL. This happens for low-traffic pages, new sites, pages blocked from indexing, or sites without sufficient Chrome users. You might see origin-level data (domain-wide averages) even when URL-level data is unavailable.

How to Improve Page Speed (Action Checklist)

Performance optimization requires addressing multiple factors affecting loading speed, interactivity, and visual stability.

Image optimization produces some of the largest performance gains:

• Compress images to reduce file sizes without visible quality loss using tools like TinyPNG or image optimization plugins
• Resize images to match their display dimensions rather than loading oversized files and scaling with CSS
• Use modern formats like WebP or AVIF that provide better compression than JPEG or PNG
• Implement lazy loading for offscreen images so they only load when users scroll near them
• Specify width and height attributes on image tags to prevent CLS during loading

CSS and JavaScript optimization reduces render-blocking resources:

• Minify CSS and JavaScript files to remove whitespace and reduce file sizes
• Defer non-critical JavaScript to prevent blocking initial page rendering
• Remove unused CSS and JavaScript that loads but never executes
• Inline critical CSS needed for above-the-fold content to eliminate render-blocking requests
• Use async or defer attributes on script tags when immediate execution isn't required

Server and hosting improvements accelerate initial response:

• Improve Time to First Byte (TTFB) through faster server processing, database optimization, or upgraded hosting
• Implement caching to serve previously generated pages instantly without server processing
• Use a Content Delivery Network (CDN) to serve assets from locations geographically close to users
• Enable compression (gzip or Brotli) to reduce file transfer sizes
• Optimize backend database queries that slow server response times

Layout stability fixes prevent CLS:

• Reserve space for images, videos, and iframes by specifying width and height attributes
• Allocate space for ads and embeds before they load to prevent content shifting
• Avoid inserting content above existing content unless it's in response to user interaction
• Use font-display: swap or font-display: optional for web fonts to minimize text reflow
• Size animation containers appropriately so animations don't trigger layout shifts

Interactivity improvements enhance INP:

• Break up long JavaScript tasks into smaller chunks to reduce main thread blocking
• Reduce third-party script execution that monopolizes processing time
• Simplify DOM structure to reduce the computational cost of style recalculations and layout operations
• Debounce or throttle expensive event handlers that run frequently
• Use code splitting to load only the JavaScript needed for the current page

Resource prioritization ensures critical content loads first:

• Preload critical resources like fonts, hero images, or essential CSS using link rel=preload
• Preconnect to required third-party origins to establish connections early
• Use priority hints to tell browsers which resources matter most for user experience
• Eliminate unnecessary requests for resources that don't impact above-the-fold content

Tracking progress: Run speed tests before optimization to establish baseline performance, implement improvements one category at a time, rerun tests after each change to measure impact, and focus on optimizations that improve Core Web Vitals most significantly.

Troubleshooting Page Speed Issues

Common performance testing challenges have identifiable causes and practical solutions.

"My score changes every time I run the test"

Cause: Performance testing involves measurement variability, network fluctuations, server load variations, and timing-dependent JavaScript execution. Lab tests simulate conditions that can't be perfectly reproduced, leading to natural score variation.

Solution: This is normal and expected. Run multiple tests and look at average performance rather than single test results. Differences of 5-10 points between runs don't indicate actual performance changes. Focus on trends over time and significant score differences (20+ points) rather than minor fluctuations.

"No field data available for my URL"

Cause: Chrome User Experience Report (CrUX) requires sufficient real-user samples to generate field data. Low-traffic pages, new websites, pages blocked from Google's index, or sites without enough Chrome users show no field data.

Solution: This is common and not necessarily a problem. Check if origin-level data (domain-wide averages) is available even when URL-level data isn't. For new sites, field data appears after accumulating 28 days of traffic from Chrome users. Focus on improving lab metrics while waiting for field data to populate.

"My site is fast but still not ranking well"

Cause: Page speed is one of many ranking factors, not the dominant one. Content relevance, quality, authority, backlinks, and user intent match typically matter more than speed for rankings.

Solution: Speed helps when competing with similar-quality content, but won't overcome poor relevance or low authority. Improve page speed as part of comprehensive SEO strategy rather than expecting it to single-handedly boost rankings. Good Core Web Vitals provide competitive advantage when other factors are equal.

"Desktop is fast but mobile is slow"

Cause: Mobile devices have less processing power, slower networks, and smaller memory compared to desktop computers. Mobile testing also uses network throttling to simulate typical mobile conditions.

Solution: Prioritize mobile optimization since Google uses mobile-first indexing. Focus on reducing JavaScript execution, optimizing images for mobile viewport sizes, minimizing render-blocking resources, and using responsive design that adapts efficiently to smaller screens.

"I fixed issues but my score didn't improve"

Cause: Caching may be serving old versions of resources, changes affected metrics that don't heavily weight the performance score, improvements were minimal compared to remaining issues, or field data hasn't updated yet (28-day window).

Solution: Clear browser cache and test in incognito mode to ensure fresh resources load. Check if Core Web Vitals specifically improved even if overall score didn't change significantly. Allow time for field data to reflect changes. Address the highest-impact issues first rather than minor optimizations.

"Third-party scripts are destroying my performance"

Cause: External scripts for ads, analytics, social media widgets, chat tools, and tracking pixels execute on your page, consuming bandwidth and processing time you can't directly control.

Solution: Audit which third-party scripts are essential and remove unnecessary ones. Load non-critical scripts asynchronously or defer them until after page load. Use facade techniques for heavy embeds (load placeholder until user interaction). Consider self-hosting critical third-party resources. Use tag managers to control when scripts execute.

Frequently Asked Questions

What is a page speed test?

A page speed test measures how quickly a webpage loads and becomes interactive by analyzing performance metrics like loading times, interactivity responsiveness, and visual stability. Speed tests evaluate both simulated lab conditions and real-user experiences, identifying bottlenecks and providing optimization recommendations. These tests help improve user experience and search engine rankings.

What is a good PageSpeed or performance score?

A performance score of 90-100 is considered good, 50-89 needs improvement, and 0-49 is poor. However, focus on Core Web Vitals thresholds rather than just the aggregate score. Good Core Web Vitals (LCP <= 2.5s, INP < 200ms, CLS < 0.1) matter more for user experience and SEO than achieving a perfect 100 score.

What are Core Web Vitals (LCP, INP, CLS)?

Core Web Vitals are Google's standardized metrics for measuring user experience quality: Largest Contentful Paint (LCP) measures loading performance, Interaction to Next Paint (INP) measures interactivity and responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. These metrics directly impact search rankings as part of Google's page experience signals.

What's a good LCP, INP, and CLS score?

Good thresholds are: LCP <= 2.5 seconds, INP < 200 milliseconds, and CLS < 0.1. These targets represent the 75th percentile of user experiences, meaning at least 75% of your users should experience performance at or better than these thresholds. Meeting all three thresholds indicates good overall page experience.

Why did Google replace FID with INP as a Core Web Vital?

First Input Delay (FID) only measured the delay of the very first user interaction on a page, missing responsiveness issues that occurred later. Interaction to Next Paint (INP) measures all interactions throughout the page's lifecycle, providing a more comprehensive view of overall responsiveness. INP officially replaced FID in March 2024 to better represent actual user experience.

Why does my speed score change every time I run the test?

Performance testing involves inherent variability from network conditions, server load, JavaScript execution timing, and measurement limitations. Lab tests simulate conditions that can't be perfectly reproduced. Score fluctuations of 5-10 points between runs are normal. Run multiple tests and focus on trends rather than individual results.

What's the difference between lab metrics and real-user (CrUX) field data?

Lab metrics come from simulated testing in controlled environments using emulated devices and network conditions. Field data comes from actual Chrome users visiting your site, aggregated in the Chrome User Experience Report (CrUX) over 28-day windows. Lab data is available immediately and provides diagnostics, while field data reflects real-world performance but requires sufficient traffic.

Why is no field data showing for my URL?

CrUX requires sufficient real-user samples from Chrome users to generate field data. Low-traffic pages, new websites, or sites without enough Chrome visitors won't have URL-level field data. You might see origin-level data (domain-wide averages) instead. Field data populates after accumulating 28 days of traffic from qualifying Chrome users.

How can I improve LCP on my site?

Improve LCP by optimizing your largest content element's loading: compress and properly size images, use modern image formats like WebP, implement lazy loading for offscreen content, reduce server response time (TTFB), eliminate render-blocking CSS and JavaScript, use a CDN for faster asset delivery, and preload critical resources like hero images or web fonts.

What causes CLS and how do I fix it?

CLS is caused by layout shifts from images/iframes without dimensions, dynamically inserted content (ads, embeds), web fonts causing text reflow, and animations triggering layout changes. Fix CLS by setting explicit width and height attributes on all images and iframes, reserving space for ads and dynamic content, using font-display properties, and avoiding inserting content above existing content.

Does page speed affect SEO rankings?

Yes, page speed affects rankings as part of Google's page experience signals. Google's Speed Update made speed a ranking factor for mobile searches, and Core Web Vitals contribute to ranking systems. However, speed is one factor among many, typically serving as a tiebreaker when content quality and relevance are similar. Good speed won't overcome poor content, but it provides competitive advantage.

How often should I run page speed tests?

Run speed tests after making significant changes to your site (design updates, new plugins, hosting changes), when implementing performance optimizations to measure impact, and periodically (monthly or quarterly) as part of routine site maintenance. More frequent testing during active optimization helps track progress and validate improvements.