• Search results
December 1st, 2015

Project Four Recap - Web Performance

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).

Web Performance Project

Github

#PerfMatters

So the two courses actually had a lot of overlap in what is taught, but they do focus on two different specific angles. Both courses focus on how the browser goes about rendering a web page. The Document Object Model, CSS Object Model, and the Render Tree are explained in detail in the first course, which is taught by Google Performance Engineer, Ilya Grigorik. This is another fantastic course by a guest teacher that was packed full of useful info. The second course focuses more on how the browser renders the page with JavaScript involved. This course is taught in part by Google Developer Advocate Paul Lewis, who also makes the course easy to follow.

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 second course on Browser Rendering Optimization got a lot more into the nuts and bolts of things that I hadn’t been exposed to before. For example, how the browser can be forced to repeat itself by some simple lines of JavaScript code. The Critical Rendering Path for the browser goes as such: Javascript -> Style -> Layout -> Paint -> Composite. When You use JavaScript to do things to the Style or Layout of a page, you also force it to re-paint the page. If you involve those actions in a loop or are doing a large number of changes, you can be in for some serious performance issues. Layout and Paint changes are very costly to browser performance.

LIAR!

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.

Portfolio Page Optimization

For the second part of the project, things got a lot more interesting. Here, you are tasked with making the web app scroll smoothly at 60fps when scrolling up and down the page. When you scroll, there are tons of pizzas in the background that are moving with the page (doing their best to slow everything down). You have to measure the FPS in Chrome Dev Tools and isolate which functions in the JavaScript file are causing the issues.

Pizzeria Web App Optimization

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!

Author

Philip Bowles