There has never been a better time to be a frontend developer. HTML5 and CSS3 have allowed us the flexibility to design user interfaces consistently across a wide variety of platforms, whilst JavaScript has been elevated from a scrappy scripting language into a fully fledged programming language with its own ecosystem, development environments and developer community. We are now equipped to do battle with native apps – indeed, the line between what's native and what's not blurs ever more with each browser iteration.
In our quest to become fast-yet-full-featured, I feel we're missing some tricks. How often have you added a library to your frontend code? And then added a framework? Maybe a selection of plugins. A dash of responsive grid. Some shims and polyfills. And finally a sprinkling of images?
Suddenly, you mysteriously have hundreds of kilobytes of JavaScript and CSS to download. Libraries and frameworks built on other libraries, full of hacks for older browsers, relying on gzipping and minification to make things small. And that's before you've even reached any of the content you want your users to see.
You expect your pages to run quickly on those older browsers, or on mobile devices with little available memory. You complain when they don't, that it can't be done, that mobile browsers are too slow, that JavaScript in phone browsers isn't fast enough, that the DOM isn't fast enough. Sound familiar? Well, there's another way.
Quick and simple
A technique that seems to have been eclipsed somewhat is that of progressive enhancement. Use the server to create your pages, don't send everything to the client and make them assemble it. Write valid, semantic HTML. Target your slowest browsers and do everything you can to make them fast. If you have to support IE8, code with a copy of IE8 open. Test everything for speed and performance.
Once you have an actual page being rendered by the browser, you won't have to worry about JavaScript or the DOM being slow on mobile. Keep it simple. Keep it fast. Once you have a really fast template that works without JavaScript, you can then enhance the content with a sprinkling of JavaScript. Here are my top tips for building the fastest possible websites:
- Make as few requests as possible. Ideally one HTML file, one CSS file and one JavaScript file. The icons and visual assets that constitute your user interface should be small, optimised and embedded as Base64-encoded images inside your CSS where possible.
- If you're using templates to construct HTML on the fly within the browser client, make those templates work on the server as well as on the client. Twitter spent a fair amount of time removing its old hashbang scheme for tweets, turning tweets into physical pages on the web. The company claims this dropped page-load times by 20 per cent.
- Load only what you need to see, when you need to see it. Sounds obvious, but often you'll have a long, scrolling page and all the images on that page will be set to be downloaded at once. This leads to a cascade effect – web browsers only open a certain amount of connections at a time to a specific host, so only a certain amount of your images will be downloaded at once. Use CSS to show background images when they're needed.
- With photographs and retina images, you can often get away with using 30 per cent quality in Photoshop's 'Save for web' feature, and doing the resizing in the browser. You end up with images that are almost the same file size as the normal ones, saved at 70-80 per cent quality, but with a higher resolution.
- If you use PNGs with alpha transparency, you can often get away with changing them from 24-bit colour to a 256-bit colour palette using software such as Fireworks or ImageOptim with no discernible loss in quality but sometimes more than 50 per cent smaller file sizes.
With this approach, you get some added extras. SEO for free. Older clients will, for the most part, work too. Same with screen readers. It'll be trivial to add ARIA accessibility support. On top of that, you get the fluffy feeling of being a good net citizen.
Words: Scott van Looy
Scott has been creating websites since 1995. He has spent the past 7 years at AKQA London and Berlin, specialising in JavaScript CSS and HTML. This article originally appeared in net magazine issue 256.
