Why The Web Is Obese
Last Updated -
A few years ago I shared Ronan Cremin’s observation the average web page is now larger than the original DOOM installation file. Shortly after that I came across Dion Almaer’s Our Web Obesity Epidemic article, which echoes the same sentiments.
The point being the average web page is far too large. This mirrors how we have allowed ourselves to become obese and out of shape. I wrote about my personal story of losing weight and getting back in shape earlier this year. Over the past year and a half my personal health and fitness research revealed how much our web development practices mirror our personal health. Or better put, I know why the web is obese.
Dion makes the following statement:
“That being said, if we see someone taking the wrong path, such as
going all in on a low-fat diet that we know is a hoax, we should step
in. We should do everything we can to educate people and help them
make the right choices.”
For years I feel like that has been one of my missions, to help stakeholders and developers understand why web performance is important and ways they can achieve almost instantaneous experiences. There of course are many layers to this obesity epidemic. There is the loading issues, but then there is what I call ‘run-time’ issues related to updates and responsiveness. But other areas include battery life, CPU and memory loads. Everything seems to correlate directly to the obesity epidemic. In short we eat too much crap and dont get enough exercise. This is causing chronic diseases that are killing the perception and desirability of the web platform.
This is nothing new, Jason Grigsby uttered the following several years ago:
“We have remade the web in our own image…obese”
When the web was still primarily a dial-up adventure we assumed there was little to know bandwidth available. Our web pages were lean and fast. We also did not have the technologies we have today to build rich user experiences, nor did we have customers that expected rich user experiences.
As bandwidth expanded developers assume high speed access is ubiquitous. Browsers have gotten much better, so we moved much of the server-side processing to the client. Meanwhile consumers have moved from powerful desktop machines to lower powered mobile devices, causing a painful degradation in user experience.
The current state of the web, according to HTTPArchive.org - Mobile State of the Web:
- 69 File Requests – 1.67MB
- 19 JavaScript Files - 360KB
- 6 CSS Files - 55.3KB
- 28 Images – 845KB
- 15 TCP Connections
- 49% Cacheable
But it is much worse than those numbers tell. HTTPArchive limits analysis to the top 500,000 site home pages. If you spend any considerable time digging past a site’s home page you quickly realize the internal pages are much heavier. Half a million sites may sound like a lot, but there are over 35 million registered domain names. I like to think of it as we think we are only slightly overweight, when in reality we are morbidly obese and just don’t know it.
When I visited the doctor in December 2014, and discovered I weighed 272 pounds I was in shock. I thought I weighed 235-240. Those extra 35 pounds scared me to death. I imagined a short life, filled with many unwanted health issues that would not only hurt my life, but my wife’s. I imagined her shouldering the burden of helping me deal with those inevitable health issues. It triggered a complete lifestyle change. Now I am hovering around 180 and feeling better than I did 25 years ago.
As business owners, web developers and operations engineers we are in the position a spouse to an unhealthy, obese person needing help. We love the person, but our quality of life suffers because we must spend time helping our love one suffer through life, out of shape. This is not only emotionally and time taxing, it is expensive.
A fat, out of shape web application is a time suck for customers and business owners. They are much more expensive to maintain and improve because so many things must be managed that could simply be eliminated without degrading user experience. This leads to higher customer satisfaction, lower operation costs and the ability to add new functionality faster. These result in higher sales and margins and a much healthier bottom line.
Web Performance Fast Facts
Radware published a set of stats related to poor web performance in November 2012:
- 57% Will Abandon a Slow Site After 3 Seconds
- We Have to Concentrate 50% Harder for Slow Sites
- 78% Have Felt Stress or Anger With Slow Sites
- 44% Say Slow Sites Make Them Anxious
- 4% Have Thrown Their Phone
I love the last fact because it demonstrates the level some users reach when forced to interact with bad user experience. We need to be mindful of the stress we are forcing on customers when they try to interact with our brand. We need to make it as simple and fast as possible.
The middle 3 stats all relate to the mental stress overweight sites cause the end user. Developers and engineers tend not to think about user psychology when writing and architecting code. Let’s be honest most developers spend their time and enjoy writing ‘back-end’ code more than front-end code. It is a world of pure logic, where front-end is a much different layer. The front-end integrates with the human mind.
Engineers struggle integrating code with the human mind. The mind is not something you can unit test. Human interaction requires real life observation. This requires direct monitoring, A/B split testing and much more. This is why businesses need to have front-end specialist and a site that is decoupled from the back-end. Employing those two tactics allows you to create a front-end experience that can be rapidly updated in response to custom usage patterns. This enables you to deliver the best experience you can every moment of every day.
How Did We Get So Heavy?
As I did research on the human obesity epidemic and learning why we got fat I could not help but wonder why the web got fat. I decided to relate some factors to personal diet and health habits. Maybe this will affect you to be healthier in real life as well as your development lifestyle.
We Eat Too Much
As the HTTPArchive statistics show we are loading too much to accomplish very little. From fast food frameworks, poor third party scripts, inefficient CSS to unoptimized images, we eat like a tourist at a Vegas buffet.
At a super high level when you eat too many calories, more than you burn in a day, then you gain weight. Maybe an over simplified answer to the complex issue, but a good place to start.
In the web performance world we start with payload weights because it is a simple stat that makes poor performance real. We also focus on page load and render times, all good key indicators to raise awareness. Generally a fatter site is a slower, less healthy site. When you cut back your portions and how much code you push to the client your user experience will improve.
We Eat the Wrong Things
Many diets and health experts talk about how many calories we eat causing the obesity epidemic, but this is not the whole story. It is how much we eat of the wrong things. The web is similar. Just because a web page loads 2MB of images does not mean it loaded slowly. Just as an application with 1MB of JavaScript may not be architected incorrectly. But we often add code blindly without doing due diligence as to the impact that code has on the overall application health.
{junk food}
I keep referring to the ongoing HTTPArchive stats because they breakdown a large sample size allowing us to see what composes the average web page. At a high level you can see where the bloat resides. But you need to dig a little deeper to see what has caused different asset type byte sizes to increase. In short we load the wrong things.
The first area I point out is the rise of ‘fast food frameworks’. These are large libraries, sometimes 1MB or more in size. They add large volumes of code that needs to be downloaded, then evaluated before a page can be rendered. Often most of the code is never executed. How often do you visit a page where the only ‘dynamic’ aspect is a dropdown menu, but over 1MB of JavaScript has been loaded? More often than you think.
A few years ago a senior architect was trying to decide how to architect the new version of a large retail site. The engineers were cheering for a popular fast food framework. The senior architect was balking at their suggestion and weighing my suggestion of a fast, lean code base. He made a statement along these lines:
“95% of our site is read-only. We have a drop-down menu and a faceted search. The rest requires very little JavaScript.”
As I try to decide what code to include in an application I ask ‘can this be done with the native APIs or CSS’ before I go running for a large JavaScript solution. Most of the time the answer to my question is yes. This is why I can build rather large single page applications with less than 100kb of uncompressed JavaScript.
Make sure you are using the right code and not just adding a library, framework or plugin just because it is ‘convenient’ or popular.
We Relay on Fast and Over Processed Foods
Fast food frameworks like React, Angular, Ember, etc are very popular. Often because developers feel comfortable having buzzwords on their resume and hiring managers feel better seeing them on resumes. Having a native or vanilla JavaScript expertise on your resume somehow is shunned. I also see code being added just because it is trendy, which of course leads to bloated code bases.
A previous client called me in to provide SPA expertise. They wanted to completely rewrite their site from scratch, often wise when your code has been around more than 2-3 years. Their live site contained some Prototype, jQuery, Ember, Angular and a smattering of other popular libraries and frameworks, including full control vendor packages. When everything was added up it was over 2MB of JavaScript, plus the accompanying CSS. 95% of this code was never executed.
{fast food frameworks}
When I pressed the team why so many layers their answer shocked me. They said they would write code in what ever was popular at the time. When they got bored they would move to the next hot framework. This way their resumes would stay up to date and they would not lose interest in writing the code.
This may sound like an extreme story, but I have seen it in person several times. I see it as I travel the web and evaluate slow and poor performing sites.
Developers, like most in Western culture, consume convenience libraries and frameworks rather than coding fresh, healthy applications. Instead of investing the same amount of time to learn powerful, fast browser APIs time is spent learning a framework that abstracts and often recreates they native APIs. Just like fast food restaurants feel more convenient because you don’t have to cook the food, the product has very little nutrition and only makes you hungrier. Worse it abstracts how to prepare real applications and developers forget how to write real code.
The result is fat, out of shape web applications no one wants to use, instead choosing to use your competition, maybe a native app (perceived to be better, but suffers from the same fitness issues). If no alternative is available they often just do not participate with your brand or industry. Line of business employees often find other solutions to accomplish their job or secretly hate their jobs, you and the company. This leads to high turn employee and customer over rates.
Summary
User experience is important to the customers. Healthier web sites have better user experiences at a lower cost of ownership. You do not need to sacrifice end user experience for leaner code. Instead user experience is improved and code is easier to maintain.
“80-90% of the end-user response time is spent on the frontend, Start there”, Steve Souders.
Since reading Steve’s High Performance Web Sites book back in 2008, the way I approach web development changed. Today I take pride in my user experience. I make the effort to understand how the browser works and have learned to leverage that knowledge to cook fast, engaging web applications that scale, cost less to host and are easier to build and maintain.
When you are looking for a web solution you should consider how the application is cooked. Are you consuming fast food or healthy fresh code, cooked close to the browser? If not then you should consider a new web solution, one you and your customers will love.