40 new videos on measuring front end performance and automating the tedious
Hey, it's Friday!
There's no reason you should have noticed, but usually I do this newsletter thing on Tuesdays. But it's Thursday night and a viewer just wrote a really polite email asking when more videos in the Front End Development collection were coming out. Would you believe that I've just been sitting here for the last few weeks with my palm hovering over a giant green "publish" button, just waiting for the right catalyst? Well, I wanted you all to know how much your voice matters. Thank you, polite writer. The publish button has been pushed with a vengeance.
This week we cover a lot of ground, using several of Chrome's DevTools features. An FED "ah-ha!" moment for many of us is when we realize that file size can be much less important than file quantity. In these videos we explain why that is and how we can measure the effect of downloading a plethora of files instead of mashing them all together in a single lump of a file.
Speaking of mashing files together (i.e. concatenating and minifying), it's not as much fun as it sounds. So, we begin the process of exploring automating boring, error-prone tasks with a tool called Grunt. This is good, good stuff. Freeing you all from all manner of tedium is part of my unwritten mission statement, and it's nice to cover a tool that is so good at that.
Enjoy, my friends!
PS: Hey, I know this email contains a load of screenshots and a fair bit of scrolling. If any of your email clients have a problem with the length of this newsletter, please give me a heads up.
After having reviewed our template in a couple of Mac browsers, we head over to Windows to give a couple browsers there a try, starting with Chrome.
Following up on Chrome, we test our template in Firefox for Windows.
Internet Explorer has long been the bane of many a front end developer. One challenge with IE is that there's not a reliable way to test multiple versions of it on a single machine, and sometimes using even a virtual machine can cause Internet Explorer to act differently than it would on a native installation. Here we talk briefly about a couple of strategies for testing multiple versions of IE.
Internet Explorer is still a popular browser, so it's important that our site be beautiful and functional in it. Here we give our template a spin in Internet Explorer 9.
Over the last several videos we've done a quick review of our template across multiple browsers, but this kind of review is only part of what goes on once you have a full functioning site in place. Here we point out how that kind of review might be different.
What we've covered in terms of front end performance, and what we'll cover now New! (This one's FREE!)
We've addressed front end performance a bit throughout this series, specifically when it comes to CSS. For the next several videos we're going to look at the other aspects of front end performance, including how to increase loading speed by reducing download sizes and the number of files we need for our site.
How to open the network dialog in DevTools and disable local caching New! (This one's FREE!)
The Chrome browser's DevTools "Network" dialog is a critical tool for identifying performance bottlenecks. In this video we demonstrate how to open it and how to disable local caching so that each time we load our page, it downloads fresh assets from the server. This way we can accurately reproduce what a visitor will experience the first time they visit our site.
Why front end performance (i.e. speed) is important New! (This one's FREE!)
In many projects you can get by without thinking too hard about front end performance. However, the research that's out there indicates that a second extra loading time can mean the difference between a sale and an unhappy visitor. Here we summarize some of research to give us a sense of why focusing on speed is important.
In this video we review some of the basic information that the network tab gives us, including the number of downloaded files and the size of each one.
Chances are that if you're watching these videos, you're a developer or aspiring developer, and you have a speedy computer to reflect your focus. If you are in a country with high-bandwidth internet, you might also have an above-average experience when it comes to using the web. Here we explain how we can't depend solely on our own experiences testing our web sites, but instead need to understand how other experiences can vary across the world.
How download size is often not the biggest factor in site loading speed New! (This one's FREE!)
Reducing the file sizes on your site's assets are sure to improve the loading speed of your site, right? Probably, but there are other factors that come into play that have a much greater impact on load time. Here we summarize what those are.
As we review the steps that went into downloading our index.html file, we walk through each step and explain what's happening. In this video we start with the "DNS Lookup" bar, which is the time it took to figure out the IP address attached to the domain of the site.
Once the browser knows the IP address of a site, it sends a request to the site to see if it's okay to start downloading files from it. Here we break down the parts of this request.
A couple of our steps outlined in the "Network" DevTools tab involve a request sent to the server followed by a message back. Here we explain how the terms "RTT" and "handshake" might be used to reference this exchange.
In this video we continue our walkthrough of the steps required to download a file. After a request is sent to the server and we get the OK to download, the browser sends another request or a specific file and waits for the file to come back.
It would be great if we had complete control over loading time for our assets, but there's a lot that's out of our hands. Here we review the different steps involved with the download and what we can and can't do to improve the speed.
By default, Chrome DevTools orders files in the Network tab a particular way, but that doesn't necessarily reflect the actual download order. Here we fix that so it's easier to review what actually happened during the download of our site.
We've gone through the step-by-step process of how a file is downloaded with our index.html file, and now we continue evaluating performance by looking at the next file that downloaded.
A web site is usually comprised of a number of files, and the browser will download several of these files at once to optimize the use of bandwidth and reduce the number of request that have to be sent to the server in sequence. Here we explain how this works and how to read the sequence of files in the Network tab of DevTools.
We just covered a lot of material around performance, and here we summarize how to read the file loading graphs in the Network tab.
There's one last mystery as we review what the steps are for each of our files to load, which is a clear bar in the loading graph for one of our images. Here we take our best stab at explaining what this bar is likely for since we were unable to turn up any documentation at the recording of this video.
Internet is surprisingly different across the globe. If you're targeting a specific region or building an international site, it's important to be able to look up what to expect so you can mimic various bandwidth scenarios with your template.
There are some nice tools out there for pinging a site (which just means making a round trip to a site) from various locations around the world at one time. Doing this can be a great reality check when it comes to determining how a site loads worldwide.
Why we're going to concatenate and minify our files, and why we'll use automation to do it New! (This one's FREE!)
We've alluded to how we're planning on concatenating and minifying files before, but here we summarize the reasons to do it and begin the process of figuring out the best tools for the job.
Now that we have a concatenated file, we can run it through a minification process to compress the file size down. In this video we explain what minification does in a bit more depth than we have previously, and demonstrate how to do it manually.
One more thing that we'll want to do that's tough to accomplish manually is swapping out our un-minified files for the concatenated, minified versions every time we want to push our project to production. Here we discuss why this is important, and how automation could really come to the rescue.
How automation can save time, reduce error and get a team on the same page New! (This one's FREE!)
Now that we've seen how painful it is to minify and concatenate our code by hand, we're in a great position to appreciate what automation can offer us. Here we summarize a couple of the major benefits of learning an automation tool like Grunt or Gulp.
There are several front end automation tools available, the most popular being Grunt and Gulp. For our project, we're going to use Grunt because at the time of this recording, it's still the most popular tool with the most extensions available. In the future, you'll be able to use many of the same techniques for other automation tools as well, as they become more widely supported.
How to install Grunt New! (This one's FREE!)
Here we install the Grunt automation tool so we can begin using it. Yea!
In the last video we installed a global instance of Grunt so we could use it anywhere in our file system, but here we install a specific version for this project only, making it easier for other teammates to install the correct Grunt version as well.
In this video we install our first Grunt extension, this one being the go-to extension for concatenating files.
In this video we test out some basic configuration by running the default Grunt task on the command line. Simple, but powerful!
Because Grunt tasks are tied to extensions, we often need to create configuration variations to be able to use the same extension in multiple contexts. Here we demonstrate how these variations work and how to trigger them when our tasks run.
Here we move a number of file paths over from our index.html file to our Grunt configuration.