Fast sites do not require insults

The snow stung my face after the neighborhood bully shoved me into the snowbank at the foot of my driveway. I couldn’t let my tears ice up: I had to get up and chase after the sheets of music he had knocked out of my band folder. Measure after measure now swirled through the air. He and his friends shouted “Thunder thighs, thunder thighs” at me as I tried to pull myself together so I could go to school.

A neighbor’s mom yelled at the bullies to leave me alone. That’s the one bright spot in an awful memory.

I was around twelve, overweight, and while that was one of the worst times I was mocked for my weight, it certainly was not the first or the last.

A quarter century later, I still struggle with my weight and my health. I also get the joy of reliving that moment all too often when I read an article about web performance.

These are all real article titles:

  • “Don’t Fall Victim to Web Obesity. 5 Preventive Measures to Keep Your Website Healthy.”
  • “Does Your Website Need to Go on a Diet?”
  • “Website and Human Obesity: When Correlation Isn’t Causation”
  • “Bloating Your Code: Why Are Websites Getting Fatter?”
  • “Modern Content Has Made the Web Fat—And That’s a Big Problem for Mobile”

Creating fast sites is crucial to a great user experience. I care deeply about front-end performance as a key component of making sure the sites we create work everywhere. Web standards, accessibility, responsive web design, front-end performance—these are all key to ensuring that the sites we create can be used in any browser, on any device, by anyone regardless of their abilities or the speed of their Internet connection.

So if our goal is to create more inclusive sites, why talk about how to do so with language that excludes and alienates so many people?

I am not the only web developer who struggles with their weight and associated health complications. If you have never had to wage war with your own body, bless your soul. From the outside, it’s easy to assume that being overweight is a simple equation of inactivity plus overeating. The reality is often more complicated and different for each individual.

Strict diets can have temporary benefits, but often lead to long-term yo-yoing between highs and lows. Eating healthy and getting exercise can help, but sometimes seems to have little effect. One person who eats relatively healthy can weigh a great deal more than someone who eats junk food day or night. Stress plays a large role in weight, so insulting somebody for their weight in the hopes that will goad them into good health often has the opposite effect.

Being overweight or not is a lot harder to control than many imagine. The interplay between genetics and an individual’s actions makes dealing with your weight challenging at best. The complicated personal factors involved are also quite unlike the more straightforward techniques that can be used to improve website load times.

It’s entirely possible that those writing articles about “website obesity” give little thought to the harm that analogy might cause. Caring about that is just another type of political correctness, amiright? Didn’t mean to insult anyone, stop being so sensitive, geesh. Just an analogy.

I’d like us to stop talking about “fat sites” not only because that language hurts my feelings, but also because this oversimplification obscures key ways we can make websites faster.

When people talk about websites being too fat or obese, this is shorthand for sites that have a larger total file size than necessary. Sites that load more files than are needed, sites that aren’t compressing files as much as possible, sites hoarding loads of JS and CSS that will never be used, sites with giant images far too large for small screens, and on and on.

Getting our sites to load just as much as needed and no more is a great goal, but we can’t stop there.

Often what’s equally important is optimizing the critical rendering path. Understanding how browsers actually work goes a long way to making your site faster. When you enter a URL in a browser or click on a link, how exactly does a browser fetch HTML and other associated resources? How does it process CSS, JS and images; how does it determine when to fetch each resource from the server, when to process that resource? How is the HTML, CSS and JS parsed into a DOM that can be rendered in the browser? How are server requests affected by different types of Internet connections, particularly wi-fi versus cell towers?

Understanding how browsers work can lead you to improve web performance with techniques like:

  • JS not strictly required for the first load of a page should go at the bottom of your source code, right before the closing body tag.
  • Load JS with async and defer, as appropriate, to move it out of the critical rendering path.
  • The transform and opacity properties are key to preventing the browser from re-rendering an entire page when making a CSS change based on user interaction.

That isn’t a comprehensive list of front-end performance techniques by any means, but these are examples of how there are many performance tools that have little to do with file size.

Other common front-end performance techniques are currently in flux as http/2 rolls out. Minimizing the number of server requests has long been a key performance recommendation. Aggregating CSS, JS and using SVG sprites for icons can all help minimize the number of times a browser needs to open a new connection with a server. However, http/2 will help minimize the overhead of each file request. So once browsers and servers widely support http/2, aggregation may become an anti-pattern. JS or CSS that is used on every single page can and should still be aggregated as much as possible. However if a resource is used on only a certain subset of pages, there will be much less overhead to load those files separately.

With http/2, as aggregation becomes a less useful performance strategy, there will likely be a renewed focus on only loading necessary resources on any given page. I fear that will lead to the all too easy analogy of obesity being used even more.

So here are some alternative analogies to use to describe loading only necessary resources:

  • “Loading desktop-size images on a small screen is like shoving a semi trailer into a Mini Cooper.”
  • “That CSS framework is like stuffing twenty clowns in a car when you only need one to make balloon animals at a kid’s birthday party. Terrifying.”
  • “If this page only needs one icon, and you’re loading thirty-two, ask yourself if you really need to bring the Death Star when just a TIE Fighter will do.”

To use shorter terms: many sites are overloaded, which makes them just plain slow.

You can easily find more expressive ways to illustrate a point about front-end performance than resorting to cheap, moralizing shots at how much people weigh versus how much you think they should.

Making “jokes” about a person’s weight is one of the last socially acceptable methods of insulting a person based solely on their appearance. After all, doing so helps to encourage people to be healthier, right? Just trying to help.

One of the great joys of being overweight is having people coming up to you at a conference to suggest their magical method for getting thin. Just take these pills, worked for somebody I know! Hey, go vegan, worked for me! Hearing that sort of advice out of the blue doesn’t help me. It only results in shame and frustration. Trust me, if somebody is overweight, they know it, and they’ve probably tried every trick in the book.

So don’t think that by using fat analogies you’re both making websites faster and helping to finally motivate people who are overweight to be thin. No, you’re using a trite analogy which has the bonus of potentially causing pain to those who struggle with their health by bringing back memories of countless bullies and personal insults.

You don’t know why somebody is overweight. You don’t know what other health complications they might have, what pills they are taking that cause weight gain, what physical complications might make it difficult to exercise, or what metabolic issues might make weight gain easy and weight loss hard.

A person’s weight is not at all like a website. So find another analogy. Get creative. By all means, work to make the web faster. Just find a way to do so without insults.

Dive Deeper

If you want to know more about the Pastry Box Project, you can read about the genesis (and goals) of the project.

Swim In The Stream

A stream of all the thoughts published on the Pastry Box Project is available. Keep it open somewhere, and lose yourself in it whenever you feel like it.

Meet Your Host

There are not only pieces of software talking to each other behind this website. There is a human, too. The Pastry Box is brought to you by Alex Duloz.

Stay Tuned

You can follow @thepastrybox on Twitter. For direct inquiries, get in touch with @alexduloz.