Journal tags: section

Web performance is an unalloyed good. No one has ever complained that a website is too fast.

So the benefit is pretty obvious. Users like fast websites. But there are other benefits to web performance. And they don’t all get equal airtime.

Business

A lot of good web performance practices come down to the first half of Postel’s Law: be conservative in what send. Images, fonts, JavaScript …remove what you don’t need and optimise the hell out of what’s left.

That can translate to savings. If you’re paying for the bandwidth every time a hefty file is downloaded, your monthly bill could get pretty big.

So apart from the indirect business benefits of happy users converting to happy customers, there can be a real nuts’n’bolts bottom-line saving to be made by having a snappy website.

Sustainability

This is related to the cost-savings benefit. If you’re shipping less stuff down the wire, and you’re optimising what you do send, then there’s less energy required.

Whether less energy directly translates to a smaller carbon footprint depends on how the energy is being generated. If your servers are running on 100% renewable energy sources, then reducing the output of your responses won’t reduce your carbon footprint.

But there’s an energy cost at the other end too. Think of all the devices making requests to your server. If you’re making those devices work hard—by downloading, parsing, executing lots of JavaScript, for example—then you’re draining battery life. And you can’t guarantee that the battery will be replenished from renewable energy sources.

That’s why sites like the website carbon calculator have so much crossover with web performance:

From data centres to transmission networks to the billions of connected devices that we hold in our hands, it is all consuming electricity, and in turn producing carbon emissions equal to or greater than the global aviation industry. Yikes!

Inclusivity

There comes a point when a slow website isn’t just inconvenient, it’s inaccessible.

I’ve always liked the German phrase for accessible: barrierefrei—free of barriers. With every file you add to a website’s dependencies, you’re adding one more barrier. Eventually the barrier is insurmountable for people with older devices or slower internet connections. If they can no longer access your website, your website is quite literally inaccessible.

Making the case

I’ve noticed that when it comes to making the argument in favour of better web performance, people often default to the business benefits.

I get it. We’re always being told to speak the language of business. The psychology seems pretty straightforward; if you think that the people you’re trying to convince are mostly concerned with the bottom line, use the language of commerce to change their minds.

But that’s always felt reductive to me.

Sure, those people almost certainly do care about the business. Who doesn’t? But they’re also humans. I feel like if really want to convince them, speak to their hearts. Show them the bigger picture.

Eliel Saarinen said:

Always design a thing by considering it in its next larger context; a chair in a room, a room in a house, a house in an environment, an environment in a city plan.

I think the same could apply to making the case for web performance. Don’t stop at the obvious benefits. Go wider. Show the big-picture implications.

A Day Apart in Seattle was more like a seminar than a workshop. Rather than being an intimate gathering in a small room, it was more lecture-like in an amphitheatre setting. But that didn’t stop me interacting with the attendees. There were plenty of great questions throughout, and I also had everyone complete an exercise.

I reprised the exercise I gave at dConstruct back in September. It isn’t a test of the audience. Rather, it’s a test of how well the new structural elements in HTML5 are described:

I then asked the attendees to match up the definitions with the element whose name sounded like the best match. To be clear: this wasn’t a test of knowledge. I was testing the spec.

The results from September’s test were quite revealing. There was some confusion between footer and details. Since then, the definitions in the spec have been updated and I’m happy to report that the Seattle audience—a much larger sampling—were almost unanimous in correctly matching element names to their definitions.

With one glaring exception.

The section and article elements were, once again, confused. This happened back in September at dConstruct. It happened again at A Day Apart in Seattle. I didn’t get exact numbers, but from the very web-savvy audience of about two hundred people, I would say there was a 50/50 split in matching up the definitions of section and article. About 50% of the attendees thought that the definition of section applied to article and visa-versa.

Historically, article and section were more distinct. The article element used to have optional cite and pubdate attributes. Now their content models are identical (apart from the fact that the article element can take an optional time element with a pubdate attribute).

The only thing that distinguishes the definition of article from the definition of section is the presence of the phrase self-contained. A section groups together thematically-related content. An article groups together self-contained thematically-related content. That distinction is too fine to warrant a separate element, in my opinion.

The existence of two elements that are practically semantically identical isn’t a harmless addition to HTML5. It’s causing a great deal of confusion. I’ve spoken to authors who incorrectly assumed that articles had to be within sections or that sections could only be within articles. The truth is that you can have sections within articles, articles within sections, sections within sections, articles within articles, or any other combination you can think of.

This isn’t helpful. Authors are confused. Yet, according to the HTML Design Principle of Priority of Constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

I don’t understand why Hixie is still clinging to the addition of the article element when he has repeatedly stated that he wants to keep the number of new elements to a minimum. Here’s the perfect opportunity: merge section and article into one element. Personally, I would keep section, with its more generic-sounding name.

We’ve been here before. The abbr and acronym elements were responsible for years of confusion amongst authors unsure of which one to use. The use-cases and the definitions of both elements were just too similar. That particular problem has been solved in HTML5: the acronym element is now obsolete. The abbr element works well enough for both use cases.

Let’s not repeat the mistake of abbr and acronym with article and section.