Simulate Lighthouse-style Performance scores using device and network presets. Explore how JavaScript weight, image size, third-party scripts, and CPU throttling affect LCP, INP, TBT, FCP, and CLS - no server, no real audit required, purely for planning and education.
Simulate Lighthouse-like Performance scores with device and network presets. Frontend-only approximation for planning and education.
Start a simulation to see statistics
Run the simulator to see trend charts
No simulation results yet
Enter a URL, configure presets, and start the simulator
5 Metrics Modeled
LCP, INP, TBT, FCP, and CLS
Custom Weighting
Adjust each metric's influence on the score
5 Network Presets
Slow 4G through no throttling
100% Client-Side
No real page is fetched or audited
This tool provides a frontend-only approximation of Google Lighthouse Performance scoring. It generates synthetic lab metrics based on the device, network throttling, and page-complexity parameters you configure, then combines them using a weighted scoring model that mirrors the structure Lighthouse itself uses.
Unlike a real Lighthouse audit - which loads your actual page in a headless Chrome instance and measures real rendering, script execution, and layout behavior - this simulator never fetches or renders your URL at all. It uses your page-complexity sliders (JavaScript weight, image weight, third-party request count, animation load, and CPU slowdown) as inputs to a heuristic formula, then adds randomized jitter across runs to illustrate how real-world performance scores vary from one test to the next even on an unchanged page.
Use it to explore relationships - "what happens to my estimated score if I cut JavaScript in half?" - and to build intuition about which levers matter most, before spending time running a full Lighthouse audit or PageSpeed Insights report against your real, deployed page.
It's important to be direct about what this tool is and isn't. The scores here are synthetic estimates, generated from a simplified heuristic model - they are not measured by rendering your actual page, and they will not match what Lighthouse, PageSpeed Insights, or Chrome DevTools report for a real URL.
Google's three Core Web Vitals - Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift - remain the field-data metrics Google uses to judge real-world page experience. A page passes Core Web Vitals only when at least 75% of real visits, measured over a rolling 28-day window in the Chrome User Experience Report (CrUX), meet the "good" threshold for all three metrics simultaneously.
| Metric | Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | Loading speed - when the main content finishes rendering | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | Responsiveness - latency of all page interactions | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | Visual stability - unexpected layout movement | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
INP officially replaced First Input Delay (FID) as the responsiveness metric in March 2024 and remains in place in 2026. Where FID only measured the delay before the very first interaction, INP evaluates the full latency of every interaction across the page's lifetime, making it a considerably stricter and more representative test - and, per recent field data, the Core Web Vital most sites currently fail.
Core Web Vitals are a confirmed ranking signal, but function primarily as a tie-breaker between pages of otherwise similar relevance and quality - not a factor that overrides strong content. Their larger, better-documented impact is on conversion: faster, more stable pages measurably reduce bounce rate and improve engagement independent of any SEO effect.
Marks the moment the first piece of DOM content - text, an image, a canvas element - is painted on screen. It's a lab-only metric (not a Core Web Vital used in ranking) but remains part of the Lighthouse Performance score, contributing early signal about perceived load speed before LCP fires.
Sums the time the main thread was blocked by long tasks (over 50ms) between FCP and Time to Interactive, during which the page can't respond to user input. TBT is a lab proxy for real-world responsiveness and correlates closely with INP - reducing TBT is usually the most direct way to improve INP.
Even a real Lighthouse audit only produces lab data - a single test run in a controlled environment. Google's ranking-relevant Core Web Vitals assessment is based on field data from the Chrome UX Report: real measurements from real Chrome users on real devices and networks, aggregated at the 75th percentile over 28 days.
A perfect Lighthouse score on your development machine means little if a quarter or more of your real visitors - often on mid-range phones or slower connections - experience something much worse. This is exactly why this simulator lets you explore multiple device and throttling scenarios rather than showing a single fixed number: real-world performance is a distribution, not a point estimate.
No. It never fetches or renders your URL. The URL field is for labeling your results only - every metric is generated from the sliders you set (JS size, image weight, third parties, CPU slowdown) using a simplified heuristic formula.
Each run applies randomized jitter around the baseline values calculated from your settings, to illustrate the kind of run-to-run variability seen in real performance testing. It's a deliberate simulation feature, not measurement noise.
No - treat it as a planning and education tool for building intuition about which factors matter most. For an authoritative score on a real page, use Lighthouse in Chrome DevTools, PageSpeed Insights, or the CrUX field data in Google Search Console.
The default weights (FCP 10, LCP 25, INP 20, TBT 30, CLS 15) are a simplified approximation loosely modeled on the general emphasis Lighthouse places on responsiveness and loading metrics - not an exact reproduction of Lighthouse's actual, more complex scoring curves.
INP measures every interaction on the page, not just the first one, so fixing it usually requires broad JavaScript architecture changes - breaking up long tasks and reducing main-thread work throughout the page's lifetime - rather than a single targeted fix.
No. All calculations happen in your browser using JavaScript. The only data leaving your device is if you choose to export your results as a JSON file, which downloads directly to your computer.
Chrome Lighthouse audits a loaded web page across performance, accessibility, best practices, SEO, and other categories. This page does not fetch the URL you enter or run Chrome Lighthouse. Instead, it models performance-like results from your chosen device, network, JavaScript, image, third-party, animation, and CPU settings. Use it to compare design decisions before validating a deployed page with a real Lighthouse or PageSpeed Insights run.
The model includes FCP, LCP, INP, Total Blocking Time, and CLS. LCP, INP, and CLS are Core Web Vitals; they describe different aspects of loading, responsiveness, and layout stability. A synthetic score is useful for comparison, but it cannot replace field data or a real browser audit because real results depend on the rendered page, server response, cache state, device, and network.
Change one input at a time and compare several runs. A large image budget is a reason to investigate responsive images, dimensions, modern formats, and the page’s largest visual element. A large JavaScript or CPU setting is a reason to inspect client bundles, long tasks, and third-party code. A high animation setting is a prompt to test layout stability and interaction work. The simulator helps decide where to look; it does not diagnose the shipped application for you.
After choosing a likely improvement, build or deploy the real page, run Lighthouse under a defined device and network setting, and record the result. Then repeat with the isolated change. Chrome describes Lighthouse as an automated audit of a supplied page; its real report covers more than this model, including accessibility, best-practices, and SEO checks. Treat the score as one signal alongside user experience and field monitoring.
First Contentful Paint (FCP) is an early indication that content has appeared. Largest Contentful Paint (LCP) focuses on the largest meaningful element in the viewport, often a hero image or primary text block.
Interaction to Next Paint (INP) reflects how quickly the page responds visually to user interaction. Total Blocking Time (TBT) is a lab metric that helps expose long main-thread tasks. Cumulative Layout Shift (CLS) measures unexpected movement, which is commonly reduced by reserving media space and avoiding late layout changes.
Yes. It is free to use without registration.
No. The URL is only a label for your scenario and is not fetched by this browser-only simulator.
It estimates Lighthouse-like performance metrics from your selected device, network, and page-complexity settings.
Yes. It works in modern mobile browsers.
No. Confirm important changes with a real Lighthouse report and production monitoring.
Discover more free developer tools that might interest you.
Resolve an IPv4 address to its reverse DNS PTR hostname
Use ToolLook up DNS records for domains
Use ToolConvert domain names to IP addresses
Use ToolView HTTP headers for websites
Use ToolTest network connectivity and latency
Use ToolCheck SSL certificate details and validity
Use ToolRead the how-to, then come back to this tool when you are ready to run it locally.