The beauty of the web is that there is no “install” step. Someone, somewhere taps a link to your site, and moments later it appears instantly in front of them.

At least, that’s the idea—but not all devices and networks are created equally. Sites that feel fast on a desktop computer with broadband can feel downright slow on a mobile phone with spotty 3G service.

So how do you build sites that stay fast no matter what? To help us better understand, we built a prototype application with two popular JavaScript libraries, Preact and Glimmer.js, that embody different philosophies of how to maximize web performance.

Emerging performance trends

Over the past few years, there has been excitement in the web development community about the idea of using lightweight libraries—those that prioritize small file size above all else—to build websites that load instantly. Advocates of this approach explain that every byte of JavaScript is a performance liability—and many popular frameworks should be considered “too big” even before you’ve written a single line of app code. Detractors of this philosophy argue that prioritizing file size over robustness stops paying dividends—and can become a liability—as an application grows. They argue that skimping on abstractions and infrastructure in the beginning just means pushing additional complexity into the app itself.

One exciting trend to emerge recently has been the idea of using compilers to “bend the curve” of tradeoffs between file size and robustness. A compiler can analyze your entire application and, theoretically, produce optimized output and assets that include only what you need.

This approach has its skeptics, too, who argue that compilers will have trouble beating a hand-tuned lightweight library. If the compiled output is still larger than the lightweight library, the argument goes, any performance gains will be wiped out.

Unfortunately, it’s very difficult to test these competing philosophies in the real world. If you want to compare how performance changes as complexity grows, how do you test that without building the same app twice? If you’re really motivated to answer this question, you could try to build the same app twice. But is that feasible? Well, that’s exactly what we did here at LinkedIn.

The need for feed

This project first started with the goal of building a prototype that optimized for page load time at all costs, to help us calibrate what “theoretical maximum” performance looked like.

Since the first thing members see when they visit LinkedIn is the feed, we thought a reimplementation of this page would be the ideal prototype for experiments around initial load time. It’s also a complex page with many different features, which was important for verifying that performance improvements held as the application grew.