Gather end-user browser performance data.
Weasel gathers browser performance data, e.g. navigation and resource timings, and sends it via beacons to an API endpoint. Weasel itself is the in-browser part. This means that it runs in the browsers of of websites and web applications users. This is typically called end-user monitoring (EUM).
Weasel takes a different approach than other popular EUM solutions, e.g. Boomerang. It restricts itself to the most important, efficiently collectible data points that are necessary to understand…
By design, this means that Weasel won't include all the metrics that tools such as Boomerang provide. This is because there are very many tools nowadays in use and available to engineers that can provide highly granular inspection from that point on, e.g. browser developer tools and WebPageTest. Weasel provides everything engineers needs in order to identify and start a first problem analysis without incurring an impact on monitored websites.
Features are categorized into beacon types that weasel is able to emit. Currently, it supports multiple beacon type:
window.onload
) event has fired. It includes various information, e.g. the API token, navigation and resource timings, first paint time and configurable meta data.XMLHttpRequest
s and fetch
sUsage of Weasel is different than that of many other libraries. Technically, this is because of its lack of a plugin system and compilation modes. This was done with a drastic users first design in mind (this means developers later). Weasel is shipped to a huge number of users on a variety of websites. As a result, its size and impact on the monitored websites must be minimal. To achieve this, Weasel does not include a plugin system or any optional code paths. Weasel is compiled using Rollup enabled tree shaking followed by Google Closure Compiler advanced mode compilation.
This being said, how would you go about using Weasel? We recommend the following way to adapt and use Weasel:
Fork Weasel. Yes, really. The lack of a plugin system and the desire to remove optional code paths means that some things just aren't configurable. But don't worry about pulling improvements from upstream: The kind of changes that you have to make in your fork are pretty small.
Update the following files within your fork as you see fit:
Install the necessary dependencies and build weasel:
yarn
yarn build
The files within target/
are the result of the build process. Serve these in whatever way you see fit. You want these to be accessible by (end-) users.
Load Weasel on a website by embedding the following script tag. Take note of and replace the placeholders within this snippet!
<script>
(function(i,s,o,g,r,a,m){i['{{vars.nameOfLongGlobal}}']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','{{urlToRetrieveWeaselFrom}}','{{nameOfShortGlobal}}');
ineum('reportingUrl', '{{urlToSendBeaconsTo}}');
ineum('apiKey', '{{optionalApiToken}}');
</script>
Accept the data on the server side. Weasel will send data either as HTTP GET
requests with data being stored in query parameters, or as HTTP POST
requests with data being available as the request body encoded as application/x-www-form-urlencoded
(whether GET
or POST
is used depends on the amount of data). The data format is described in lib/types.ts.
Let us know about how you are using Weasel! This will help us get a better understanding for the community and the impact that our changes will have.
Keep your fork up-to-date by periodically pulling from upstream.
Have a great day ☀️!
Please check for complete documentation in the Website monitoring documentation.