(upbeat music) - Hi everyone.
Before we start talking about trends and stats, let's quickly address the data source from which this entire talk is using.
HTTP Archive is an open-source attempt to track how the web is built.
And it does this by crawling, analysing and storing data of over 5 million URLs every month. These monthly datasets are massive, as you can only imagine when storing information of millions of sites.
Due to resource limitations however, only one page on each of the websites in the dataset is actually tested by HTTP Archive, and that's the homepage. It's always important to keep this in mind when diving into the data and attempting to come up with any conclusions or patterns, because this is an important caveat.
So it's great that a tool like HTTP Archive is publicly available to anyone and everyone. But how can we actually read data from the project? There's a few different ways.
One of them is by using BigQuery, a data warehouse tool that makes it possible to perform large, big data analysis.
Instead of having to download all the raw data yourself, HTTP Archive is available on BigQuery, allowing you to run complex query on the dataset and resolve them quickly, thanks to BigQuery's processing power.
If you don't feel like running queries yourself, and will like to just see some high-level trends on different aspects of the web, the HTTP Archive website itself also provides many useful reports with graphs that chart all kinds of information every single month.
It's a comprehensive and detailed report that accurates a lot of information from HTTP Archive, but also combines it with the expertise of the web community in the form of Web Almanack.
And even the other important aspects of user experience like performance security, SEO, and e-commerce. the whole Almanack is extensive and I highly recommend taking a look if you're interested in understanding the current state of the web.
All the data used for this talk is from to HTTP Archives, July, 2020 dataset.
HTTP Archive uses a private instance of WebPageTest with private test agents running actual browsers on desktop and mobile.
But WebPageTest isn't the only technology used. Other tools include Lighthouse, an open source audit tool built by Google and Laplight, a tool for detecting what technologies are being used on a page.
having to be downloaded parsed, compiled and finally executed.
But what is too much? That entirely depends on network connections and devices used by consumers.
Even at the 90th percentile we're only looking at roughly a 5% difference between desktop and mobile.
Breaking it down by device client again, we can see that at the median, 20 requests are sent for mobile and 21 for desktop. In all percentiles, there's no significant difference between device type.
In terms of number more third-party requests are sent than first party at every percentile. And the difference grows at higher percentiles. Just to reemphasize this, we fetch more scripts for third-party code than we do for the first-party code that we offer.
And resource compression can be one of the most effective ways to minimise download time.
For both desktop and mobile, the number is about .8% of all sites.
So less than 1% of sites currently use NID of model support, which means that many sites are most likely still relying on older module loads like require JS for example.
What about source maps? In many sites, scripts are minified, or even initially used a superset like TypeScript that compile to an output that can look noticeably different from the original source code.
Source maps are additional files that can be used to tell a browser how to map final code output to its original source, which can make debugging and analysing a lot easier. However, there are many people who feel like shipping source maps to production may not be ideal.
I would rather only enable them for the development environments.
There's no right or wrong here and everybody's use case is different.
But I thought it would be interesting to see how many sites actually ship source maps to their production output.
And that number is about 14%.
In other words, for both mobile and desktop, 14% of sites include a source map for at least one script on their page.
There are many different tools that can be classified as a library versus framework, and that's a discussion of its own, but React, Angular and Vue are arguably some of the most popular clients that frameworks use today to build single page applications. In HTTP Archive, the usage of either of these frameworks makes up a 6.5% of the entire dataset.
Instead on contrast, 83% of sites use jQuery. Now this is not to say in any way that usage means importance or preference in the ecosystem because that's just not the case.
Most front front-end developers today would not likely use jQuery for a new site that they built. But the very interesting thing about the data is that it shows how expansive that jQuery became and how many sites still use it to some extent today. If you're interested in looking into real world user experiences and data specifically on sites that use frameworks, I built a dashboard called Perf Track that actually dives into this.
Now this is a core part of my work, it's something I find very interesting.
So if you do too, feel free to take a look. The first edition of the Web Almanack was a massive commitment.
There were a total of 93 contributors ranging from analysts, authors, developers and so on. Remember the Web Almanack is an annual report, and we're always looking for more people to help. If you're interested in any capacity, consider joining the team and helping out in the years to come.
I hope you enjoy this talk as much as I enjoy giving it. Again, everything we just covered only scratches the surface.
HTTP Archive and the Web Almanack are goldmines of information that I hope more people can start taking advantage of. My name's Houssein, thank you for watching. (upbeat music)