Tailoring for performance

One source does not fit all

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.

vel-before-js-removal

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
With manipulation and patience, I used server-side logic and regular expressions to load only what was needed. Doing so, I was able to remove 5 JavaScript resources and 4 CSS resources from the homepage. Since one of these JavaScript resources was a jQuery library, I moved the HTTP request and moved any jQuery dependent code beneath the request. Testing the homepage in PageSpeed Insights and WPT got noticeable improvements.

vel-after-js-removal-pagespeed74

image04

Notice that not only does the page render sooner, it loads 0.8s faster!

Corralling JavaScript snippets
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.

image00

While using Yepnope, there wasn’t much of a performance improvement. Notice that the page renders sooner but visually completes 0.1s later. Given these results, I would still consider using YepNope to manage external JavaScript and CSS resources to maintain control over the order of asynchronous loads.

Let’s look at the progress from the start

image05

After losing some weight in the and using YepNope to manage the external JavaScript resources, we shaved off 0.860s from the page load time and about 0.80s from the start render time. That’s a pretty good improvement from simply removing those HTTP requests that don’t apply to the homepage and asynchronously loading what does.

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

Cover the Basics & Get the Tools
The O’Reilly Media web group monitors the daily and weekly performance of the various O’Reilly web properties with tools like Keynote, WebPageTest (WPT), and PageSpeed Insights. As a site is produced, the web team picks the low-hanging fruit (see how we started): image compression, spriting where possible, CDN usage, lazy-loading images, and moving any Javascript to the end of the body. Also, Yepnope.js was used for managing asynchronous loads.

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.

tags: , , ,

Get the O’Reilly Web Ops & Performance Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.