Canarytrace Smoke Pro automatically run Lighthouse on every URL and lhr object stored to Elasticsearch. Canarytrace Professional run Lighthouse at any time and on any tested site.
Result of Performance Audit (lhr object) stored to
An object containing the results of the audits, keyed by their name.
first-contentful-painthttps://web.dev/first-contentful-paint/ First Contentful Paint (FCP) is one of six metrics tracked in the Performance section of the Lighthouse report. Each metric captures some aspect of page load speed.
largest-contentful-painthttps://web.dev/lcp/ Largest Contentful Paint (LCP) is an important, user-centric metric for measuring perceived load speed because it marks the point in the page load timeline when the page's main content has likely loaded—a fast LCP helps reassure the user that the page is useful.
speed-indexhttps://web.dev/speed-index/ Speed Index measures how quickly content is visually displayed during page load. Lighthouse first captures a video of the page loading in the browser and computes the visual progression between frames. Lighthouse then uses the Speedline Node.js module to generate the Speed Index score.
first-meaningful-painthttps://web.dev/first-meaningful-paint/ DEPRECATED FMP measures when the primary content of a page is visible to the user. The raw score for FMP is the time in seconds between the user initiating the page load and the page rendering the primary above-the-fold content. FMP essentially shows the timing of the paint after which the biggest above-the-fold layout change happens. Learn more about the technical details of FMP in Google's Time to First Meaningful Paint: a layout-based approach.
estimated-input-latencyhttps://web.dev/estimated-input-latency/ Estimated Input Latency is an estimate of how long your app takes to respond to user input during the busiest 5 second window of page load. The timing of this audit is from First Meaningful Paint to the end of the trace, which is roughly 5 seconds after Time to Interactive. If your latency is higher than 50 ms, users may perceive your app as laggy.
total-blocking-timehttps://web.dev/tbt/ The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.
max-potential-fidhttps://web.dev/lighthouse-max-potential-fid/ Max Potential FID measures the worst-case First Input Delay that your users might experience. First Input Delay measures the time from when a user first interacts with your site, such as clicking a button, to the time when the browser is actually able to respond to that interaction.
cumulative-layout-shifthttps://web.dev/cls/ CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. A layout shift occurs any time a visible element changes its position from one rendered frame to the next. (See below for details on how individual layout shift scores are calculated.)
server-response-timehttps://web.dev/time-to-first-byte/ This audit fails when the browser waits more than 600 ms for the server to respond to the main document request. Users dislike when pages take a long time to load. Slow server response times are one possible cause for long page loads. When users navigate to a URL in their web browser, the browser makes a network request to fetch that content. Your server receives the request and returns the page content.
first-cpu-idlehttps://web.dev/first-cpu-idle/ DEPRECATED First CPU Idle measures how long it takes a page to become minimally interactive.
interactivehttps://web.dev/interactive/ Measuring TTI is important because some sites optimize content visibility at the expense of interactivity. This can create a frustrating user experience: the site appears to be ready, but when the user tries to interact with it, nothing happens.
critical-request-chainshttps://web.dev/critical-request-chains/ Critical request chains are series of dependent network requests important for page rendering. The greater the length of the chains and the larger the download sizes, the more significant the impact on page load performance.
redirectshttps://web.dev/redirects/ Redirects slow down your page load speed.
uses-rel-preloadhttps://web.dev/uses-rel-preload/ Potential savings ms. Prioritize fetching resources that are currently requested later in page load.
uses-rel-preconnecthttps://web.dev/uses-rel-preconnect/ Potential savings ms. Prioritize fetching resources that are currently requested later in page load.
network-rttRound-trip time (RTT) is the duration in milliseconds (ms) it takes for a network request to go from a starting point to a destination and back again to the starting point. RTT is an important metric in determining the health of a connection on a local network or the larger Internet, and is commonly utilized by network administrators to diagnose the speed and reliability of network connections.
third-party-summaryhttps://web.dev/third-party-summary/ A third-party script is any script hosted on a domain that's different than the domain of the URL that you audited with Lighthouse. As the page loads, Lighthouse calculates how long each of the third-party scripts blocks the main thread. If the total blocking time is greater than 250 ms the audit fails.
non-composited-animationshttps://web.dev/non-composited-animations/ Non-composited animations can appear janky (i.e. not smooth) on low-end phones or when performance-heavy tasks are running on the main thread. Janky animations can increase the Cumulative Layout Shift (CLS) of your page. Reducing CLS will improve your Lighthouse Performance score.
unsized-imageshttps://web.dev/optimize-cls/?utm_source=lighthouse&utm_medium=node#images-without-dimensions Image elements do not have explicit width and height. Set an explicit width and height on image elements to reduce layout shifts and improve CLS.
uses-long-cache-ttlhttps://web.dev/uses-long-cache-ttl/ When a browser requests a resource, the server providing the resource can tell the browser how long it should temporarily store or cache the resource. For any subsequent request for that resource, the browser uses its local copy rather than getting it from the network.
offscreen-imagehttps://web.dev/offscreen-images/ Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive. Learn more.
render-blocking-resourceshttps://web.dev/render-blocking-resources/ The Opportunities section of your Lighthouse report lists all URLs blocking the first paint of your page. The goal is to reduce the impact of these render-blocking URLs by inlining critical resources, deferring non-critical resources, and removing anything unused.
unminified-csshttps://web.dev/unminified-css/ Minifying CSS files can improve your page load performance. CSS files are often larger than they need to be.
unused-css-ruleshttps://web.dev/unused-css-rules Remove unused CSS.
uses-webp-imageshttps://web.dev/serve-images-webp/ WebP images are smaller than their JPEG and PNG counterparts—usually on the magnitude of a 25–35% reduction in filesize. This decreases page sizes and improves performance. Example: https://twitter.com/RDPanek/status/1340918791279132672
uses-optimized-imageshttps://web.dev/uses-optimized-images/#optimize-images-using-gui-tools Lists all unoptimized images, with potential savings in kibibytes (KiB).
uses-text-compressionhttps://web.dev/uses-text-compression/ Text-based resources should be served with compression to minimize total network bytes.
uses-responsive-imageshttps://web.dev/uses-responsive-images/ Lists all images in your page that aren't appropriately sized, along with the potential savings in kibibytes (KiB).
efficient-animated-contenthttps://web.dev/efficient-animated-content/ Lists all animated GIFs, along with estimated savings in seconds achieved by converting GIFs to video format. Large GIFs are inefficient for delivering animated content.
dom-sizehttps://web.dev/dom-size/ A large DOM tree can slow down your page performance.
no-document-writehttps://web.dev/no-document-write/ For users on slow connections, external scripts dynamically injected via
document.write()can delay page load by tens of seconds.
uses-http2https://web.dev/uses-http2/ HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push.
uses-passive-event-listenershttps://web.dev/uses-passive-event-listeners/ Consider marking your touch and wheel event listeners as
passiveto improve your page's scroll performance.
You can visit our visual documentation with all dashboards.