Are We Doing Our Best on Frontend Development? This Data Perspective May Help Answer This Question

May 30, 2023
Rss Fetcher

An overview of the comprehensive state of the web report

The sum of transfer size kilobytes of all external scripts requested by the page. Source: httparchive.org

If your expression changed after seeing this chart, keep reading this article.

We will review together last year’s Web Almanac report by httparchive and see what’s happening on the web.

The Highlights
  - JavaScript
  - HTML
  - CSS
Web Almanac (by httparchive)
State of JavaScript
State of HTML
State of CSS
Final words

The Highlights

JavaScript

There are many interesting points to review, such as more than 77% of pages have render-blocking scripts, less than 0.5 of sites uses dynamic import of JavaScript, the median mobile page has 3.59 seconds dedicated to long tasks, and so on.

“We need to do all we can — and more — to stem the tide of how much JavaScript we ship on production websites.” -the report

We will review this state of js a little bit deeper later.

HTML

Do you know what ‘Divitis’ is? That sounds familiar, doesn’t it?

The practice of authoring webpage code with many <div> elements in place of meaningful semantic HTML elements.

And guess what? Almost 30% of HTML tags are divs over the total tracked sites by httparchive. They represent 2,123,819,193 occurrences in the mobile data set and 1,522,017,185 in the desktop data set.

“Divitis is real.” — the report says.

CSS

There are many interesting items on the CSS report, such as rules repetition increase, nonexistent properties usage like box-flexor margin-center(those are funny ones), and the unrecoverable syntax errors state:

“…An unrecoverable error is one where the error is so bad, the full stylesheet is unable to be parsed by Rework. Last year, 0.94% of desktop pages, and 0.55% of mobile pages contained an unrecoverable error. This year, 13% of desktop pages and 12% of mobile pages had such errors. This seems like a large jump…”

If every year we have an increase of around ~2000% of these errors, we have messed up.

What does all this mean?

What do you think? Are we healthy in terms of performance, best practices, and code quality?

Data is screaming. No, we aren’t.

Web Almanac (by httparchive)

-What are we reading?
In their words: The Web Almanac is a comprehensive report on the state of the web, backed by real data and trusted web experts.

-How many sites were tested by this report?
8.4 million websites are tested monthly (~43.88 TB of data).

-What does this report tell us? It has four major parts, and each section is composed of chapters:

Page Content (we are reviewing this one)
User Experience
Content Publishing
Content Distribution

If you are a frontend developer or work with one, I recommend you check all the reports to ensure they have no waste.

All right, now we’ll start looking at the main chapters of the ‘Page Content’ part (JS, HTML, and CSS).

The State of JavaScript

As I mentioned at the beginning of this post, the data presented here is quite shocking. What’s intriguing is that despite these findings, we often don’t perceive the impact on our user experience. This could be attributed to the concurrent increase in the processing capacity of devices and advancements in internet speed evolution.

This sounds OK. Everything evolves with balance, and we already know technology is going that way. So, what’s the matter?

Percentiles show that we are on our way to reaching 50% of unused js bytes in production. Source: httparchive.org

Does this combination of charts tells you something?
Between 30 and 40 percent of total js bytes is unused code!

So, the amount of code we can deliver to our end users or devices is increasing, which seems reasonable. However, what’s concerning is the simultaneous increase in the amount of unused code. This is something that should ideally be improved.

Can we do this better? Where are we going wrong? What factors should we address and rectify that contribute to this inefficiency?

In this article’s ‘Final words’ section, I’ve listed some points to keep in mind. Now, let’s continue reviewing the report.

“We found that 77% of mobile pages have at least one render-blocking script in the document <head>, whereas 79% of desktop pages do this. This is a concerning trend, because when scripts block rendering, page content is not painted as quickly as it could be.”

The report has many improvement opportunities identified, such as avoiding Render-Blocking Scripts on a page fetch. It says, “In particular, 63% of the top 1,000 websites accessed on mobile devices ship at least one render-blocking script in the <head>, and the proportion of pages increases as we proceed through the ranks.”

The recommendation here is to keep integrating non-render-blocking execution into your projects, which can be achieved with async and defer strategies. Also, you can load scripts after the HTML content and do a preload of your scripts, etc.

