Web Performance

We like our networks fast and always on. Streaming video, instant pictures, audio, games, you name it. It seems almost effortless to consume it all.

The reality behind things that are so fine, so easy, is that it takes an awful lot of work to get all the details just right. I know how true that is in video storytelling. Mo Willems talks about it with children's books. Linus Torvalds insists that, as far as tech innovation goes, the formula to success is one percent innovation and 99 percent hard work.

On the web, 'just right' means eliminating bottlenecks, sending only what's needed over the line. Because the connection will always be the most vulnerable point. When a user's connectivity declines, it's understandable that the experience is affected. But we don't want a site to become completely unusable.

One way to get around the connection issue is to use CDNs and caching. That requires building and maintaining systems that exist solely to pump our data. These are critical on large systems to satisfy the huge numbers of users. But, no doubt, they work better when a system has been tuned and revised to operate as efficiently and cleanly as possible.

I've been struck by this conundrum since reading Dan Luu's blog on what it's like to browse the web on a very slow network. Of course, 'slow' is a relative term and what we consider slow today was the norm for most of us in the '90s.

Despite my connection being only a bit worse than it was in the 90s, the vast majority of the web wouldn’t load.

"Wouldn't load." Not slow, or sluggish, or certain features suffered. Does _not_ work. Even on dialup in the 90's, you could rely on part of a site to work before the whole page loaded. Now, we have scripts that run only when the page content is loaded. On a slow connection, that may never happen.

Drupal

This got me thinking about the work I do, which is mostly on Drupal. Sure, Drupal is heavy by design, but it can be tuned to work efficiently, right? When I went to look at one of our team projects, that is not what I found. Many scripts and style files loading individually, large image sizes ... But it works fast in front of the caching layer! I have a lot to learn when it comes to tuning Drupal or any other network application. But it does make me think about the project lifecycle and where or when it's right to force a discussion about performance with a client.

Angular 2

Angular 2 is another technology I use. For comparison, I wanted to look at the performance details on a very small app I have. Webpagetest declared it pretty good, in spite of having no CDN. All A's, in fact, except for the F on CDN usage. I should be proud of that report card!

The challenge with Angular 2 and many other Javascript framework is that first page load. The framework comes down in that initial payload and _must_ be loaded before any of it works. So ... what is that payload in my case?

That pesky vendor bundle is more than 3MB! Thinking back to the '90s dialup days, I would have thought very hard about clicking on a photo or video that was 3MB. 

As far as Angular goes, I know the team has made huge efforts to minimize the size of the base bundle as much as possible. A barebones, stock app built from the cli measures in a bit smaller. My app has zero images, but it does draw in parts of the RX Observables library and optional Angular 2 modules, i.e. http. So then we start thinking about lazy loading and ahead-of-time compiling ... things get more complicated.

Another inspiration for my exploration into performance was this article by Addy Osmani. He talks about the cost of parsing and compiling scripts in the browser. 

As we move to an increasingly mobile world, it’s important that we understand the time spent in Parse/Compile can often be 2–5x as long on phones as on desktop.

This is all totally new to me as well, and somewhat separate from the earlier performance issue. But it all reflects in the end-user experience. The temptation for developers is to add. More code, more features, more is more, right? Sometimes we have to think about users. And the reality for them may not be that more is more.