Boost Your Site Speed: Put Scripts on a Diet with Service Workers
3 min read
Building modern web applications is no less complicated than writing a thesis. There was a time when we could just spin up an ec2 instance and put our static html, css and little bit of Javascript (Yes, using javascript instead of TS was not really a crime back then) but we are past that era. For a single page website with zero to little client interactivity, we tend to rely on meta frameworks like Next.js. Next.js is a great framework but it can be a terrible choice if you are using it for a marketing landing page or even your personal blog.
Meta frameworks like Next.js need to download a whole lot of javascript to make your website interactive which is terrible for Time to Interactive (TTI) web vital.
Those scripts weren’t enough, now you also have third party scripts, maybe from the google analytics, or hubspot, or your designers want to see whether their over engineered ui features getting enough tractions with hotjar. Third party scripts are necessary but you should always remember there’s only so much you could process with a single thread.
But here’s a catch:
JS is single threaded but the underlying engine that transpiles the javascript language supports multi threading. and thats when the service workers (or web workers) come into the picture.
Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface.
Let’s Understand how these web workers can help us get what we want, the performance:
- A way to put all the third party scripts into a separate thread, not the main thread.
- A consensus to make sure not third party script gets executed in our main thread, cause that’s for our main application.
This is where Builder.io’s partytown come into the picture. (Currently in BETA)
So what does partytime do and how does it do?
- Partytown creates a messaging protocol between the service workers and main thread running in browser for workers to have synchronous/async access to all the browser specific things such as DOM APIs, localstorage etc.
- It does so by leveraging proxies, sync XHR Requests,
- you don’t need to rewrite or refactor your third-party scripts to make them work within web workers. They’re executed exactly as coded; they just work from the background thread.
By putting all these third party scripts into service workers thread, we are saving so much for our main thread and this is directly resulting in best ever web vitals score.