http/2

ES6 modules support lands in browsers: is it time to rethink bundling?

Modules, as in, this kind of syntax right in JavaScript:

import { myCounter, someOtherThing } from 'utilities';

Which we'd normally use Webpack to bundle, but now is supported in Safari Technology Preview, Firefox Nightly (flag), and Edge.

It's designed to support progressive enhancement, as you can safely link to a bundled version and a non-bundled version without having browsers download both.

Stefan Judis shows:

<!-- in case ES6 modules are supported -->
<script src="app/index.js" type="module"></script>
<!-- in case ES6 modules aren't supported -->
<script src="dist/bundle.js" defer nomodule></script>

Not bundling means simpler build processes, which is great, but forgoing all the other cool stuff a tool like Webpack can do, like "tree shaking". Also, all those imports are individual HTTP requests, which may not be as big of a deal in HTTP/2, but still isn't great:

Khan Academy discovered the same thing a while ago when experimenting with HTTP/2. The idea of shipping smaller files is great to guarantee perfect cache hit ratios, but at the end, it's always a tradeoff and it's depending on several factors. For a large code base splitting the code into several chunks (a vendor and an app bundle) makes sense, but shipping thousands of tiny files that can't be compressed properly is not the right approach.

Preprocessing build steps are likely here to stay. Native tech can learn from them, but we might as well leverage what both are good at.

HTTP/2 – A Real-World Performance Test and Analysis

Perhaps you've heard of HTTP/2? It's not just an idea, it's a real technology and slowly but surely, hosting companies and CDN services have been releasing it to their servers. Much has been said about the benefits of using HTTP/2 instead of HTTP1.x, but the proof the the pudding is in the eating.

Today we're going to perform a few real-world tests, perform some timings and see what results we can extract out of all this.

(more…)

Modernizing our Progressive Enhancement Delivery

Scott Jehl, explaining one of the performance improvements he made to the Filament Group site:

Inlining is a measurably-worthwhile workaround, but it's still a workaround. Fortunately, HTTP/2's Server Push feature brings the performance benefits of inlining without sacrificing cacheability for each file. With Server Push, we can respond to requests for a particular file by immediately sending additional files we know that file depends upon. In other words, the server can respond to a request for `index.html` with `index.html`, `css/site.css`, and `js/site.js`!

Server push seems like one of those big-win things that really incentivize the switch to H2. We have an article about being extra careful about caching and server push.

A Case Study on Boosting Front-End Performance

At De Voorhoede we try to boost front-end performance as much as possible for our clients. It is not so easy to convince every client to follow all of our performance guidelines. We try to convince them by talking to them in their own language, and explain the importance of performance for conversion or compare their performance to their main competitors.

Incidentally, we recently updated our site. Apart from doing a complete design overhaul, this was the ideal opportunity to push performance to the max. Our goal was to take control, focus on performance, be flexible for the future and make it fun to write content for our site. Here’s how we mastered front-end performance for our site. Enjoy!

(more…)

Building for HTTP/2

Rebecca Murphey:

This is everything-you-thought-you-knew-is-wrong kind of stuff. In an HTTP/2 world, there are few benefits to concatenating a bunch of JS files together, and in many cases the practice will be actively harmful. Domain sharding becomes an anti-pattern. Throwing a bunch of <script> tags in your HTML is suddenly not a laughably terrible idea. Inlining of resources is a thing of the past. Browser caching — and cache busting — can occur on a per-module basis.

I can't help but think that web development might actually make sense some day.

Making a Simple Site Work Offline with ServiceWorker

When Nicolas Bevacqua (of Pony Foo) started talking about a potential guest post, I knew right away we should do something with offline. Nicolas has been writing a lot about the ServiceWorker API and offline stuff is one of the things it was made for. Rather than a theoretical look with code snippets, I thought we could combine that with a demo website with it all working. So that's what we did - take it away Nicolas!

(more…)

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag