Legacy JavaScript

Silktide checks whether your page ships extra code whose only purpose is to support very old browsers. Modern browsers don't need it, so for almost every visitor it is wasted download and processing time.

When is prepared for publishing, build tools often add polyfills (substitutes for features old browsers lack) and transforms (rewrites of modern syntax into older equivalents). Configured for browsers that have essentially disappeared, they can add substantial dead weight to every page load.

Why this matters

The overwhelming majority of visitors use browsers that update themselves and support modern JavaScript natively. Legacy support code makes them all pay - in download time, mobile data, and processing time - for compatibility with browsers that may account for none of your actual traffic.

The cost is easy to miss because nothing looks wrong: the site works everywhere. It is simply slower than it needs to be, on every page, for everyone.

How to fix it

This is a build configuration fix for your developers:

Set the build's browser support targets to the browsers your visitors actually use, rather than a legacy default that has drifted out of date. Most build tools read this from a browser support declaration in the project.
Remove blanket polyfill imports that pull in support for everything, and let the build include only what your targets genuinely need.
If some legacy browser must still be supported, serve two builds - a modern one for current browsers and a legacy one only for browsers that need it - instead of sending the legacy build to everyone.

How Silktide tests this

Load the page in a real browser, using the device type, connection speed, and test location configured for your speed tests.
Examine the JavaScript the page downloads for known polyfills and syntax transforms that modern browsers do not need.
Report each file containing legacy code, with the download size that could be saved.
Grade the page by the total wasted size: around 30 KB of legacy code is graded down, and 100 KB or more is graded as poor.

Troubleshooting

We still need to support old browsers

Ask whether your visitors actually use them - your analytics will tell you. If some genuinely do, the module/nomodule pattern lets you serve legacy code only to the browsers that need it, so modern browsers stop paying the cost.

The legacy code is in a third-party script

Scripts from other providers can carry their own legacy padding, which you cannot rebuild. Check whether the provider offers a modern build, and weigh the script's value against its cost.