When your brand can own the narrative.
We created an online hub of original, interactive content that connected Newark element14 with a wider audience of engineers and makers.
Read the Case Study
In past blog posts, we’ve talked about the importance of website speed, how to really understand what it is and the impact it can have on your marketing efforts. What we haven’t discussed yet is how to improve your site speed.
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.
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;
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. Lets 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)|
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 #||Type||Size||Item Time||Group Time|
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|
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.
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|
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, I am 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.