A Beginner’s Guide To Web Performance: 2

Part Two: We’ve Got Problems

Cole Brown
iamota insights
5 min readSep 6, 2016

--

In Part One, we introduced a number of tools to help you collect data on the performance issues with your site. Whether your site scored well or poorly, there may still be performance issues to address. But how do you identify what to fix first? In part two we will explore common performance shortfalls and offer suggestions on how to optimize each area.

General disclaimer: not all suggestions are fit for every website. Use your test results from PageSpeed Insights, WebpageTest, and any user testing you may have done to determine what fixes may apply to you, and be sure to retest after making changes to see the impact. We suggest testing each change in isolation to best understand what provides you and your site with the biggest performance gains.

Images

Since 2012, bandwidth spent on images has increased over 400%, making images the most ubiquitous source of performance shortfalls on modern websites. Creating an image loading strategy can help with both the objective and perceived performance of your site. We recommend:

  1. Wherever you can, convert images from PNGs to progressive JPEGs. Users downloading your site over data will appreciate this the most, so make sure you optimize them for both CMS-generated photos and build deployed photos. Already doing that? For a bleeding-edge approach, try implementing WebP for even better performance improvements by converting both JPEGs and PNGs to WebP and serving fallbacks using the <picture> element.
  2. Ensure all images are sized appropriately for their content areas. Pick sane maximums for full-bleed banners and content areas — you shouldn’t load a 960 px content image in a 180 px wide thumbnail area. As mobile devices are increasingly the primary device used to access the web, your 5,000 px wide iMac is the exception, not the norm.
  3. Improve your perceived performance with a lazy-loading image technique. Lazy-loading allows you to choose to serve different sized images at different breakpoints, meaning you can optimize image sizes per device. Additionally, you can choose to deliver images nearly immediately with a “blur-up” technique (like one used here on Medium), thanks to initially loading micro-sized images. The perceived performance gains with this technique applied to areas like hero banners can make a huge difference to your users, especially over a mobile connection.
Side by side comparison of regular versus lazy-loading techniques over simulated 3G. 16 x 9 px images are used, which load almost instantly using the blur-up technique.

Scripts

With every tool your website references, from analytics trackers to utility plugins to ads, a script is included in the resource stack of your site. This can impact your performance in a few ways: by increasing the weight of your page, delaying the loading of other resources, and needing to be downloaded regularly due to low expiry times. Since most of the services you might include on your page are presumably doing something necessary, optimizing scripts requires a “weight without the wait” strategy:

  1. Be sure that your scripts are being included in the footer of your website, including application scripts, plugin scripts, and analytics or advertisement scripts, and set to load asynchronously. This means that all these scripts will not block HTML from loading on the page, allowing users to begin viewing content as soon as possible.
  2. Already loading your scripts last but hoping to continue to improve the perceived performance? Bundle critical Javascript away from your plugins, analytics, and ads, and load it asynchronously. Making sure your scripts for lazy-loading and navigational elements load quickly increases your users’ ability to navigate your site.

Webfonts

Like scripts and images, webfont usage has dramatically increased, from around 10% of sites using a webfont in 2012 to around 62% of sites using one today. These fonts can help your brand stand out in a sea of competitors, but you’ll need to make sure you’re delivering it optimally:

  1. Fix loading by killing that flash of invisible text. It’s a jarring experience at best and one that prevents your users from reading anything for seconds at worst. By providing some font-fallback styles, you can create a seamless experience for your users whether your custom font loads fast, slow, or at all. For a robust solution, consider implementing Web Font Loader from Google and Typekit as a way to serve a variety of webfont formats.

Server

Now that you’ve resolved any issues with your front-end code, it’s time to take a look at a few server configurations that could be negatively impacting your performance. Combining the features outlined below can greatly increase the performance of your site:

  1. Enable gzip compression for your site. This is relatively simple to enable on your web server and goes a long way to reduce data transfer from your web server for basic file types like HTML, JS, and CSS.
  2. Expires headers should be enabled and customized per resource in your server configuration files. They help direct browsers to cached versions of your static content, helping you increase performance on repeat visits for your users.
  3. Enable keep-alive to handle more requests with fewer connections. For modern web servers, setting the connection timeout to 5 seconds will help with load times in most cases, and still hold up under heavy usage. If you’re still concerned, test this setting over a 24 hour period and compare the results. If you’re seeing faster load times within acceptable memory usage, keep-alive should be enabled.
  4. When you’ve completed your server performance tuning, it’s time to retest your time to first byte (TTFB). The ideal TTFB for your project depends on factors like server technology and audience, but generally lower is better. A very high TTFB can be affected by many variables, so testing to see what the root cause is may take time. Pay attention to things like hosting infrastructure and the usage load to determine if a change in server architecture is the right move.
Comparison of keep-alive disabled and keep-alive enabled server under a 100 user load test; keep-alive with a 5 second timeout delivers resources more quickly than a server without keep-alive.

Next Steps

Addressing issues is not a one-time fix, and to help prevent your now highly performant website from gaining back the bloat, you’ll need a performance plan. Check back here for Part Three, where we will cover the whys and hows of creating a performance plan for your website or your development pipeline.

--

--

Cole Brown
iamota insights

(they/them) Front-end developer with a web-performance focus. Asexual activist, mentor to minorities in tech, civic tech advocate.