Like a lot of web teams, O’Reilly’s web group has increased its focus on using global components to better scale maintenance and optimize workflow. From a load-time measurement perspective, our performance ratings stay near benchmarks. However, after a recent analysis, using metrics other than load time, we found that our global efforts may have sacrificed performance on a handful of highly visible and heavily visited web pages.
Identifying the popular pages, we sought to improve the use of global components with server side logic, regex, and asynchronous loading. After re-measuring these popular pages, we arrived at faster load times with improved perception of speed.
Taking a closer look
After the Velocity 2014 site was produced, I got the following results from PageSpeed Insights and Webpagetest (WPT) while testing the homepage. These results are close to our average benchmarks for load time but revealed further elements to fix.
PageSpeed Insights pointed out render-blocking scripts and advised how I can optimize CSS delivery. WPT provided a visual UI to demonstrate the user’s perception of speed and gave me an average load time and start render time. Together, these tools gave many angles of approach to improving load times and the perception of speed.
Even though the load and start render times from WPT weren’t bad, the PageSpeed Insights score demonstrated that further improvements could be made.
Global components impeding performance
PageSpeed Insights pointed out several external resources that were delaying the load of above-the-fold (ATF) content. These HTTP requests were coming from a global component that’s included throughout the Velocity website. For some pages, these HTTP requests are crucial to properly load content and user interaction components, but it was unknown that these HTTP requests should be removed from the pages that didn’t need the resources. The global include of the HTTP requests across the site had the purpose of maintaining reusable code, but it didn’t make sense to keep it on pages that didn’t use the loaded resources.
Losing the <head>ache
Notice that not only does the page render sooner, it loads 0.8s faster!
By this point, you’d think I would be satisfied with the results but I started thinking I should defer or asynchronously load the jQuery library. I wondered how I could manage all HTTP requests while maintaining the order in which they load.
Thank you, YepNope.js
YepNope is an asynchronous conditional loader that loads external files in the order you request. By using this 1.7K (gzipped) file, I asynchronously loaded jQuery and it’s dependent script resources, then executed any function calls upon completion.
Let’s look at the progress from the start
My biggest takeaway from this performance makeover is that maintaining a single code source for a website may unintentionally sacrifice the speed of a single highly visible page. It’s important to prioritize the most popular pages on your website and make them as lean as possible to create a better user experience. It may be time-consuming, but it’s worth it if you keep your users happy.
Stay tuned…further improvements regarding CSS optimization will be covered in another post.
Note: All WPT tests were ran with test location: Dulles, VA using Chrome as the browser and a Cable connection.
To learn more about how you can tailor your site for performance, check out the Velocity 2014 Schedule.