tips

Tip 014 - Loading JS

Nowadays, your sites and projects are going to have JavaScript on them. It's pretty unavoidable. This is not necessarily a problem - we just need to make sure that we are shipping JS quickly and responsibly.

You've probably seen this said in many other places, but byte for byte, JS is the heaviest resource on a web page. An image loads in and is simply displayed. CSS loads in and is applied almost instantly. JS loads in, and then not only needs time for the browser to parse it and run it, but this usually takes longer than it took to download and doesn't even start until the download is finished.

So what can be done? There's a lot of strategies out there, here's a couple:

Preloading

<link rel="preload" href="app.js" as="script">

This isn't so helpful with initial page load, but if you know something will need to be downloaded later, this is invaluable. This technique also works with CSS files, images, fonts, and more. If a script is already preloaded, then when it's called for, you essentially skip the download step and go straight to the parsing and running phase.

Service Workers

By registering a service worker, you can take a ton of processing power off the one main thread that JavaScript has to work with. By running some or all the code alongside the page, you can take those loading times waaaay down. Is there ever a time where you shouldn't use service workers? Das Surma says:

You should always use Web Workers.

Well, you heard him. From what I understand, really the only thing that shouldn't be handled by a service worker is the UI stuff, the stuff that you actually see and can click on right away.

Cut back on 3rd parties

This is the worst offender. All those analytics scripts, tracking scripts, ad scripts, developer convenience scripts, UI scripts, routing scripts, and goodness knows what extensions and add-ons the client actually has running. Evaluate what you're using and see if they're necessary. They might be doing something light enough you can do it yourself with vanilla JS (in a service worker for bonus points), or they might even (hear me out here) be doing literally nothing. Shaving off some of these can go a long way to getting that unresponsive-site time down.

Less JS

No that's not the name of a new framework. This depends on so many things about your project and how it works, so this is very subjective, but just cutting back on the actual JS you write will be beneficial for both the load time and the parsing time. By learning about the inherent capabilities of HTML and CSS (especially in the realms of animation, accessibility, and control behavior) you can go a long ways before bringing JS into the picture.

And more!

I'm not the savvy-est developer out there. I am nowhere near familiar enough with JS to make this a comprehensive article or anything. That's most of the reason I keep a blog, so that I can record things as I learn them. In that spirit, if there's something I missed that will make this list please let me know! There's comments and a magic link-to-your-response box below!

 

Have you written a reply to this post? Send me the URL here: