You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement related to a problem? Please describe.
Third-party scripts are a pain - the solutions are few and far between, and those that do exist are not pretty - so lets explore some:
Service Workers
Service Workers can be a valuable tool for caching assets more aggressively and accessibly than the server can. As all sites run on HTTPS these days (one of the prerequisites for service workers) - we can largely depend on the functionality. Service workers can be used for speedy response times for assets commonly requested on sites.
Serving third-party scripts and assets via CDN is still slower than serving from your server. Using a Service Worker, we can aggressively cache assets that are unlikely to change often: fonts, CSS, js, images, etc.
Google has a great library known as WorkBox that abstracts Service Worker implementation.
Workbox comes with recipes, which are snippets that can be used for everyday tasks that engineers might want to implement; some example could be:
Precaching/prefetching important URL's in the navigation of the site
Caching entire pages
Caching static resources like CSS, js, fonts, images, etc.
Caching Google fonts
Self Hosting
Even though service workers are a form of self-hosting, they're far more dynamic than actual self-hosting. One technique to reduce the latency of third-party scripts is to self-host third-party scripts, removing the network activity needed to actually request the asset before it executes.
However, there are plenty of case studies that show major benefits.
This ticket is to potentially explore the pro's and cons of both techniques to see if we can alleviate some of the stress caused by third-party scripts.
Designs
N/A
Describe alternatives you've considered
N/A
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Is your enhancement related to a problem? Please describe.
Third-party scripts are a pain - the solutions are few and far between, and those that do exist are not pretty - so lets explore some:
Service Workers
Service Workers can be a valuable tool for caching assets more aggressively and accessibly than the server can. As all sites run on HTTPS these days (one of the prerequisites for service workers) - we can largely depend on the functionality. Service workers can be used for speedy response times for assets commonly requested on sites.
Serving third-party scripts and assets via CDN is still slower than serving from your server. Using a Service Worker, we can aggressively cache assets that are unlikely to change often: fonts, CSS, js, images, etc.
Google has a great library known as WorkBox that abstracts Service Worker implementation.
Workbox comes with recipes, which are snippets that can be used for everyday tasks that engineers might want to implement; some example could be:
Self Hosting
Even though service workers are a form of self-hosting, they're far more dynamic than actual self-hosting. One technique to reduce the latency of third-party scripts is to self-host third-party scripts, removing the network activity needed to actually request the asset before it executes.
There has been advice issued lately regarding the benefits of self-hosting third-party scripts: https://web.dev/efficiently-load-third-party-javascript/#self-host-third-party-scripts - however it has generally been frowned upon because end users might not get the latest updates of a script in question. This is a fair argument, of course.
However, there are plenty of case studies that show major benefits.
This ticket is to potentially explore the pro's and cons of both techniques to see if we can alleviate some of the stress caused by third-party scripts.
Designs
N/A
Describe alternatives you've considered
N/A
Code of Conduct
The text was updated successfully, but these errors were encountered: