Welcome!

Open Web Authors: Pat Romanski, PR.com Newswire, David Weinberger, Louis Nauges, Sarah Lake

Related Topics: Java, SOA & WOA, AJAX & REA, Web 2.0, Open Web, Apache

Java: Article

Top Performance Mistakes: Supersized Content

Top performance mistakes when moving from test to production

Because of the efforts of people like Steve Souders, John Resig, Sergey Chernyshev, Paul Irish, ... a lot has changed when it comes to optimizing web site performance. Browser and Application Performance Vendors built tools to make Web Performance Optimization easier than ever before. Web Frameworks are optimized to generate better web pages.

However, looking at the following chart reminds us that best practices, conferences and tools alone didn't succeed and building optimized web sites is getting even harder. As can be seen, the main problem with modern web sites is the growing number of resources, the size of the content, and the declining user experience that results from the first two items:

Page Size and Number of Objects on an Average Page doubled over a period of 12 months

If your testing efforts are not focusing on these metrics, read this graph as: "Let's test and optimize our page size!"

You don't want to spend endless test cycles optimizing your applications' "business logic" performance when the major impact of page load times come from too much multi-media content, JavaScript files or content from third-party providers. To prevent this from surprising you, all it takes is testing your application from the perspective of your real end user. This enables you to prevent "super-sized" web pages from hitting the public web. In this blog I show some examples of why pages end up being too big and how to identify these problems before moving them to production.

Example #1: Too many resources
Have you ever analyzed the pages of your application using tools such as dynaTrace AJAX Edition, YSlow, Google Page Speed or SpeedOfTheWeb? The following example is taken from a blog I did last year analyzing the page performance of retail web sites. It shows how many resources are loaded for a single page and how loading that many resources from a large number of different domains comes with the additional cost of Connect and DNS time per domain.

Many websites do not follow Web Performance Optimization Best Practices leading to very long page load times

When we compare this to another online retail store, it becomes clear that there is a lot that can be achieved by optimizing resources loaded on the initial page visit.

Testing and optimizing web sites on resources can lead to 5 times faster page load time

It's clear that not every web site can be optimized like this - but there is a lot of room for improvement and there are lots of easy wins we can achieve. Whether it's merging JavaScript files or using CSS Sprites to reduce the number of images, any or all of these are steps that make sure your web pages won't get supersized.

The statistics shown at the beginning of this post clearly highlight that the average web site is growing in size and complexity. To avoid this, it takes a testing team that focuses on Key Performance Indicators (KPIs) such as # of Images, # of CSS Files, # of external domains, # of used JavaScript Frameworks ... The Best Practices are out there; so are the tools. Now it only takes effort to implement them.

The good news is that testing and verifying these KPIs can be automated and integrated in your continuous performance test process. This avoids manually looking over the results of every single tested page of your application. Here's what it takes to implement it:

  1. Testing Tools that use real browsers in order to test downloads of dynamic content, JavaScript Times, ...
  2. Browser Diagnostic tools that analyze tested pages based on these performance metrics
  3. A Smart Performance Repository that automatically alerts on performance regressions

The following screenshot shows what continuous testing on these KPIs looks like and how to identify regressions immediately by monitoring these metrics for every page and for every test:

Analyzing Key Performance Indicators for every tested page identify regressions early on

Example #2: Heavy Third-Party Content
As already highlighted in the first example, it's not only your own content that can blow up your pages. You probably rely on third-party content such as Ads, Social Platform Widges or Map Services. If that's the case you want to make sure that:

  • Your pages only load the third-party content that is really needed, e.g, global includes in web projects may load third-party content on pages where not necessary
  • You include this third-party party content in an optimized way, e.g., why provide an interactive world map when all you want to do is show a static image of your address?

Klaus Enzenhofer wrote a great blog about Third Party Content Management applied - where he highlights the impact of third-party content and also how to test it. The key message is that you need to understand what type of third-party content you really need, how much impact it has on your page load times, and how to optimize it. Klaus did some testing with Standard Google Maps vs. Static Maps and how this one change can optimize your page load time while still relying on third-party content. The following table shows the difference when using these two ways of including the Maps Services on your page:

KPI

Standard Google Maps

Static Google Maps

Difference in %

First Impression Time

493 ms

324 ms

-34%

Onload Time

473 ms

368ms

-22%

Total Load Time

1801 ms

700 ms

-61%

JavaScript Time

563 ms

0 ms

-100%

Number of Domains

6

1

-83%

Number of Resources

43

2

-95%

Total Pagesize

636 Kb

77 Kb

-88%

For measuring the overhead of third-party content simply take the same tools as explained in the previous example. The following shows the timeline view of dynaTrace where the overhead of Facebook and Google+ are easy to spot:

Analyze your page load times to spot slow third-party content

Call-to-Action
Let's make sure that all the great work that has been done to optimize web site performance is not just left to the browser vendors - they won't be able to speed up your web sites by building a new JavaScript engine or by allowing the browser to download more content on more parallel network connections. Keep the following list in mind:

  • Make sure that these Best Practices are enforced early in the development cycle as well as throughout your performance testing
  • Monitor the critical Key Performance Indicators to ensure that your web sites don't end up super-sized
  • Test using real browsers and don't exclusively rely on protocol-based performance testing

More Stories By Andreas Grabner

Andreas Grabner has more than a decade of experience as an architect and developer in the Java and .NET space. In his current role, Andi works as a Technology Strategist for Compuware and leads the Compuware APM Center of Excellence team. In his role he influences the Compuware APM product strategy and works closely with customers in implementing performance management solutions across the entire application lifecycle. He is a frequent speaker at technology conferences on performance and architecture-related topics, and regularly authors articles offering business and technology advice for Compuware’s About:Performance blog.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.