- What is Performance Audit
- What metrics are stored in a Elasticsearch
- What is a form factor
Performance audit is available in Canarytrace Pro edition
If you use Canarytrace Pro in
user-journey mode, you can run performance audit on every page via
formFactoris emulation performance profile ( e.g. desktop or mobile )
Canarytrace send result of performance audit into Elasticsearch into
c.audit-* index. Read below for more information and a description of metrics.
Lighthouse HTML report
Canarytraces save full Lighthouse HTML report.
- open example HTML report: 03bbc6dac05072c42859-0f920da3db03fefb7cae-lighthouse-report.html
Canarytrace records of activity in Chrome's processes for the Trace Event Profiling Tool
- download JSON example: 03bbc6dac05072c42859-0f920da3db03fefb7cae-traces.json
chrome://tracingin your Google Chrome and click on Load button.
Result of performance audit is stored into
c.audit-* index and contains many metrics, opportunities a diagnostics information.
performance.score In general, only metrics contribute to your Lighthouse Performance score, not the results of Opportunities or Diagnostics. https://web.dev/performance-scoring/
first-contentful-paintFirst 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. https://web.dev/first-contentful-paint/
speed-indexSpeed 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. https://web.dev/speed-index/
interactiveMeasuring 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. https://web.dev/interactive/
total-blocking-timeThe 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. https://web.dev/tbt/
largest-contentful-paintLargest 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. https://web.dev/lcp/
cumulative-layout-shiftCLS 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. https://web.dev/cls/
Total Blocking Time30%
Largest Contentful Paint25%
Cumulative Layout Shift15%
First Contentful Paint10%
Time to Interactive10%
max-potential-fidMax 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. https://web.dev/lighthouse-max-potential-fid/
first-meaningful-paintFMP 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. https://web.dev/first-meaningful-paint/
- This metric is deprecated in Lighthouse 6.0
server-response-timeThis 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. https://web.dev/time-to-first-byte/
critical-request-chainsCritical 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. https://web.dev/critical-request-chains/
redirectsRedirects slow down your page load speed. https://web.dev/redirects/
uses-rel-preloadPotential savings ms. Prioritize fetching resources that are currently requested later in page load. https://web.dev/uses-rel-preload/
uses-rel-preconnectPotential savings ms. Prioritize fetching resources that are currently requested later in page load. https://web.dev/uses-rel-preconnect/
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-summaryA 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. https://web.dev/third-party-summary/
non-composited-animationsNon-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. https://web.dev/non-composited-animations/
unsized-imagesImage elements do not have explicit width and height. Set an explicit width and height on image elements to reduce layout shifts and improve CLS. https://web.dev/optimize-cls/?utm_source=lighthouse&utm_medium=node#images-without-dimensions
uses-long-cache-ttlWhen 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. https://web.dev/uses-long-cache-ttl/
offscreen-imageConsider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive. https://web.dev/offscreen-images/
render-blocking-resourcesThe 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. https://web.dev/render-blocking-resources/
unminified-cssMinifying CSS files can improve your page load performance. CSS files are often larger than they need to be. https://web.dev/unminified-css/
unused-css-rulesRemove unused CSS. https://web.dev/unused-css-rules
uses-optimized-imagesLists all unoptimized images, with potential savings in kibibytes (KiB). https://web.dev/uses-optimized-images/#optimize-images-using-gui-tools
uses-text-compressionText-based resources should be served with compression to minimize total network bytes. https://web.dev/uses-text-compression/
uses-responsive-imagesLists all images in your page that aren't appropriately sized, along with the potential savings in kibibytes (KiB). https://web.dev/uses-responsive-images/
efficient-animated-contentLists all animated GIFs, along with estimated savings in seconds achieved by converting GIFs to video format. Large GIFs are inefficient for delivering animated content. https://web.dev/efficient-animated-content/
dom-sizeA large DOM tree can slow down your page performance. https://web.dev/dom-size/
no-document-writeFor users on slow connections, external scripts dynamically injected via
document.write()can delay page load by tens of seconds. https://web.dev/no-document-write/
uses-http2HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push. https://web.dev/uses-http2/
uses-passive-event-listenersConsider marking your touch and wheel event listeners as
passiveto improve your page's scroll performance. https://web.dev/uses-passive-event-listeners/
resource-summaryKeep request counts low and transfer sizes small
font-displayAll text remains visible during webfont loads. https://web.dev/font-display/
total-byte-weightAvoids enormous network payloads. https://web.dev/total-byte-weight/
modern-image-formatsServe images in next-gen formats. https://web.dev/uses-webp-images/
network-server-latencyServer Backend Latencies. https://web.dev/time-to-first-byte/
third-party-facadesLazy load third-party resources with facades. https://web.dev/third-party-facades/
maxWaitForFcpWait on render the first piece of DOM content.
maxWaitForLoadWait on full load page.
formFactorDetermines how performance metrics are scored. You can set performance profile for desktop or mobile.
throttling.rttMsControls simulated network RTT (TCP layer).
throttling.throughputKbpsControls simulated network download throughput.
throttling.requestLatencyMsControls emulated network RTT (HTTP layer).
throttling.downloadThroughputKbpsControls emulated network download throughput.
throttling.uploadThroughputKbpsControls emulated network upload throughput.
throttling.cpuSlowdownMultiplierControls simulated + emulated CPU throttling.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4420.0 Safari/537.36 Chrome-Lighthouse
lighthouseReport- name of HTML Lighthouse report, e.g.
traceReport- records of activity in Chrome's processes for the Trace Event Profiling Tool e.g.
Trace Event Profiling Tool But there’s a lot that DevTools can’t tell you.
requestedUrlis entered url and
finalUrlis url after last redirect. They usually are the same.
uuidActionis unique id for test step / for
itmethod. This is useful for searching in Kibana. The same uuidAction is stored in other Elasticsearch indices, so by this uuidAction is possible pairing data from
uuidis unique id of one running instance of Canarytrace runner. This same uuid is stored in other Elasticsearch indices, so by this uuid is possible pairing data from c.report index and from c.audit index.
timestampTime stamp when the audit was performed.
preload-lcp-imagePreloading the Largest Contentful Paint (LCP) image can display your hero image or website banner much earlier in the page load. https://gtmetrix.com/preload-largest-contentful-paint-image.html
Canarytrace has build-in latest version of Lighthouse and you can set behavior of Lighthouse via environment variables. If you use smoke mode, the Lighthouse will be launched automatically for each landing page.
allowfor run performance audit / Lighthouse
PT_AUDIT_LOG_LEVELavailable options are
verbose. Default is
90000in ms and default value is
90000in ms and default value is
PT_AUDIT_THROTTLINGis formFactor and has available options
desktopDense4G. Default is
Conditions for generate report
You can generate reports (Lighthouse HTML report and Trace records) only if any of the metrics has a low score. E.g. generate report if metric
total-blocking-time has score lower than 50%. Available metrics:
total-blocking-timefor Total Blocking Time (TBT)
first-contentful-paintfor First Contentful Paint (FCP)
largest-contentful-paintfor Largest Contentful Paint (LCP)
cumulative-layout-shiftfor Cumulative Layout Shift (CLS)
speed-indexfor Speed Index (SI)
interactivefor Time to Interactive (TTI)
And how to use:
If you use option
PT_AUDIT_TRACE or both, generated reports will be printed to logs after end of the run.
You can run multiple instances of Canarytrace and via option
PT_AUDIT_THROTTLING set different formFactor for each of them. This is useful for create work load model by your production profile and by devices used your clients.
Simulated throttling, which Lighthouse uses by default, uses a simulation of a page load, based on the data observed in the initial unthrottled load. This approach makes it both very fast and deterministic.
Lighthouse will be run with this configuration
Lighthouse will be run with this configuration
Lighthouse will be run with this configuration
Unlike network throttling where objective criteria like RTT and throughput allow targeting of a specific environment, CPU throttling is expressed relative to the performance of the host device. This poses challenges to variability in results across devices and this is reason, why Canarytrace measures in a closed environment with fixed resources for each run.
Canarytrace set resource for
benchmarkIndex around 1.600
|-||High-End Desktop||Low-End Desktop||High-End Mobile||Mid-Tier Mobile||Low-End Mobile|
|Example Device||16" Macbook Pro||Intel NUC i3||Samsung S10||Moto G4||Samsung Galaxy J2|
You can visit our visual documentation with all dashboards.
- Architecture https://github.com/GoogleChrome/lighthouse/blob/4d3bda1f14540266eb37f7e2ba8cabbc668db11d/docs/architecture.md
- Metrics https://web.dev/lighthouse-performance/#metrics
- Lighthouse Scoring Calculator https://googlechrome.github.io/lighthouse/scorecalc/