Things I Learned Last Night at a Web Performance Meetup

The analysis meetings are smaller and sort of unstructured. Attendees simply ask to have a site reviewed for performance optimization by the group. Despite being tuned into the web performance culture there is always things for me to learn. Last night was no different, but I would like to go over some points we covered analyzing the two sites covered.

The primary performance analysis tool we used was WebPageTest.org, but we also used browser F12 tools and Google Page Speed test tool. So the analysis was primarily synthetic, but generally this is good enough to find low hanging web performance fruits to prune.

NYC Web Performance MeetupLast night I attended a New York Web Speeders meetup at the Manhattan Akamai office. Sergey runs a great group that meets twice a month. One meeting is a presentation, the other a site analysis meeting. Last night was an analysis meeting.

The analysis meetings are smaller and sort of unstructured. Attendees simply ask to have a site reviewed for performance optimization by the group. Despite being tuned into the web performance culture there is always things for me to learn. Last night was no different, but I would like to go over some points we covered analyzing the two sites covered.

The primary performance analysis tool we used was WebPageTest.org, but we also used browser F12 tools and Google Page Speed test tool. So the analysis was primarily synthetic, but generally this is good enough to find low hanging web performance fruits to prune.

The Ichan School of Medicine at Mt Sinai

The first site we were ask to review was the Ichan School of Medicine at Mt Sinai. They recently deployed a new home page and are in the process of rolling out a new design through out the site. We focused on the home page and spent about an hour discussing various issues we found.

Ichan School of Medicine at Mt Sinai

My Web Page Test runs can be found here. Some quick facts:

  • Scorecard A - First Byte Time A - Keep-Alive Enabled D - Compress Transfer F - Compress Images F - Cache Static Content X - No CDN Used
Mt. Sinai School of Medicine Web Page Test Scorecard

Images

This is always the biggest issue with most sites. Today's design trends rely on large, higher definition photography to create visually engaging sites. The Mount Saini page is no different. There is a rotating background image that consumes a large amount of bandwidth.

There are two ways the site could optimize images. First is to run them through an image optimizer. My favorite is Kraken, but the group also recommended Compressor. For the record Kraken costs money, but has a wider range of images it can manipulate. It also has an API that is easy to use. I compressed almost 6000 images one night last month via the API and auto deployed them to Azure storage. Compressor is free, but only offers the web interface, which Kraken also offers.

When I ran one of the images through Kraken I shaved 26% off the file size. Looking at the Web Page Test analysis the site could trim over 2.2MB total by optimizing images. That is huge! In fact it is over a third of the page's payload removed without degrading the experience.

"4,240.4 KB total in images, target size = 2,060.7 KB - potential savings = 2,179.7 KB"

Mt. Sinai School of Medicine Payload Breakdown

The other area they could optimize is utilizing properly sized images. The site is responsive, which is a big plus, but they load the large image for small screens as well.

We are nearing a time when browsers support responsive image solutions natively. Till then there are JavaScript polyfils. My personal strategy is to utilize the matchMedia API and drive the images via JavaScript media breakpoints. I have been working on a longer post about responsive images, so I will defer details till I am ready to post it.

But a quick responsive image summary is load a properly sized image for the view port. Don't load a 1400 by 900 image when you only have 320 by 480 pixels to render. Not only does this take longer to download the device's CPU has to work hard to decode the image then resize it. This is not only slow, but burns battery life.

Fonts

Everyone seems to need multiple fonts these days. I get why they think they need these fonts, but most of the time you should use the native fonts. I can read your article just fine with Segoe, Helvetica or Robotica. Microsoft, Apple and Google have all chosen these fonts as system fonts because they are very readable.

Mt. Sinai is loading at least a half dozen fonts, plus font awesome. We could not find where these fonts were necessary and in many cases caused the page to render without visible text because the font had not loaded. This causes extra cognative load to the user, plus when the font does load it often causes a flash as the browser repaints the screen.

The City of Addison Texas

Next up was the Addison Texas web site. This one was fun since I go to Addison a few times a year to speak. The graphics are locations I am very familiar with by now, so it was neat seeing the site.

City of Addison Texas

My Web Page Test runs can be found here. Some quick facts:

  • Scorecard D - First Byte Time A - Keep-Alive Enabled C - Compress Transfer B - Compress Images F - Cache Static Content X - No CDN Used
City of Addison Texas Web Page Test Scorecard

Time to First Byte

The first issue identified was a 1.6 second time to first byte. This is a measurement of how long it takes the server to send the initial markup to drive the remaining asset requests. Here the server is taking way to long to generate the markup. For the record I ran additional tests and saw times in the 400-500ms range, still not acceptable.

Addison Texas Time to First Byte

The site is built using a CMS and PHP and taking too long to create the page. The reason this happens is a combination of things really. It could be a slow database query, congested or long rendering pipelines. Maybe it is just an overworked server. This can easily be solved by caching the response. The markup on the home page does not change often, so caching the response can be done for a long time.

In ASP.NET we would utilize Output caching. This prevents the server from running through the entire pipeline over and over to generate the exact same result. Instead it is run the first time and placed in memory for a set amount of time. Subsequent requests use the in memory, cached version. This enables your server to scale and your responses to be fast.

Duplicate Scripts

The next thing I noticed was some duplicate scripts. In this case loading jQuery and jQuery UI twice. Once from the CDN, the next via PHP on the server. loading the scripts twice doubles the payload and execution time. This performance issues could be easily fixed by removing the php generated request. I recommend removing this reference because using the CDN hosted files are a better practice.

You want to avoid loading multiple script and css files for more than just payload issues. Often when you see this multiple versions are being loaded. This means the first requested version is completely overwritten by the second. This can cause bugs and other quality control concerns. For CSS rules are duplicated and overwritten and layouts can be broken.

Addison Texas duplicate script references

The page also loads the same modernizr file twice as well as duplicate inline scripts. The inline scripts and duplicate file references indicate the site is composed of various include files maintained by lazy developers. This is a very common issue and here is how it happens.

A developer is tasked with creating a component, as an include or ASP.NET partial view. They use a JavaScript library or CSS file. To make sure everything is included when the page is composed they toss in a script or style tag to inline their dependencies or make sure the external file is loaded. There is no process in place to bundle and minify the entire solution or something to ensure there is are optimized external dependencies.

Ideally there would be a single script and a single external CSS file reference to the page or application. Sometimes you just can't do this, but it is rare if you build sites like I do. When HTTP/2 becomes common we can skip the bundling step, but until then you should.

Summary

Most web sites and applications have simple things development teams can do to ensure their pages load instantly. Unfortunately most developers are still unaware of how to properly build web front-ends. The Mt. Sinai and Addison Texas web sites are no different. Each of these sites can have their load times radically improved by spending a few hours to make some changes. These changes quickly raise the user experience, which in turn increases the return on the web site investment. Remember a web site is there to help your business or organization succeed. Always keep your customer's user experience first. Performance is a technical aspect you can easily control and receive immediate payback.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel