Website Speed Optimization: Asset Requests
There are many tactics we utilize to increase site speed, anything from content delivery networks to image optimization. One of the most effective techniques is optimizing asset requests. Let’s look at what assets request are, how they affect your site and explore an example of a client’s site where we created a 65% decrease in load time.
Before we begin, let’s define a few terms. When talking about front-end website development, we are talking about anything that happens in your browser and excluding anything that happens on the server, which is what we call back-end development. If you are interested in learning more about the difference between front-end and back-end development, Tree House has a great article that goes into more detail.
Asset Requests
To understand asset requests, you really need to understand what a web page is. A single web page is made up of different pieces that your browser puts together to create a complete page. The easiest web page assets to identify are images. Image assets are imported by your browser from another location to display on the page. Just right click on any image and you can open it in a new tab. This will just open the actual location of the image. There are many other types of assets many of which you can never seen in the browser here are few common examples;
- Hyper Text Mark Language (HTML) – HTML files are the bones of any web page, containing the majority of the actual content and site structure.
- Cascading Style Sheets (CSS) – CSS files are used by the browser to change the way the page displays on screen, things like color, position, and size are set by these assets.
- Javascript (JS) – JS typically are used to created the interactions and much of the animation that websites perform
So when you open up your favorite web page, the web page tells your browser all the different elements it needs in order to show you for a complete page. Your browser then retrieves all the different elements and puts the page together, similar to a chef with a recipe. The main page is the list of the ingredients and your browser is the chef. The page says you need these images, and you need this css file and need these javascript files. Your browser follows the recipe, gathers all the ingredients, adds them in the proper order and mixes them together to create a complete page.
When your browser goes and gets the elements it is called an asset request. Every time your browser needs to get one element it adds more time to the process. Let’s do a little math to figure out what this actually looks like. The following chart show what it would take each assets to download on a cable connection at 5 kb per millisecond.
| Asset Type | Size (kb) | Time (kb/ms) |
|---|---|---|
| html | 10 | 2 |
| css | 20 | 4 |
| css | 20 | 4 |
| js | 15 | 3 |
| js | 15 | 3 |
| font | 20 | 4 |
| image | 50 | 10 |
| image | 60 | 12 |
| image | 30 | 6 |
| image | 40 | 8 |
| Total | 280 | 56 |
As the chart shows, we ended up with a total of 56ms to download 10 assets. However, we can also take into account that our browser has few extra hands than our friend the chef. Your browser can typically download 4 files at a time. So, if we break our assets into groups of four and account for the longest time, then we have 2 groups of four assets and 1 group of two. We get the following chart instead cutting our time down to 24ms.
| Group # | Type | Size | Item Time | Group Time |
|---|---|---|---|---|
| Group 1 | html | 10 | 2 | |
| css | 20 | 4 | 4 | |
| css | 20 | 4 | ||
| js | 15 | 3 | ||
| Group 2 | js | 15 | 3 | |
| font | 20 | 4 | ||
| image | 50 | 10 | ||
| image | 60 | 12 | 12 | |
| Group 3 | image | 30 | 6 | |
| image | 40 | 8 | 8 | |
| Total | 280 | 56 | 24 |
Here is where we start to optimize. In the above set of assets we have 2 css files, 2 javascript, and 4 images. What if we can combine those groups down to one of each type? Well we can do exactly that, watch what happens to our chart.
| Group # | Type | Size | Item Time | Group Time |
|---|---|---|---|---|
| Group 1 | html | 10 | 2 | |
| css | 40 | 8 | 8 | |
| js | 30 | 6 | ||
| font | 20 | 4 | ||
| Group 2 | image | 50 | 10 | |
| image | 60 | 12 | 12 | |
| image | 30 | 6 | ||
| image | 40 | 8 | ||
| Total | 280 | 56 | 20 |
So 4ms probably doesn’t sounds like much but when you are decreasing from 80 to 40 you can cut times in half! Additionally, we have one more factor to consider. For every group of requests your browser has to open a new connection, this adds time for every group. Depending on your server, this can be very large and in this case it is 52ms. Watch what happens when we account for opening new channels and start adding more requests (assuming all of our files are 25kb).
| # Request | # Groups | Time | Connection | Total Time |
|---|---|---|---|---|
| 20 | 5 | 5 | 270 | 295 |
| 40 | 10 | 5 | 540 | 590 |
| 80 | 20 | 5 | 1,080 | 1,180 |
This is all setup in an ideal world where nothing changes, in real life every time you make a request no matter what the speed of your internet connection things can change, server might be processing other requests or something they just don’t connect. So, every extra request can add anywhere from one to hundreds of milliseconds to your site speed.
A Real World Example
One of the most difficult things to do is to go back and optimize a website. However, when you start building a site, you can plan and build the site with optimization. Recently, we had an opportunity to both optimize and redesign a website for Dotcom Distribution. Check out these beautiful and speedy results.
Let start with the numbers. In the following chart you can quickly see that the difference in every stat starting with the number of request and the total size of downloaded files and how quickly that adds up.
| Site | First Byte | Start Render | Time | Requests | Bytes In |
|---|---|---|---|---|---|
| Original | 1.455s | 2.698s | 9.698s | 61 | 3,841 KB |
| New | 0.191s | 1.393s | 2.023s | 25 | 728 KB |
While these numbers are pretty impressive what do they actually mean? The following gif visualizes the difference in load times. On the left is the original site and the right is the new site, the images are taken every second as the sites load. Note that even thought it is 4 sec before the new site is finished loading the images, at 2 sec most the site is loaded and the image view is already there.
Notice the difference between the new site and the old site. The new site is fully loaded in less than 3 sec while the old one is still just getting started.
Think about the last time you waited 9 seconds for a site to load for you? What about even 4 or 3 seconds? Did you even stay around and watch it finish loading? If you did, we’re guessing you weren’t happy about it. After launching Dotcom’s brand new site their bounce rate dropped from 58% to 33% percent, which means a higher percentage of users are staying and actually looking at the site. Don’t get me wrong, the awesome new design and rewritten content plays a role, but no matter how good the design and content, if your users have to wait to see it, they won’t stick around.
As you can see, site load time is extremely important for your website. Have questions about optimizing your website’s load time? Sign up for our free web analytics report to learn about your website’s site speed.