Project Four focused on web performance and browser rendering. It was a bit of a mixed bag for me in terms of how much I enjoyed it. The video courses provided, Website Performance Optimization and Browser Rendering Optimization were both quality courses that had some good content. Unfortunately, it just wasn’t the most interesting content. This isn’t to say that I don’t think performance is an important part of the web, but it’s just not as fun to learn when you are first figuring things out and learning cool things like how to create your own game. However, the smart voice inside my head tells me that it makes much more sense to teach web performance early in someone’s web career rather than later. Trying to unlearn bad habits is much more difficult than not forming them in the first place. So I guess what I’m trying to say is that I understand why Udacity put this project in here when they did and I’m thankful that they did (even though it’s not the coolest flashiest most fun project).
While I learned a few things in the first course, such as using timeline traces for Google Chrome Dev Tools, I was already familiar with the DOM, CSS OM, and had a basic understanding of how the browser put that stuff together. I had also used Google PageSpeed Insights on a website that I had built before and felt like I had a good grasp on all of the basic things that they ask you to do to optimize the loading time for your website. Both of these courses delved deep into Chrome Dev Tools and I would highly recommend them for learning that alone. It was nice to learn how to use the Dev Tools in conjunction with learning why they are important and how to measure things for performance.
The courses also had some interesting numbers on performance, especially for browser rendering optimization. LIAR is a nice acronym provided that stands for Load, Idle, Animate, Response. Basically, you get 1 second to load the page initially, after that you have about 50ms where you can perform actions in an idle state that aren’t crucial to the first page load and you can delay a bit. All style, layout, paint (Animate) processes must be done within 16ms in order for the web app to perform at 60fps. Response time for actions performed by the user must be performed within 100ms in order to feel responsive. I thought this was interesting information and it also showed you how to measure these things in Dev Tools.
On To The Project!
Ok, so for the web performance project, you are given a mobile portfolio page for one of the instructor’s, Cameron Pitman, and asked to make improvements in order to get the Google PageSpeed Insights score above 90. Second, there is a web app included in the portfolio for a pizzeria with a bunch of spinning pizzas in the background and a slider to make them larger/smaller. The web app is insane and pointless, but it’s a great example project to focus on the browser rendering performance. You are asked to get the app run smoothly at 60fps and remove any ‘jank’ from the app.
For the first part, it is mostly small tweaks like moving your google analytics script to the bottom of the page, making script tags load with the async attribute, and doing basic minification of your CSS and JS. Extra credit is earned for setting up Grunt or Gulp to perform these tasks as well as image optimization. To start off, the page has a PageSpeed score of 27. By the time I finished, I achieved a 94. I figured that was good enough for tweaking someone else’s work! This was a fairly easy task for me, having dealt with many of these issues while launching my first client website a few years ago.
I must admit, this part was very challenging at first but it turned out to be kind of fun by the end of it. I’ve always struggled with refactoring code because I feel like I don’t understand it well enough but this project really helped me with that. By the end of it, I found myself comfortably moving lines of code around, deleting others, and rewriting them.
Most of the issues you are working to fix involve variables being declared within for loops. This will cause the interpreter to create a new variable each time the loop runs. If the loop is also calculating style or layout, this can get expensive for the browser rendering very quickly. The better alternative is to declare your variables outside of the loop and then the interpreter is only re-assigning the value for the variable each time rather than creating a new instance of it.
The other big one in this project that seemed to be a recurring theme to fix was changing querySelectorAll to getElementById or getElementsByClassName. querySelectorAll will run through all of the elements on the page and return any that match the CSS class you pass it. This sounds great (jQuery does this but much faster) but when you are using it in a loop or on a web app of this nature, it can bog down performance because you are constantly querying the browser for all of the elements on the page. The more elements on the page, the longer this action will take.
Overall I give this project a big thumbs up! It made me feel much more confident in my understanding of Chrome Dev Tools, web performance, browser rendering, and most importantly refactoring code. I finished up with a big “Exceeds Expectations” for the project!