This article explains how we analysed the web performance of our website overlay, which is a plugin of our JavaScript tracker.
At Ometria all of our features, including website overlay, are built with web performance in mind.
From prototyping the concepts to releasing our features, Ometria’s Engineers are passionate about web performance.
Every additional update to website overlay has been measured and analysed with various web performance tools, such as Google's open-source tool Lighthouse, which measures the core web vitals metrics.
How we built website overlays
The website overlay feature was written using native DOM JavaScript methods with no third-party package requirements or libraries.
This translates to a significantly reduced amount of JavaScript code required compared to using libraries.
Furthermore, using native JavaScript methods increases website performance, as these native functions and methods are generally a lot faster compared to the ones belonging to a library or framework.
Our overlays load after the page has been loaded (after the OnLoad
event):
Metrics and scoring
Using the latest Chrome browser version of Lighthouse - Version 91.0.4472.114 (Official Build) (arm64) - with the default settings (simulated throttling and clear storage) on an Apple Macbook M1 (16 GB, macOS Big Sur version 11.1), we ran Lighthouse reports using the browser extension on an internal testing online store, loading our JavaScript tracker including the website overlay plugin, and tested the impact.
The metrics reassured us that the plugin is web performant.
Before loading the overlay
After loading the overlay
We can clearly see that the impact on web performance is minimal.
Find out how metric stores are determined.
Metric | Description |
First Contentful Paint (FCP) |
Measures how long it takes the browser to render the first piece of content from the DOM. This is a very important user-centric metric for measuring page load speed. It also provides the first feedback to the user that the page is actually loading. |
Speed Index | Reflects how quickly the visual content is available during page load. |
Large Contentful Paint (LCP) |
Measures loading performance. A good user experience would be 2.5 seconds LCP from when the page starts loading. |
Time To Interactive (TTI) |
Measures how long it takes a web page to become interactive. That point is defined when the page has displayed useful content, the registration of event handlers for the most visible page elements is complete and the page is ready to fully respond to user interactions. |
Total Blocking Time (TBT) |
Reflects the total amount of time between the First Contentful Paint (FCP) and Time To Interactive (TTI) where the main thread was blocked, preventing input responsiveness. |
Cumulative Layout Shift (CLS) |
Measures visual stability. This is the number of times visible web page elements (fonts, images etc.) changing their position causes a web page layout shift. |
Further reading
- https://developers.google.com/web/tools/lighthouse
- https://web.dev/performance-scoring
- https://web.dev/lighthouse-performance
- https://web.dev/vitals/#core-web-vitals
Comments
0 comments
Article is closed for comments.