Performance Improvement is not Performance Optimization
Performance improvement is the art and science of making online applications faster, while performance optimization is the art and science of making online applications efficient. While these two concepts are very closely related, using the homepage of a high-end specialty retailer, this article will show how a focused performance optimization effort can
- Shrink page size by nearly 40%
- Decrease Hosts and Connections on the page by up to 50%
- Improve overall response time by 40% as a result
- Have little or no effect on the overall site design seen by customers
Even optimization can’t find every issue, and it is often these lower priority or browser/device specific items that become roadblocks in succeeding in both performance improvement and optimization efforts. We’ll highlight how one overlooked item inadvertently affected the performance for a large group of customers.
The Case for Optimization
While it is not always true that performance improvement requires performance optimization, it is almost universally true that performance optimization leads to performance improvement. Improvement can sometimes be achieved through methods that don’t require any deep inspection of site mechanics (CDNs, adding more hardware, etc.), but optimization relies on clear thinking about how individual applications are built and delivered to the customer with an eye to addressing fundamental questions such as
- Do we know where all of the third-party content on our site originates? Can we quickly and effectively control or disable poor performing third parties?
- Do we have standards for image size, resolution, and quality that all content providers in the organization adhere to prevent the inadvertent slowing of page response?
- Do we audit the site regularly to detect content that does not meet the standards or may be causing performance issues?
- Have we verified that all optimizations work with the top 5 customer browsers and devices?
An organization focused on performance improvement would be immediately drawn to the slow objects at the bottom of the waterfall, with a focus on determining the root cause of the slow performance and identifying internal applications or third-party services that needed to be investigated.
Companies that have included a focus on optimization in their performance analysis would also ask another question: Does the performance of those objects affect the customers’ perception of page performance?
Following web performance best practices, objects that provide services that are not directly related to the business purpose of the page – analytics, customer feedback polls, advertising, customer support chat services, etc. – are placed below the most critical content to prevent this important but not critical additional content from accidentally interfering with the customer experience.
For the page being studied here, the objects at the bottom of the waterfall should be investigated for their effect on the complete page load time, but the customer who is visiting the page probably was interacting with it before these objects finished downloading.
Let’s start with the good news: repeat visitors don’t have to load these files across the internet every time they visit the site. The team that initially configured this site placed a heavy reliance on client-side caching for follow-on requests. Comparing a first-time visit and to a returning visit in AJAX Edition shows that the cached column only captured the first 4 requests returning to the origin server on the page reload, with the remaining CSS and JS files being pulled directly from the browser cache.
Optimizing the Page
All of the data above indicates that the page could get faster through means other than acceleration. With the help of Joshua Bixby of Strangeloop, I ran the sample site through their automated Front-End Optimization (FEO) algorithm. The Strangeloop system returned results strongly indicating that there is still more that could be done to improve performance through optimization.
The team that develops and maintains this site should be easily able to ask and answer questions, like:
- Can we reduce the number of CSS and JS files through consolidation and minification?
- Is it better for customer experience to spread loading of CSS and JS files throughout the site on a need-to-use basis rather than loading all required CSS and JS files on the first page?
After asking these questions, then developing, implementing, and testing the optimization answers, the development and business teams can make a deployment decision that ensures that the performance optimization process does not interfere with the desired customer experience in a way that affects brand and revenue.
This site serves as an excellent example of performance optimization at work. A week after the initial data was collected, the number of objects on their page was cut by more than a half, having a dramatic effect on all aspects of the page construction and performance, including a 1.5-2.0 second performance improvement.
Now that this optimization effort has been completed, is it time to stop? No, because there are likely further optimizations that will be discovered that will drive other incremental improvements.
Missed One – Browser-Specific Optimizations
The site made great strides forward. Except in one area – cross-browser compatibility.
Deeper examination of the data shows that the page delivered for Firefox – the primary study engine so far – is now approximately 577,000 bytes, down from 924,000 at the start of the data collection. But this page size reduction does not transfer to the page delivered to IE8 users, which remains at nearly 920,000 bytes.
The clearest reason for this is in the size of text elements on the page. Where Firefox average 57,000 bytes of text content, the IE measurement averaged 130,000 bytes.
If the majority of your visitors use web and mobile browsers that are from the last 5 years, these filters are most likely unnecessary, and sites such as Yahoo! have removed these filters to prevent accidental performance issues such as this.
[NOTE: If you have customers who use versions of IE that should have been made extinct over 10 years ago, their performance experience is likely not something that you can plan for, and your site is only one of many where these customers will experience performance issues.]
Changing the mod_deflate rule to remove the delivery of uncompressed content to IE users is a very quick fix, that often only requires a server restart after the edits are made in the Apache configuration files.
The Case for Optimization and Improvement
This one page provides an example of how optimization can benefit performance improvement. The team that built the site understood how the components worked together, and what they needed to do to ensure that performance improvement and optimization efforts were successful without affecting the customer experience or the bottom line.
While the automated solutions are growing in sophistication and popularity, the manual approach is still the recommended first step. The best use of an FEO solution is to elevate page optimization to the next level, not use it as a crutch to support inefficient page design practices.