Automating FEO: How much is your developers' time worth?
Contributed by Grant Ellis.
Freeing up the time of top developers is one of the primary benefits of implementing an automated FEO solution. That being said, the question of exactly how much manpower can be saved by automating this process has seldom been properly addressed.
To people in the web performance optimization industry, the answer to this may seem obvious. But for those who haven’t tried optimizing pages by hand, this discussion should be helpful.
First off, who is affected by the issue of developer ROI?
1. Those who write code themselves or have coders on staff.
2. Those who have a financial or productivity-related interest in the performance of a particular website.
3. Those who update or change their website often, and/or have content-rich pages.
Let’s look at Sears.com It’s a good example because the site matters, it’s dynamic, and they care about performance.
Trying to frame this problem is hard because you can look at it from different angles. What we’ll do is look at a couple of key front-end performance rules as described by Steve Souders in the context of different perspectives.
In this example, we’ll address two key performance practices:
1. Reducing the number of HTTP requests.
2. Adding an ‘expires header.’
Reducing HTTP Requests
Perspective 1: One page, one browser
If a site never changes, performance tuning is much easier. Unfortunately, this strategy won’t work in today’s ecommerce climate, where sites are highly dynamic -- many changing daily.
To observe how much sites change over time, have a look at tests over the last year from Sears.com as summarized by the HTTP Archive.
Visual: Looking at the video below, you can see how much the site has changed visually over the past year.
Behind the scenes: As the graphs below show, this site is constantly changing. The content changes, the number of requests change, and the number of domains change. Though dramatic, this type of continuous transformation is quite common.
As these graphs illustrate, the basic composition of this page changes dramatically over the year.
Why it's expensive to hand code
Minimizing server roundtrips is a major key to making pages faster. Many of the techniques to minimize roundtrips involve combining objects together into packages. If the content is always changing, then these packages also have to change. Keeping packages updated is arduous and time consuming, not to mention fraught with the potential to make mistakes.
The key ROI from automation for dynamic sites is the ability to offload all of the packaging time and effort onto a computer. It saves time, and it reduces error.
Calculating savings
A few caveats on ROI calculation: Calculating cost savings is best done on a case-by-case basis. The numbers cited in this post are from our experiences working with customers that hand code their pages.
Formula: By implementing automated FEO for resource reduction in this context, we would estimate 5 person-days of dev/QA time saved for every major content change on the site.
Perspective 2: One page, many browsers.
Changing packages as content changes is hard and costly to do by hand. Changing packages to take into consideration the performance nuances within each browser is a nightmare to do by hand.
Why it's expensive to hand code
Browsers don’t all support the same standards. As we’ve observed in the past, they can also change at a moment’s notice with disastrous effects if you are not careful. If you’re going to hand code by browser, not only does your matrix of supported scenarios exponentially increase, so does your QA surface. You also need to stay on top of all new browser developments and patches.
For a modern website with a standard user profile, you would need to do separate packages for at least five browser groups.
Calculating savings
In any large organization that performs FEO by hand (think Google, Facebook, etc.), they have a team of browser experts.
Formula: Depending on the size of your organization, we would factor in at least one browser expert and a 1.5x increase in front-end development time and a 2x increase in QA time if you’re going to undertake a per-browser optimization path.
Perspective 3: One page, many desktops + mobile
You probably already get the point, but it’s critical to break out mobile, as it makes front-end optimization way more difficult. Resource reduction is totally different in a mobile context, so you need a totally different skill set to conduct mobile FEO.
Why it's expensive to hand code
As someone once said: Nothing doesn't change in mobile. Standards change quickly. Browsers change quickly. Handsets have very different capabilities, and testing is a huge pain.
Calculating savings
Most of the organizations we know that perform front-end optimization by hand have a totally dedicated mobile team (on the dev and QA side).
Formula: Calculate at least at 2:1 ratio of front-end desktop to mobile team members and a 2x increase in workload if they are going to perform these tasks by hand. You also need to factor in the costs of all the different devices and related plans.
Perspective 4: Many pages, many browsers
Resource reduction is difficult across pages, and can actually slow you down if done improperly. One of the key benefits of a good automated FEO tool is the ability to juggle all of these different packaging combinations and provide the optimal package.
Why it's expensive to hand code
Given the amount of change seen in a modern site, hand coding in this scenario is nearly impossible. If you’re just going to put a few common files into a package and reference it everywhere, this problem is much closer to perspective 1, but that's not good enough to gain maximum performance.
Calculating savings
The ROI here cannot really be measured in person-power reduction, but simply in the value of site speed. If you're crazy enough to try to do this by hand, be prepared for months of extra development and a whole lot of pain.
Adding an Expires Header
Adding an expires header is easy. All of the difficulty arises from having to add the right header to the right resource and then to deal with version changes.
Imagine a simple example in which you add an expires header of 24 hours to a resource called logo.gif. Now imagine three hours later that the image changes but the name stays the same.
You now have a problem because everyone who has logo.gif cached will not request it again for 24 hours (or, to be exact, 24 hours minus the time elapsed since they first received it). This is a big problem because now you have people seeing stale content, and stale content is not acceptable.
To deal with this issue, organizations often have poor caching headers or else they embark on the long process of building a sub-system to version objects and control expires headers. They also need a vigilant operations staff to find stale content and they need to keep someone glued to the CDN purge tool. (Purging on a CDN is typically done manually or else you need to burn development hours integrating with their APIs. This becomes more complicated if multiple CDNs are in use, since no two are the same.)
Why it's expensive to hand code
Proper object versioning and header management is time consuming and expensive to code. Without it, you risk stale content or more roundtrips because your expires headers are not optimal.
Calculating savings
Building a proper version control and header management sub-system is expensive (think many person-months of effort). You also have to factor in the time you spend manually purging CDN caches, as well as the damage that stale content does to your brand.
Other key considerations
This post just scratches the surface in terms of ROI benefits when it comes to automating FEO. We could go on, but for now here are a few other considerations:
Third-party content
As we know, managing third-party content is costly. It also requires a great deal of vigilance to ensure you don’t have SPOFs or poor performance because of the third-party content you are forced to add to your site. Automating performance offers significant dev ROI because good FEO tools will help manage your third-party tags and place them in the right order. Your FEO vendor should save you countless hours in the trial and error process of moving tags around.
Image sizes and resolution
Images are one of the biggest performance challenges and many organizations spend a great deal of time optimizing their images by hand. One of the big time savers from automated FEO is the ability to have all of this work happen automagically.
Using a CDN
Automatically renaming files so they can be served from a CDN can be time consuming. One of the benefits of automated FEO is the ability to quickly get onto and change CDNs, thus saving devs a lot of time.
Final thoughts: ROI is about more than just short-term savings
Great developers are a key asset, and FEO is a tool best used in conjunction with this talent – not as a replacement. If you run a successful modern ecommerce site, you need great developers working on hard problems. The purpose of automated FEO is to let them work on different problems — in some cases bigger problems.
Offloading the arduous task of automation frees your team to climb bigger mountains and to continue to innovate.
Improve website performance across all browsers, automatically
To learn how Strangeloop can help accelerate your page load times across all major browsers, visit our Site Optimizer or Mobile Optimizer product pages.