Scripts injection is another common practice that can lead to performance issues, such as affecting the LCP if the injected script resource is responsible for rendering HTML or styling elements.

The report also says, “The script injection is so prevalent in today’s web is a concerning trend (75th and 90th percentiles of pages inject 50% and 70% of scripts respectively). Modern frameworks and tooling may rely on this pattern, which means that some out-of-the-box experiences may rely on this potential anti-pattern to provide functionality for websites.”

A staggeringly low 0.34% of all observed mobile pages currently use dynamic import(), while 0.41% of desktop pages use it. That said, it’s common for some bundlers to transform the dynamic import() syntax into an ES5-compatible alternative. It’s very likely that the feature is in wider use, just less so in production JavaScript files.

So yeah, we are going our way to support the most recent features of ECMAScript standards. Still, it looks like we have to put much effort into accelerating these upgrades and leave behind old-browser support (ES5) and start developing more recent technologies (ES2020 and onwards).

Dynamic import enables developers to load specific code chunks on-demand, optimizing JavaScript bundles and improving web application performance. Checkout Qwik, a fresh frontend framework whose mission is to ship zero js and load it on demand.

The import() syntax is supported on Chrome >85, Firefox >80, M. Edge >85 (chromium based) and Safari >14. Legacy JavaScript support will be slowly decreasing, maybe too slowly, so keep this in mind. If you need to keep supporting webs for Internet Explorer, then check if you can design a better js code delivery strategy :).

Check the Metrics section of the chapter. You can find data related to First Input Delay, Interaction to Next Paint, Total Blocking Time, and other CWV metrics.

Also, read about Scheduler. This is an amazing API currently being adopted by browsers (supported by Chromium-based browsers right now), but it will be a great tool to work with for web performance, which is only on ~0,003% of sites right now.

The JavaScript chapter is challenging for everyone; this was just an overview. Developers and frameworks authors should try to incorporate arriving technologies. In my opinion, we need to have a wider culture of web performance and monitoring of the evolving state of JavaScript (a hard task, as Jeff Delaney reminds us in every video).

Check the ‘Final words’ section to see a list of recommendations.

The State of HTML

The sum of transfer size kilobytes of all markup documents requested by the page. Source: httparchive.org

…We explicitly encourage you to also analyze the data we gathered and to share your own conclusions — and when you do, tag them: #htmlalmanac.

As they recommend for this section, we can do our own research using all the data they’ve collected and shared.

The Markup chapter has fewer conclusions than the others, but they provided a bunch of data we can interpret. What is plain is HTML could be much better used. Regarding performance or how many bytes of HTML are shipped to browsers, it is stable and fairly constant over time.

What did I mean by ‘better used’? In HTML 5, there are ~110 different elements, and the report shows a median of ~32 different elements are being used. It doesn’t mean we have to start using all available elements just like that, but maybe we can use more semantic markup tags instead of overusing the <div> tag:

<article>, <aside>, <details>, <figcaption>, <figure>, <footer>, <header>, <main>, <mark>, <nav>, <section>, <summary>, <time>

Or, in place of styling, let’s say a <span> (using, therefore, a CSS selector), it might be enough for you to use an <em> or a <b>, <i>, <s>, or any other tag that provides text emphasis. Even better, read what these tags were made for and check if they are recommended!

The list of ‘strange’ or uncommon tags is huge, and they might be a good opportunity in some scenarios. Some of those include <dialog>, <kbd>, <wbr>, <bdi>, and so on.

I was looking at the report’s data, and I found a mysterious case for the button elements:

<button type=”button”> only applies if it is inside a form (then the button will not have the role of submit or reset and, instead, will do nothing).

At the same time, as per the report, the total number of <button> tags is ~3.8M and ~5.4M for mobile and desktop, respectively. Does it mean that nearly 80% of button tags have this attribute? Are most of the buttons across all 8.5M analyzed sites inside forms, then? I wonder what all these ‘button type buttons’ are for… #htmlalmanac

The markup section includes other discussions (compression, document size, attributes, social markup, etc.), and you can directly check all chapters on the report.

A valuable resource for further investigation is the HTML Living Standard site.

The State of CSS

The sum of transfer size kilobytes of all external stylesheets requested by the page. Source: httparchive.org

Again, we can find really interesting facts in this chapter, such as:
CSS transfer data is increasing by nearly 7% year after year.

The median amount of rules is ~600 per page, with an increase from last year for the 50th percentile increased by 130 rules in the case of desktop. There are other interesting facts, but let’s walkthrough key aspects of this chapter.

The declaration repetition metric aims to identify how efficient a stylesheet is by looking for the number of declarations using the same property and value. It has a median of unique declarations per page of 45%.

Sniper-CSS 🎯 is a free, ‘one-click action’ Chrome Extension you can use to run upon any site. It will analyze the page, emulate variety of scenarios, and capture and download the CSS it applied on the app.

*It is not perfect but does a good job. You just need to verify if is any style missing in the page after using it.

For length units, pixels have dominance, by far, and that is a concern regarding the responsiveness of layouts. Nowadays, it is possible to create a fully responsive design using modern layout approaches such as flexbox or grid combined with relative length units. So this data is alarming.

Did you know that there are new relative units to use?

All relative units are available to use, and many of them are not widely known.

There are also ways to apply logical CSS to your styles if you know how to combine different rules selectors and style operators, like a conditional border radius, which is useful for your styles.

The report shares some exceptional cases found, like the largest style sheet detected for mobile was around 78MB of weight (I can’t imagine what this site is about). Another mobile site was loading 1,387 stylesheets… These numbers are scary. Damn.

Well, the CSS chapter also provides insights into the following:

popular pseudo-classes
selectors
specificity ranks
how many times the !important keyword is used
attributes
global keywords
custom properties
colors formats
new rule adoptions, and more

Wrapping up on style sheets, it will be interesting to see how all the new and modern properties will be adopted (or not) in the future years, but also, it will be nice to see improved quality of rules to be applied on today’s CSS usage, such as:

Avoid using the * selector in the top wrapper elements of a page, as it applies these rules to every single descendant element.
Anticipate which elements might change in the browser using the will-change property in case of an incoming mutation.
Revoke the use of heavy paint animations.
Rethink the usage of a third-party styles library like Bootstrap just to use a few rules when it loads nearly 14,000 lines of code in the minified version.
Explore techniques for optimizing CSS performance. There is much more to do!

Final Words

I encourage you to read more chapters of the report as you will see more useful data in the domain of Media, Fonts, Security, Accessibility, and many other interesting things.

What can we do to improve our products and provide top-quality web apps?

Here’s some key points:

Start measuring your code outcome.
Stay up to date on new web standards and their recommendations.
Dedicate more time to analyzing and investigating code best practices and design patterns.
Do a deep clean of your project after development time.
Use tools that help you stay aware of web vitals and improvements opportunities and how the user’s perception is related.
– Lighthouse and UX Report by Chrome, Page Speed testers, etc.
Consider upgrading your technology stack or start using new ones.
– For example, check how they behave regarding CWV (Core Web Vitals), Bundle size, etc.

Benchmark of Frontend Frameworks (Astro is AMAZING, check it out). Source: lookerstudio.google <- you can apply different filters, and it has more charts to check. Try it.

Investigate how your technology stack works behind the scenes.
– For example, how efficient is a framework using device memory.
Decrease or avoid the use of third-party resources that are not performant.
– For example, Momentjs is still in the top 15 npm used libraries. Stop. There are way better alternatives like dayjs, which is ~84% lighter (4.23MB vs 651KB).

And as an extra point, remember, margin-centerdoes not exist (I loved that one 😄)

This is the end of this article. I hope you’ve enjoyed it and found it helpful. I’ve learned new things while investigating and writing it. This is an endless field to explore and work on, as it will keep evolving and surprising us over time.

My motivation to share this information with you arises from my interest in web development performance and how to achieve it to create competitive and quality applications. I am aware it can be an exhaustive task, and there will always be room to improve what we do.

I leave an open question to think about regarding how much energy damage this data growth (much of it unused) can cause to the planet since it is a global worrying issue.

Can we make a positive impact by addressing this issue?

As one who firmly believes that even the smallest contribution is better than none, I am inclined to say yes.

Are We Doing Our Best on Frontend Development? This Data Perspective May Help Answer This Question was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.