May 10, 2016

Making Our Sites Faster, Part 3: The First Rounds of Improvements

This is the third post in a 4-part series discussing performance on the GeorgiaGov platform.

I’ve been talking a lot about the importance of fast page loads and smaller page sizes (the data that makes up a web page). Two weeks ago I showed you some results of our initial page speed tests, and showed you how we measure up against similar sites. I also explained our goals to improve our platform performance wherever we can; rather than try to meet an arbitrary number, we will continue to tweak code where we can and test to see which improvements are making a difference.

In conjunction with our code cleanup a couple months back, we identified a module that will compress and combine JavaScript and CSS files so browsers have fewer files to load — meaning fewer server calls, which theoretically means faster page loads. We also made some other small updates to our theme files and backend code that were expected to improve performance a little bit. We were eager to test our performance after making those improvements, and share with you our first round of performance updates.

First Quarter Results

I’ll be honest. After our first round of testing, things weren’t looking too good. We hit a lot of walls and were seeing a negative impact on our work. We had cleaned up our code and implemented the JavaScript and CSS Aggregation module, and … suddenly many of our sites were loading much more slowly than before. (Cue the sad trombone).

How did this happen?

We beat our heads against the walls, re-ran tests, and puzzled over the results. Slowly things started to come into focus. In some instances, it wasn’t the size of the files slowing things down. It was the time to connect to external tools, like Google Analytics. That connection happens in the background at the very end of a page load, so it isn’t actually slowing down the user’s perceived page load experience or inhibiting visitors from accessing content.

But that wasn’t telling the whole story. The numbers we were looking at and comparing against were too broad for it to be just that.

We also noticed another server call to a small piece of functionality all the sites use that has started to take an unusually long time to load. Again, we were getting somewhere. This should be something we could fix. Phew!

Lastly, we noticed that some homepages were taking longer to load due to changes to its content! More specifically, some agencies had added new images to their rotators. Something that puzzled us initially seems obvious now that we realized content was affecting it. Why yes, if you add two new large feature images to your rotator, your page will load more slowly. If you remove one, it will load more quickly. Another mystery solved.

But Wait, There’s More!

As we were digging into all of this, looking more closely at our performance results and brainstorming ways to improve, we finally noticed something that had been staring us in the face all this time. Many of our platform’s theme/layout images are not optimized.

What.

We’ve been so focused on compressing JavaScript and CSS, and doing all these little tweaks to improve performance. All this time, we have barely noticeable background images that could easily be resaved to be 120 kb smaller in some cases without losing image quality.

It just goes to show you that even the design experts (and believe me, we had minted and celebrated industry experts from our vendor shop working on our themes) sometimes forget about things like image compression

This One is Easy

Again, this is something we can fix. So our frontend developer went to work updating and compressing our image assets across all of our 16 platform themes. She primarily used free online tools such as compresspng.com and compressjpeg.com, in some cases using Illustrator to recreate icons that were fuzzy in compression to resave them in a smaller, crisper version.

Depending on the theme, were able to decrease the total page load when a user first visits a site by between 20 kb and 400 kb, with an average of about 200 kb reduction per site.

That’s 200 kb less data downloaded each time a browser visits one of these sites for the first time. That’s approximately $0.01 per visit on mobile — which seems like nothing until you learn that across the platform, we had 1,765,735 mobile visitors in the last month alone. We’re talking about a potential of approximately $17,000 we can save constituents per month — just by compressing some images.

We’re still putting the finishing touches on the image compression work, so this change isn’t live yet. The updated images are slated to be rolled into our next monthly release at the end of May. Then we will re-run the performance tests to confirm whether we see the improvements we’re expecting from such a massive reduction in files sizes.

Like anything else on our platform, this is a team effort. We make improvements on our side, but to see the full impact of potential improvements, each agency’s content managers need to be on board and doing their part. In my next post, I’ll give you a rundown of some performance quick wins for content managers — what you can do to improve your site’s performance and respect your visitors’ bandwidth.

Related Posts

Related to: