Page Speed Online works similarly to the Page Speed browser extension. Page Speed Online checks web pages against various performance best practices, including CSS and JavaScript positioning, cache policies, GZIP compression, and eTag usage. Figure 1 shows Page Speed Online results for CNN.com

Clicking on one of the recommendations brings up a detailed screen with recommendations (see Figure 2):

Page Speed Mobile Performance Analysis

The online version of Page Speed also includes a mobile performance analysis that simulates viewing a mobile site in a mobile browser (page speed automatically follows mobile redirects, acting as a mobile browser). Figure 3 shows the mobile results.

Conclusion

Page Speed online is the web-based version of the Page Speed extension. The online version provides a list of expandable recommentations based on web performance best practices. Unlike the Page Speed extension, the online version does not provide a one page report, this would be a welcome addition to future versions.

Further Reading

mod_pagespeed

This Apache module automates many of the recommendations in the Page Speed performance plugin.

Page Speed home page

Google's gateway to the page speed family of services and software.

]]> tag:www.websiteoptimization.com,2011:/speed/tweak//3.352 2011-03-18T20:42:52Z 2011-03-19T13:02:45Z

The race is on to get tickets to the 2012 Summer Olympics in London, England. Are the web sites handing the traffic as fast as the athletes they promote?

website optimization http://www.websiteoptimization.com The race is on to get tickets to the 2012 Summer Olympics in London, England. Millions of people (some 2.3 to 2.7 million signed up to request tickets so far) are clamoring to attend events featuring the likes of Michael Phelps, Ian Thorpe, and Usain Bolt. To distribute the load in the initial ticket request phase, Olympic organizers are using a batch system to accept requests over a six week period. Even with this even-handed approach, the servers were under tremendous load in the early hours of this past Tuesday. We investigate and show how performance could be improved.

]]> London2012.com versus CoSport.com

Tickets for the 2012 London Summer Olympics went on sale Tuesday March 15. In the UK, registered residents can buy tickets from the official London2012.com website, while those in the US, Australia and some other countries use CoSport.com as their official ticket reseller. With millions of fans are looking for tickets are the servers up to the task?

Batch versus Live Ticket Sales

Unlike the future live ticket phases in June and December this initial request phase is a batch, where the millions of people who signed up enter their event choices from March 15 to April 26, 2011. After all the requests are in, tickets will be assigned, with oversubscribed events chosen by random lottery. Ticket requests during this phase receive the same priority, there is no advantage to applying early. Despite this approach, the sites dispensing tickets experienced high loads Tuesday morning. Checking the official London2012.com site in the morning, it was up and running (see Figure 1):

Figure 1: London2012.com Tickets Site Under Load

CoSport.com Web Site Under Load

While the authorized US ticket reseller CoSport had some trouble handling the load (see Figure 2):

Figure 2: Cosport.com Under Load

Emails to Cosport were promptly returned, and a notice went up saying "Site Offline" it is being updated, come back mid-afternoon (see Figure 3).

Figure 3: Cosport.com Site Announcement

True to their word as of 4pm EST the site was up and able to take ticket requests (see Figure 4).

Figure 4: CoSport.com Home Page

Brief Performance Analysis of London2012.com and CoSport.com

Let's take a brief look at the two home pages using the YSlow and Page Speed tools. YSlow finds both home pages get a grade of C. The CoSport home page is 504.9K in total size, and uses 36 HTTP requests (see Figure 5).

Figure 5: CoSport.com YSlow Results

The official London2012.com site also scores a C in YSlow, with 1069K total page size, requiring 100 requests (see Figure 6).

Figure 6: London2012.com YSlow Results

Page Speed Analysis of London2012.com and CoSport.com

A Page Speed analysis of the two home pages tells a similar story. The CoSport.com home page scores an 80 out of 100 possible points (see Figure 7).

Figure 7: London2012.com Page Speed Results

While the London2012.com home page scores a 70 out of 100 with Page Speed (see Figure 8).

Figure 8: London2012.com Page Speed Results

Waterfall Analysis of CoSport.com and London2012.com

Looking at waterfall graphs can help isolate problem areas in web page performance. Using webpagetest.org, we find the following results for both sites. First the overall results for CoSport.com (see Figure 9).

Figure 9: CoSport.com Web Page Test Results

CoSport.com loads in 5.4 seconds, and starts to render content in 2.58 seconds.

The London2012.com site loads in 9.7 seconds, and starts to render content in 4.2 seconds (see Figure 10).

Figure 10: London2012.com Web Page Test Results

Waterfall Graphs

The waterfall graph for the two sites shows how each web page component loads, and breaks down the different load time components (DNS lookup, time to first byte, content download, etc.). Figure 11 shows the CoSport.com waterfall graph.

Figure 11: CoSport.com Waterfall Graph

Note the highlighted areas. CoSport.com redirects to a secure page on the home page, with associated SSL delays. Multiple CSS and JavaScript files delay the time to first byte.

The waterfall graph for the London2012.com is shown in Figure 12. The London2012 site shows about a 0.8 second time to first byte for the home page, and multiple CSS and JavaScript files which delay the time that useful content displays.

Figure 12: London2012.com Waterfall Graph

Front-End versus Back-End Performance

The CoSport.com home page is less than half the size of the London2012.com home page (504.9K versus 1069K), and uses nearly 1/3 of the requests (38 versus 100). The front-end engineers at CoSport have done a good job of making their site smaller and more streamlined than the official London2012 site. So even though the CoSport home page is half the size with nearly 1/3 the requests, the London2012 site stayed up and available during the crush of visitors Tuesday morning. This shows that the backend capacity is higher on the London2012.com site. According to Steve Souders, 80% of performance problems are on the front-end (Higher Performance Web Sites, O'Reilly), but under high load the main difference here is the back-end performance and request capacity of the servers.

Suggested Performance Recommendations

Based on the findings above, we'd recommend that CoSport.com beef up their back-end infrastructure and CDN to better handle more simultaneous requests and higher peak bandwidth. They could combine CSS files and JavaScript files to minimize HTTP requests, and avoid a redirect to an SSL page on their home page to avoid SSL overhead. During peak access times, they could replace key pages with minimalist pages by substituting CSS text or sprites for graphic text (see the highlighted country button examples above in Figure 4), to minimize the number of requests served. The London2012.com team could improve performance by adding GZIP compression, improving caching, minifying and combining JavaScript and CSS, and optimizing and combining images.

Further Reading

CoSport.com

Official reseller of Olympic tickets and hospitality packages for Australia, Austra, Bugaria, Canada, Norway, Sweden, and the United States.

London2012.com

Official site for the London 2012 Summer Olympic Games.

Page Speed

Google's Page Speed browser plug-in analyzes web pages according to an expanded set of performance rules, first created by Steve Souders.

Web Page Analyzer

A free web-based web page analysis tool using guidelines to offer recommended improvements.

Yahoo! YSlow for FireBug

Useful browser plug-in that analyzes web pages according to a set of performance rules, first created by Steve Souders.

]]> tag:www.websiteoptimization.com,2011:/speed/tweak//3.350 2011-02-13T18:26:56Z 2011-02-14T01:24:06Z

Learn how to speed up web pages that use Google Analytics with a few simple changes, while maintaining its advantages for faster-loading sites.

website optimization http://www.websiteoptimization.com Many sites now use Google Analytics to track their metrics. Google Analytics gives some useful statistics not normally found from server-side log files, including PPC versus natural SEO traffic and visitor behavior. Used as directed however, Google Analytics can slow down your pages. This article shows how improve the speed of web pages using Google Analytics with a few simple changes, while maintaining its advantages for faster-loading sites.

]]> Placement of Google Analytics' JavaScript

After you signup for Google Analytics (http://www.google.com/analytics/) Google gives you a snippet of JavaScript to include in your web pages. This snippet contains a unique code (see _setAccount below) identifying your website, as well as a link to the "ga.js" JavaScript file (google-analytics.com/ga.js) that is called to grab the data. The code for WebsiteOptimization.com looks like this:

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-21014437-1']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>
</head>

Google instructs webmasters to place this code just before the closing </head> tag, at the end of the HEAD element in their XHTML files. The code is purported to be asynchonous, meaning it should load the script after the content has loaded. Let's see what actually happens with a waterfall graph (courtesy of WebPageTest.org, see Figure 1).

Figure 1: Waterfall Graph of WebsiteOptimization.com Google Analytics in HEAD

Note that the dark blue, orange, green and light blue colors signify DNS lookup, Initial Connection, Time to First Byte, and Content Download times respectively.

You can see that the external Google-Analytics.com/ga.js file loads fourth (4) in the sequence of 19 total files, while the 1 pixel GIF from Google loads tenth (10). The DNS lookup (58ms) and initial connection (137ms, in dark blue and orange respectively) times for the external ga.js file total 195 ms. You pay a price for loading files from another server due to DNS lookup time. Under load we noticed a slight delay after adding the Google code to the page.

The overall loading statistics are shown in Figure 2. Start render is shown as 0.844 seconds for the HEAD configuration.

Figure 2: Loading Times for WebsiteOptimization.com with Google Analytics in HEAD

Let's see what happens when we move the code to the footer.

Move JavaScript to the Bottom

As an experiment we moved the Google Analytics JavaScript snippet to the bottom of the page, just before the closing BODY element thus:

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-21014437-1']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>
</body>

The resulting waterfall graph looked like this (see Figure 3):

Figure 3: Waterfall Graph of WebsiteOptimization.com with Google Analytics before closing BODY

The Google Analytics JavaScript file moved from loading fourth (4) to eighth (8) in the sequence. This lets more useful content display for the user, giving them a sense of faster feedback from the page. In this case the DNS lookup was higher at 242ms, and the initial connection time was 55ms, for a total delay of 297ms or about 1/3 of a second on a high speed connection. The start render went from 0.84 to 0.77 seconds moving the JavaScript from the HEAD to the footer (your times may vary with each load See Figure 4).

The overall loading statistics for the code in the footer configuration are shown in Figure 4. Start render is shown as 0.768 seconds for the FOOTER configuration.

Figure 4: Loading Times for WebsiteOptimization.com with Google Analytics in FOOTER

Localize External JavaScripts

To avoid the extra overhead of off-server resources (DNS lookup and Time to First Byte) you can localize your JavaScripts on your server. We copied the ga.js file from google-analytics.com/ga.js and placed it at websiteoptimization.com/ga.js, and changed the code accordingly (google-analytics.com/ga.js to websiteoptimization.com/ga.js):

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-21014437-1']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.websiteoptimization.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>
</body>

Let's see what happens to the waterfall graph after localizing this file (see Figure 5).

Figure 5: Waterfall Graph of WebsiteOptimization.com with Google Analytics before closing BODY local

The Google Analytics file now loads 17th, after all the page content displays. The start render time (green vertical line) moved from 0.77 seconds to 0.73 seconds or 13% faster than the initial start render time of 0.84 seconds (see Figure 6). There is now no DNS or Initial Connection overhead for the JavaScript file because it is stored locally.

The overall loading statistics for the code in the footer configuration are shown in Figure 6. Start render is shown as 0.73 seconds for the FOOTER local file configuration.

Figure 6: Loading Times for WebsiteOptimization.com with Google Analytics in FOOTER local

Cautions to This Method

There are a couple of cautions to watch out for with this method. Google periodically updates their analytics code to add more features. You can address this with a CRON script to periodically copy over the latest ga.js file, or copy the file manually periodically. The other caution is that Google says if you place the code at the end, you may lose some visitor data for people that don't wait for the entire page to load. For faster pages this isn't much of an issue, but for slower ones you may lose some visitor data this way. For us, the slight chance of a loss of some visitor data is more than offset in the gain in display speed.

Conclusion

You can speed up sites using Google Analytics with two simple changes. Move your analytics code to the bottom, and localize the JavaScript file. This article showed the effect of these changes on a real-world example with waterfall graphs.

Further Reading

Google Analytics

Google's free analytics service uses JavaScript to gather data. Formerly the Urchin statistical software acquired, improved, and made into a free web service by Google.

JavaScript Optimiation Tips

Tips from WebsiteOptimization.com's Speed Tweak.

]]> tag:www.websiteoptimization.com,2011:/speed/tweak//3.349 2011-01-31T19:28:26Z 2011-01-31T20:26:41Z

Learn how to configure or eliminate ETags to improve website performance.

website optimization http://www.websiteoptimization.com An Entity tag (ETag) is a unique identifier assigned to a specific version of a given resource on a web server. ETags are used as a cache control mechanism to allow client browsers to make conditional requests. This lets caches work more efficiently by reusing unchanged resources on the client, and avoiding full server responses if the content has not changed. Efficient caching saves bandwidth and improves performance by delivering only what the client needs, not what it already has.

]]> Anatomy of an ETag

In Apache, ETags are made out of three components: the INode, MTime, and Size.

FileETag INode MTime Size

An ETag looks like this:

ETag: "10690a1-4f2-40d45ae1"

Cache Conversation

When clients cache a resource they also save its ETag. If the server resource changes, its ETag is updated. When a client revisits a page, it checks to see if the resource has changed by sending a conditional header If-None-Match and the value of the object's ETag:

If-None-Match: "10690a1-4f2-40d45ae1"

On the subsequent request, the server compares the ETag sent with the current Etag of the resource. If the Etags match the resource has not changed so the server sends the short response of HTTP 304 Not Modified status. The "not modified" status tells the client that the resource in the cache is good, and it can be reused. If the ETags do not match the server sends a complete response including the modified resource.

The Problem with ETags

The problem with ETags is that by default they are intended to be used on a single server (the inode portion above). Apache and Microsoft IIS default to the full ETag configuration, including the server's iNode. For websites served from multiple servers, ETags can cause an unnecessary load by serving the same resource from different servers, even though the resource is identical and unchanged.

The Solution: Configure ETags

The solution for sites with multiple servers is to remove the iNode portion of Etags. To do this in Apache add the following lines to your configuration file.

<Directory /usr/local/httpd/htdocs>
    FileETag MTime Size
</Directory>

An example from a site using iNode-less ETag follows:

Server	        Apache
Last-Modified	Fri, 28 Jan 2011 16:30:52 GMT
Etag	        "15c3-4d42ef3c"
Accept-Ranges	bytes
Content-Length	5571
Content-Type	image/jpeg
Date	        Mon, 31 Jan 2011 18:56:41 GMT

This server-independent ETag avoids the problem of the default ETag configuration, and allows more efficient caching of the same object across different servers.

Remove ETags Entirely

Another option is to remove ETags entirely, and rely on other cache control headers like Last-Modified timestamps. To remove ETags in Apache, add the following to your server configuration file.

Header unset Etag
FileETag none

This has the added benefit of reducing the size of your headers, which we'll talk about in a future tweak.

Conclusion

Used correctly ETags can improve cache efficiency and improve the performance of your website. However, by default Apache and Microsoft IIS servers send fully specified ETags with a server component that can cause unnecessary requests for an identical resource served from multiple servers. One solution is to configure your ETags to omit the server information (iNode). Another is to eliminate ETags entirely.

Further Reading

Clausen. L. "Concerning Etags and datestamps,"

In Proc. Web Archiving Workshop, Bath, United Kingdom, September 2004. - Tested the optimal combination of ETag and datestamp caching.

Code: Configure or Eliminate ETags

An excerpt from Website Optimization showing how to configure ETags.

ETag from HTTP 1.1 Specification

Describes the use of ETags.

]]> tag:www.websiteoptimization.com,2010:/speed/tweak//3.346 2010-11-12T15:56:12Z 2010-11-12T16:07:06Z

mod_pagespeed is an open-source Apache module that automatically speeds up web sites. Through a number of filters, mod_pagespeed trims the fat off your HTML, CSS, JavaScript and images, reduces HTTP requests, and improves caching. In this article we introduce mod_pagespeed and summarize the available filters.

website optimization http://www.websiteoptimization.com mod_pagespeed is an open-source Apache 2.2+ module designed to automatically speed up your site by optimizing the various components of your web pages. The module does this by rewriting page resources using filters that adhere to web performance best practices. mod_pagespeed is the server version of the client-side Firefox module that analyzes web pages using similar best practices.

]]> How mod_pagespeed Works

mod_pagespeed utilizes a number of filters to optimize HTML, JavaScript, CSS, and JPEG and PNG images, as well as set better caching policies. mod_pagespeed rewrites resoruces into a server-side cache to be delivered instead of the original resources, so it is important to configure caching on your server correctly. The module essentially takes existing page resources and trims excess fat (unused resources in images for example), and improves caching (hashed resources with long expiry times). By configuring caching and HTTP compression and using mod_pagespeed, webmasters can speed up their sites by serving optimized resources.

mod_pagespeed Filters

This module is configured similarly to other Apache modules, using the pagespeed.conf file. The configuration file turns on and off the filters, and allows webmasters to fine tune threshold settings used by the various filters. A summary of the initial filters is shown below:

Add Head

Adds an XHTML head section to the document if it finds a <body> tag before finding a <head> tag. This filter is used to make sure there is a place for other filters to write tags into the HEAD of XHTML documents.

Add Instrumentation

Inserts two small snippets of JavaScript (early in the head, and late in the body) to measure the time the client spends loading and rendering a page, and reports this data back to the server.

Collapse Whitespace

This filter replaces contiguous whitespace with a single whitespace character to reduce the transfer time of HTML files.

CSS Combine

The CSS Combine filter reduces HTTP requests by combining multiple external CSS files into one concatenated CSS file.The filter operates within the scope of a "flush window."

Combine Heads

Although technically a no-no in XHTML, there are web pages out there that have multple head elements. This filter combines them into one.

Elide Attributes

This filter removes attributes from tags when the specified value is equal to the default value of that attribute.

Extend Cache

The "Extend Cache" filter extends cache lifetimes for all resources that are not otherwise optimized. This filter rewrites the URL referenced in an HTML page to include a hash of the resource. It also rewrites the HTTP header to extend the max-age value of the cacheable resource to one year. mod_pagespeed uses the origin cache TTL to periodically re-examine content to see if it has changed. If so, the hash of the content will change. This mechanism makes it safe to serve hashed URLs with a long timeout. So if a site owner changes a resource, the hash to the resource will change after the specified TTL. Note that this filter is included in other filters that optimize resources.

Inline CSS

The "Inline CSS" filter moves smaller external CSS files into the HTML file, to save HTTP requests. This filter inlines CSS files below a specified byte threshold.

Inline JavaScript

The "Inline JavaScript" filter works similarly to the Inline CSS filter. It saves HTTP requests by inlining small external JavaScript files directly into the HTML file. This filter only inlines script below a specified byte size threshold, and only those scripts without both source and inline data, and on-domain JavaScripts.

Minify JavaScript

This filter minifies JavaScript code to reduce file size. It currently removes most whitespace and comments. This filter allows webmasters to "prettify" their JavaScript to be more legible with indents etc. and still have minified files without the extra step of minification.

Move CSS to Head

This filter moves all external CSS to the head of the HTML document. This filters aims to minimize the number of times a browser must re-flow a document by ensuring that all CSS is parsed in the head before any body content is encountered. Like some of the other filters in mod_pagespeed, this filter works in the scope of a "flush window." A flush of the output buffer is used to deliver initial content faster, and to increase the apparent response time of web pages (feedback).

Optimize Images

The "Optimize Images" filter re-scales, re-compresses, and strips metadata from JPEG and PNG images. It also inlines images using the data:uri scheme below a default (2048 bytes) or specified threshold. The filter does not currently optimize GIFs or 1x1 pixel images. You should also turn on the insert_imagedimensions filter to ensure fast rendering of images.

Outline CSS

This experimental filter is the opposite of Inline CSS. It takes inlined CSS larger than a minimum byte threshold and makes it into an external resource. Outlining CSS can save bytes across multiple pages that use the same inlined CSS by caching the outlined CSS file.

Outline JavaScript

This experimental filter works similarly to the Outline CSS filter. It takes inlined JavaScript larger than a minimum byte threshold and makes it an external resource.

Remove Comments

This filter removes most comments from HTML files. The filter is aware of Internet Explorer's conditional comments, and will not remove these.

Remove Quotes

This filter removes unnecessary quotation marks from HTML attributes. Note that XHTML requires quotes around attributes.

Rewrite CSS

This filter minifies inline and external CSS by stripping out most whitespace, and shortening color names. The example shows #ff0000 shortened to red, it isn't clear if shorthand hex notation is also used for this filter (i.e., #ffcc00 becomes #fc0). Note that this filter should be used with caution on malformed or proprietary CSS.

Conclusion

mod_pagespeed is a welcome addition to our web performance toolkit. It automates a number of techniques webmasters either do manually or automatically with shell scripts. While no substitute for recoding pages using CSS sprites, conversion to CSS behavior from JavaScript (drop-down menus for example), substituting CSS layout for table layout, and modular CSS techniques, mod_pagespeed will trim the fat, reduce HTTP requests, and intelligently extend caching policies for your web page resources.

Further Reading

Make your websites run faster, automatically - try mod_pagespeed for Apache

Official announcement of the mod_pagespeed Apache module by Richard Rabbat, Product Manager, 'Make the Web Faster' initiative at Google. Last year Google introduced Page Speed, a client-side analysis module that analyzes web pages for performance issues. On November 3, 2010 Google's official blog announced mod_pagespeed, which incorporates 15 on-the-fly optimizations derived from web performance best practices. Initial tests by Google showed speed improvements of up to 50%, or 2X faster on average across a rough sample of web sites.

modpagespeed.com

Official website for mod_pagespeed, offers before and after examples of each filter.

mod_pagespeed documentation codebase

"mod_pagespeed is an Apache 2.x module. It is added into an existing Apache installation, and configured with the pagespeed.conf configuration file. mod_pagespeed can be installed from source or binary form."

]]> tag:www.websiteoptimization.com,2010:/speed/tweak//3.344 2010-09-30T11:03:41Z 2010-09-30T20:57:42Z

Google's new search rank measure, site speed, is one more reason to make sure your pages fly. For faster websites and higher rankings, many companies turn to a performance analysis. Find out what to look for in a web performance audit.

website optimization http://www.websiteoptimization.com With Google now factoring page loading speed into search engine rankings, having a fast website has become even more important. Exactly how much of a factor speed is in search rankings is open to debate, although anecdotal evidence suggests that speed can affect rankings. One of the first steps companies need to take in improving their website speed is a web performance audit. This article details what to expect in a web performance analysis.

]]> What is a Web Performance Audit?

A web performance audit is an independent analysis of the factors that contribute to the response time of a website. In addition to measuring the size and rendering speed of the various components that make up a web page, a web performance audit should offer recommendations to speed up the response time of initial and subsequent page loads. Depending on its depth, a web performance audit can also include optimized code examples to replace older less efficient code (XHTML, CSS, JavaScript, and backend PHP, Perl, Java, etc.).

Performance audits come in two flavors, front-end and back-end. Front-end audits are more common than back-end because about 80% to 90% of the time users wait for pages to load are spent on the front-end (Souders 2007). Back-end audits are still useful for performance because you can potentially gain orders of magnitude improvements in performance from back-end optimization. A front-end audit typically includes the following:

Front-End Web Performance Analysis

• Executive summary with overall recommendations
• Baseline performance benchmarks (useful for tracking progress and competitive analysis)
• Detailed analysis of individual web pages
• Baseline metrics (XHTML, CSS, JavaScript, multimedia size, page load speed [first byte, start render, page load times])
• Triaged recommendations (listed in order of effectiveness) for both page components and server settings
• Code review with optimized examples of first instances of problem areas (XHTML, CSS, and JavaScript)
• Optional: AJAX-specific analysis (code review, unused functions, proper library, compression, server settings])

Back-End Web Performance Audit

A back-end audit explores the factors that effect the delivery of the front-end content. Back-end audits typically review server setups, CMS and module configuration, and SQL query efficiency. An example outline of a back-end audit follows:

• Executive summary with overall recommendations
• Baseline performance benchmarks and server setup
• Identify server configuration, middleware, and CMS and module setup/versions
• Recommend improvements for above factors (upgrades, caching, compression, middleware)
• Locate target pages with profiling/monitoring tools
• Identify slow database queries using SQL profiler
• Show which SQL queries to optimize
• Show where to create indexes for any full table scans

Hybrid Performance Audit

A hybrid performance audit combines both front-end and back-end analyses into one complete report. Hybrid audits analyze the two main components that contribute to web page speed, the server configuration that delivers the content to the user, and the content itself and how quickly the content renders.

What about Web Performance Tools?

Automated performance tools like YSlow, Page Speed, and WebPageAnalyzer.com can give you some useful metrics and guidelines. Performance experts use these and other tools to analyze your site, review your code in detail, and triage and implement recommendations.

Common Performance Problems

What can you expect to find when reviewing a site for web performance? Here are some common performance problems we've found when reviewing web sites.

Long Time To First Byte

Figure 1 shows an example of a long time to deliver the first byte, over 4 seconds before any data is sent. This delays the time for the display of useful content. A long TTFB indicates a server performance issue, typically from an overloaded shared or dedicated server.

Figure 1: Long Time to First Byte (WebPageTest.org waterfall)

Slow SSL Connection/Handshake

For secure transactions you often see a slow SSL connection (see Figure 2). Secure Sockets Layer handshakes are resource intensive and can slow down https pages. One solution is to offload SSL connections to a specialized server.

Figure 2: Long SSL Connection (WebPageTest.org waterfall)

Blocking of Content by JavaScript

When browsers load and execute JavaScript they stop other rendering duties including downloading other resources. Misplaced JavaScript (typically placed after CSS instead of before), can block the downloading of subsequent files. Here is an example where JavaScripts were placed between CSS files (see Figure 3), note the misplaced CSS file after a JavaScript file.

Figure 3: Misplaced JavaScript Blocks Parallel Downloads (WebPageTest.org waterfall)

Too many external files in the HEAD

With the average web page requiring more than 43 objects per page object overhead now dominates web page latency. Multiple objects (external JavaScript and CSS files typically) within the HEAD of XHTML documents are particularly harmful to web page performance because they delay the rendering of useful body content that users can interact with. See Figure 3 for an example. One solution is to combine JavaScript files into fewer files, and do the same for CSS. Another solution is to "split the payload" and load only the CSS and JavaScript required by the page (before the onload event) and defer loading of the rest of the JavaScript and CSS after the body content loads (by attaching a node say with JavaScript after the onload event fires).

Overweight JavaScript

One trend that we're seeing lately with the advent of Web 2.0-enabled pages is the growth of JavaScript. Libraries like jQuery, Prototype, YUI, and Dojo are used and combined with other behavior (menus in particular) to create more interactive and responsive web interfaces. Unfortunately, all of this JavaScript has to be downloaded and parsed. We've seen total JavaScript payloads larger than 500K! A couple solutions present themselves, compress the JavaScript (with GZIP or deflate) which typically compresses these text files by 75% to 80%. Even better, combine and minify the JavaScript files before compression. The best solution is to rethink the behavior of the page in question, and substitute standards-based methods (CSS drop-down menus for example) for JavaScript.

Unused or Legacy CSS

One of the useful metrics that Page Speed gives is an indication of how much of the CSS is actually referenced in a target web page. In recent analyses we've found a fair amount of CSS going unused within pages and sites. To combat CSS bloat remove legacy CSS left over from past designs, and adopt a more object-oriented approach ala Nicole Sullivan (see OOCSS.org for more information).

Removed unused CSS
45% of CSS (estimated 31.7kB of 70.4kB) is not used by the current page.

Uncompressed Textual Content

HTTP compression is a standards-based way to compress the textual content of your web pages. HTTP compression or "content encoding" uses GZIP and deflate to compress your XHTML, CSS, and JavaScript at the server, and modern browsers decompress these files automatically to speed up web page downloads and save bandwidth. Even though on average HTTP compression can save 75% or more off of textual files, only 66% to 89% of compressible text is compressed on the Web (Ramachandran 2010).

You can test your site for HTTP compression using the above tools or Web Page Analyzer or Port80Software.com tools.

Unoptimized Images and Multimedia

On average images make up 64.3% of the average web page size, and more than 75% of all HTTP requests, so optimizing images is one of the first places to start when speeding up web pages. While lossy methods can significantly reduce web image sizes, not everybody wants to change the quality of their images. You can losslessly trim unnecessary bytes and blocks from your images using a tool like Smushit from Yahoo! (see Figure 4)

Figure 4: Shushit Losslessly Optimizing Images

Complex XHTML Code

The XHTML provides the skeleton to display the objects in a web page. Making this skeleton lightweight is one key in fast web page display. Overuse of tables for layout and embedded styles and JavaScript are two common problems. One thing to avoid is saving HTML files from Word files. Word outputs a large amount of unnecessary code:

<pre><code> <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=windows-1252"> <meta name=ProgId content=Word.Document> <meta name=Generator content="Microsoft Word 12"> <meta name=Originator content="Microsoft Word 12"> <link rel=File-List href="index%20IT_file/filelist.xml"> <link rel=Edit-Time-Data href="index%20IT_file/editdata.mso"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Sample Home Page HTML from Word</title> <!--[if gte mso 9]><xml> <o:DocumentProperties> <o:Author>fm</o:Author> <o:Template>Normal</o:Template> <o:LastAuthor>fm</o:LastAuthor> ...

Improper Server Settings

You can detect certain server settings without requiring access to the server, typically using HTTP headers. Caching, keep-alive, HTTP compression, etags usage, cookies on static resources, and other settings can be detected remotely. Figure 5 shows the optimization checklist from WebPageTest.org, which is an online version of AOL's PageTest open source program.

Figure 5: Optimization Checklist Showing Items to Address (WebPageTest.org Optimization Checklist)

Conclusion

With speed now factoring into web page rankings, web performance has suddenly become more important. A web performance audit can show where problem areas are and recommend solutions. This article shows what to expect from a web performance audit. There are two main kinds of performance audits, front-end and back-end. The majority of analyses are front-end, although back-end audits can often reveal significant areas for improvement. We showed some common problems found in websites today, and list some tools used by performance engineers.

Further Reading

The Average Web Page

Shows data for the average top 500 web page and the average web page for the entire web. The average web page as of May 2010 was 320K with 43.9 resources.

HTTP Compression

Standards-based way to compress textual content in a web page using GZIP or deflate. Typical compression savings are 75%.

King, A. 2008, "Website Optimization: Speed, Search Engine & Conversion Rate Secrets"

Half of this book is devoted to improving web site performance. Includes a chapter on web metrics and performance tools. By Andrew B. King. O'Reilly.

Ramachandran, S. 2010, May 26, "Web metrics: size and number of resources,"

Using the Googlebot, Sreeram analyzed both 380 million top sites and 4.2 billion websites to see what the average web page consists of. He found that the average web page is 320K in size, using 43.91 resources per page.Just 66% of compressible bytes were compressed using HTTP compression in the entire Web. 64.3% of the average web page was taken up by images (205.99K of images divided by 320K size of average web page). There were 7 scripts and 3.2 external style sheets. The uncompressed size of the top sites was 477.2K, while the uncompressed size of the average web page (4.2 billion) was 376.7K. Interestingly, the top sites network size (bytes delivered down the pipe) was smaller (312K vs. 320) than the overall average web page, due in part to the increased used of HTTP compression (89% versus 66%). Google, May 26, 2010.

Souders, S. 2007, "High Performance Web Sites",

Using his experience as a back-end engineer at Yahoo! Steve Souders wrote his first book on web performance gives 14 rules to follow to speed up your site by 25 to 50%. Each rule is explained and tested with matching live tests on the companion site. O'Reilly.

WebPageTest.org

A web-based version of AOL's Page Speed program. Gives waterfall charges of resource loading sequences, optimization checklist of major problem areas, and timings at different network locations and bandwidths of page loading metrics.

]]> tag:www.websiteoptimization.com,2010:/speed/tweak//3.341 2010-08-29T14:20:22Z 2010-08-29T14:50:05Z

Joshua Bixby interviewed Andrew King about the web performance industry. Learn what to look for in a performance consultant and what to expect in an audit.

website optimization http://www.websiteoptimization.com Our own Andy King was interviewed by Joshua Bixby of Strangeloop Networks. Joshua asked Andy some probing questions about web performance consulting. Joshua, the President of Strangeloop Networks, asked about the value of hiring an outside consultant. Where to start when finding a performance consultant. Asking the right questions to weed out unqualified candidates. If there was a common process that performance consultants follow? And what to expect at the end of the process.

Web Performance Consulting: Five questions for Andrew King

What to look for with a Performance Consultant

You want to hire a firm that has experience and credibility. Like any job involving a consultant, ask for references. Take a look at their website to see how it fares for speed and design. Use Pagespeed, YSlow, or Web Page Analyzer to test the speed of their site, to see if they eat their own dog food.

Performance Consultant Directory?

Joshua asked an interesting question in the interview. Where can one find a performance consultant? Is there an organization of performance consultants and firms? Unlike SEO which has SEMPO, I know of no organization of web performance consultants, looks like there is a need for this.

Web Performance Audit

The most common request we have from companies looking for performance consulting is an audit. Front-end audits outnumber back-end audits by a large margin, as 80% of performance problems are due to the front-end, i.e., the content that you deliver from your server to your users. A front-end audit evaluates the XHTML, CSS, javaScript, and multimedia for efficiency, as well as server settings that can help performance. We'll expand on what to expect in a web performance audit in a future tweak.

Further Reading

Strangeloop Networks

Joshua Bixby's Strangeloop Networks specializes in automatically speeding up websites with services and hardware appliances.

Page Speed

A free browser-based tool that analyzes and grades web pages based on performance rules discovered by Steve Souders.

Web Page Analyzer

A free server-based tool that analyzes the performance of web pages.

YSlow

A Firebug plug-in that analyzes and grades web pages for performance. Useful for summarized statistics.

]]> tag:www.websiteoptimization.com,2010:/speed/tweak//3.339 2010-06-29T13:16:49Z 2010-06-29T14:09:10Z

Highlights from the Velocity 2010 conference on web performance. This sold-out event explored the latest technique for fast websites, and is a must-see for performance engineers.

website optimization http://www.websiteoptimization.com I just got back from the Velocity 2010 Web Performance and Operations Conference in Santa Clara, California. Now in its third year, the conference is a must-see if you are a web performance or network operations engineer. And engineers were aplenty this year, the conference was sold out with more than 1500 attendees. Founded by Steve Souders (author of High Performance Web Sites, Even Faster Web Sites) and Jesse Robbins (founder of Opscode and Amazon's "Master of Disaster") the Velocity Conference is devoted to helping you make your web pages and web applications faster. The conference this year covered many related issues, including mobile web performance, cloud computing, HTML 5, metrics, and network latency. It is a must-see if you are a web developer interested in making your site faster. And with Google's recent announcement of factoring speed into web page rankings, everyone should be interested in making their pages faster.

The Web Performance Track

What follows are some highlights from the talks, keynotes, and workshops I attended. As a web performance engineer, I was most interested in the web performance track, leaving the network operations talks to the sysops.

Highlights

Metrics 101: What to Measure on Your Website Sean Power (Watching Websites)

The best speaker I saw, Sean Powers made metrics interesting, which is no mean feat. Averages are out, percentiles are in. Talked about boiling down metrics into meaningful form, while still retaining enough granularity to be meaningful. Four kinds of sites, transaction, collaboration, SAS, and media, each has its own set of metrics.

The Top 5 Mistakes of Massive CSS Nicole Sullivan (Consultant), Stoyan Stefanov (Yahoo! Inc)

Nicole Sullivan talked about modular CSS, where you boil down the common interface features (media block, headers, etc.) and use only classes and classes that extend those classes plus the cascade and inheritance to build minimalist stylesheets. Using infinitely nestable grid systems like Yahoo's YUI, Nicole showed how she significantly reduced Facebook's CSS and HTML (by 50%). This and the Metrics talks were the two best I saw.

Speed Matters Urs Hölzle (Google)

Gave a good talk on navigating web pages as fast as you can turn pages in a book. Talked about changes to the building blocks TCP, DNS, etc. One interesting statistic, the average web page is 320K with 44 requests and 7 DNS lookups, taking 4.9 second to load. The average bandwidth is 1.8Mbps. This is close to the Average top 1000 web page which we estimate is 350K as of 2010.

Other Highlights

The Browser Performance Toolkit - Matt Sweeney (Yahoo!)

Matt provided a good overview of the performance tools available to developers, including YSlow (of course), PageSpeed, Firebug, and others

The Psychology of Performance - Stoyan Stephanov (Yahoo!)

This should sound familiar to readers of my books, Stoyan showed how to tweak web pages to increase their perceived speed. Talked about flushing the page 2-3 times at key points in the render. The speaker was a bit hard to understand.

Building Performance Into the New Yahoo! Homepage Nicholas Zakas (Yahoo!)

This was a well-attended and interesting talk. Nicholas talked about what Yahoo! did when adding features to maintain fast performance. He went beyond the usual suspects of caching, splitting payloads, and minification.

Twitter and Facebook talks

Engineers at both Facebook and Twitter talked about how they scale to millions of users.

Mitigating Advertising Impact on Page Performance Ismail Elshareef (Razorgator Inc.)

Ismail talked about how his team reduced the impact of display ads at Edmonds.com using a JavaScript loader function at the end of the page.

Speeding up Ads

The folks at Meebo (toolbar) had an interesting talk about how they loaded ads asynchonously with a hidden iframe and attaching a node with JavaScript. We'll explore the details in a future tweak.

It was well worth attending this conference, met some great people and learned a few things. Being an O'Reilly conference there was an O'Reilly booth equipped with the latest performance-related books, but my book (Website Optimization, half of which is about performance) was not there for some reason. I recommend going if you are interested in web performance.

Further Reading

You can see the speaker's slides (most of them) and videos of speakers at the official O'Reilly Velocity website, which also has talks/slides from the previous two conferences.

]]> tag:www.websiteoptimization.com,2010:/speed/tweak//3.334 2010-04-11T18:42:35Z 2010-04-15T16:11:47Z

Google's addition of a page speed signal to its search rankings algorithm officially links performance with search engine marketing. The loading speed of a web page affects user psychology in a number of ways, and now it can affect its rankings as well.

website optimization http://www.websiteoptimization.com Google has incorporated the speed of a web page into its search engine rankings. While this new signal currently affects only a small percentage of US sites, Google's announcement officially links performance with search engine marketing. Google has long used various factors, including page load speed, in its quality scores of PPC landing pages. Now Google has incorporated page loading speed into its search engine rankings. Google announced this new signal in their official Webmaster Central blog:

"Speeding up websites is important - not just to site owners, but to all Internet users. Faster sites create happy users and we've seen in our internal studies that when a site responds slowly, visitors spend less time there. But faster sites don't just improve user experience; recent data shows that improving site speed also reduces operating costs. Like us, our users place a lot of value in speed - that's why we've decided to take site speed into account in our search rankings. We use a variety of sources to determine the speed of a site relative to other sites."

Linking User Psychology and SEM

While not currently as strong a signal than inlinks and page relevance, the new Page Speed signal should be taken into account when designing websites This is great news for the usability of the Web and for user satisfaction. Google incorporates more than 200 signals into its search engine ranking algorithm, and the page speed signal now more concretely bridges the gap between the psychology of performance and search engine marketing.

The Psychological Effects of Speed

Research has shown that the speed of a website affects a number of measurable usability factors including:

• Ad revenues
• Aesthetic perception
• Bailout rates
• Conversion rates (Akamai study)
• Flow states (Novak, Hoffman)
• Perceived web credibility (Fogg)
• Quality Ratings
• Queries per user
• User Frustration (measured by blood pressure and galvanic skin response)

Even in this era of widespread broadband, slow web sites still frustrate users. The average web page more than tripled in the 5 years from 2003 to 2008 from 93.7K to 312K in total size. An upcoming survey will show the trend continuing at a similar rate. We have seen home pages in excess of 4 to 10 MB in file size with hundreds of objects! Even on a broadband connection these fat and complex web pages will tax the attention thresholds of users.

The average number of objects has grown from 25.7 to 49.9 during the same 5 year time period with no signs of slowing down. Object overhead now dominates page load delays in this era of higher speed connections.

How Google Incorporates Speed Into Its Algorithm

Search Engine Land reported that Google will measure the speed of a page in two ways:

1. How a page responds to Googlebot
2. Load time as measured by the Google Toolbar

Google has long been an advocate of website performance, in fact they provide an entire section of their site devoted to Speeding Up the Web. Their Page Speed tool, spearheaded by Steve Souders (who also was integral in Yahoo's Yslow performance tool) incorporates the best practices his team found and he detailed in his two books (High Performance Web Sites, and Even Faster Web Sites, both from O'Reilly). Google included site performance in its webmaster tools in December 2009.

Conclusion

Google's announcement of adding a page speed signal into its search rankings algorithm will in the long run help reduce user frustration with slow web sites. It is well established that the loading speed of a web page affects user psychology in a number of ways, and now it can effect its rankings as well. The Page Speed signal now concretely links user psychology with search engine marketing.

Futher Reading

Google incorporating site speed in search rankings

Matt Cutt's expands upon his company's official announcement. April 9, 2010.

Google Now Counts Site Speed as Ranking Factor

Site speed is now a ranking factor in Google's algorithm, and is already in place for U.S. searchers. Search Engine Land, April 9, 2010.

Page Speed Tool

Google's free Firefox add-on that analyzes web pages against best practices outlined in Steve Souders' two O'Reilly books.

Speed Up Your Site

Learn how to Speed Up Your Site with a number of techniques still applicable today including HTML, CSS, and JavaScript optimization. New Riders, 2003, Andrew B. King.

Using site speed in web search ranking

Google's announcement of the Page Speed signal in its search engine rankings algorithm. Official Google Webmaster Central Blog, April 9, 2010.

Web Page Analyzer

Free web page analysis tool, gives total size of page, components, and number of objects along with recommendations. From Website Optimization.

WebPageTest.org

A web-based version of AOL's Page Test software that analyzes web pages for performance against best practices. Features waterfall graphs to locate response time bottlenecks.

Website Optimization Secrets

Covers both search engine marketing and website performance techniques. Touches on crossover effects from the two camps (SEO and performance), including conversion, usability, and flow.

YSlow

Yahoo's browser plug-in for analyzing the performance of websites. Includes easy to use page stats and recommendations. Requires Firebug.

. ]]> tag:www.websiteoptimization.com,2010:/speed/tweak//3.333 2010-03-31T12:11:00Z 2010-04-01T12:31:33Z

Which program is the alpha transparency dog of PNG optimization? We put the front runners of the photo optimization pack through their paces.

website optimization http://www.websiteoptimization.com Over 60% of the file size of the average web page is taken up by graphics and multimedia. So graphics optimization is an important step in optimizing web page speed. At an alarming frequency, we have seen large PNG24 and unoptimized JPEGs used on the Web. Large PNG24s should be optimized for file size or converted to PNG8s. This article shows how to optimize PNG files effectively by minimizing their color palettes, and using alpha transparency intelligently.

]]> PNG vs. GIF

PNGs were designed to be a superior replacement for the Graphic Interchange Format (GIF). GIFs are limited to 256 colors (8-bit color palette), one level of transparency, and the Lempel-Ziv-Welch (LZW) compression algorithm that was patented by UNISYS. In most cases, PNG files from the same source images are smaller than corresponding GIFs. PNGs use the "deflate" compression algorithm, which is 10 to 30% more efficient than LZW compression.

By design PNGs have some advantages over GIF images. PNGs offer more choices in color depths than GIFs, including 8-bit (256 colors), 24-bit (8 bits per channel), and 48-bit (16 bits per channel) truecolor allowing for greater color precision and smoother transitions. When you add an alpha channel, PNGs allow for up to 64 bits per channel. PNGs can have index color transparency (one color) or alpha transparency (multiple levels) useful for smooth shadow transitions over other images. In summary, the advantages of PNGs over GIFs are:

• Alpha channels (multilevel transparency)
• Variable bit depths
• Cross-platform gamma and color correction
• Two-dimensional interlacing
• More efficient lossless compression (LZ77 vs. LZ78+)

PNG24 and PNG Optimization

In a previous article, we discussed how to replace GIF with PNG files for smaller file sizes. You can also optimize PNG24 files for file size by reducing bit depths and the number of colors used. Photoshop and Fireworks offer limited options when optimizing PNG24 files, but there are some third party plugins that offer more control over PNG24 color palettes.

Sample PNG24: NPVetHospital.com

Our volunteer PNG24 comes from NPVetHospital.com, a California client who was kind enough to grant permission to use his site as an example. He came to us concerned that the site was slow to load, even on some broadband connections. The site was designed using large PNG24 images with wide transparent drop-shadows layered over graduated backgrounds. These 24-bit PNGs gave some beautifully smooth transitions around the outer edge of the animals, but were slow to load. While certainly adorable, the puppy image alone weighed in at 676K, giving the home page a weight of well over a megabyte (see Figure 1).

Figure 1: NPVetHospital.com Original Home Page

The original image appeared this way in Photoshop (see Figure 2). Note the wide drop shadow around the edge of the hand and puppy. The existence of the drop shadow and the transparency-based design are the reasons why the original designers chose to use PNGs over GIFs. Note that a JPEG, as shown in these figures, reduces to a much smaller file size, but lacks the transparent feature of GIFs and PNGs.

Figure 2: PNG24 in Photoshop

Photoshop to PNG8, No Dithering

Reducing the original image in Photoshop to a PNG8 produced mixed results (see Figure 3). Note that starting with a layered Photoshop original would give better results: you would avoid requantizing, you could minimize drop shadows, and you could equalize transparent flat areas.

Figure 3: PNG8 in Photoshop

Adding diffusion transparency dither got rid of the non-transparent areas in Photoshop, but the dithering shows once the image is overlaid on the background (see Figure 4).

Figure 4: PNG8 in Photoshop with Diffusion Transparency Dithering

Saving as a PNG24 (File -> Save for Web) cuts the file size to 292K (by 56.8%), but offers no options for color reduction (see Figure 5).

Figure 5: PNG24 in Photoshop

Fireworks and PNG Optimization

Fireworks offers more options than Photoshop when optimizing PNG files. For PNG24s, Fireworks offers no color reduction options but reduced our test PNG24 to 243K (by 64%), which is 7 percentage points better than Photoshop. But Fireworks really shines when optimizing to PNG8 files where it allows both alpha and index transparency (see Figure 6).

Figure 6: PNG8 Optimization in Fireworks

Unfortunately, the upper part of this drop shadow shows some banding in this svelte PNG8 (see Figure 7).

Figure 7: Fireworks PNG8 with Alpha Transparency

This version is nearly ideal, however. Let's try adding some dithering and see what happens to the drop shadow (see Figure 8). The banding nearly disappears! This version is 94K.

Figure 8: Fireworks PNG8 with Alpha Transparency and 100% Dithering

This dithered alpha dog will hunt. Its drop shadows are smoother now with only a hint of an outer edge. Note that we found a bug in Fireworks CS4 for the Mac. It didn't consistently apply an alpha transparency, while the Windows version worked fine. We've reported this behavior to Adobe.

Optimizing PNGs with Web Image Guru

Web Image Guru is a Photoshop plug-in from VIMAS Technologies that gives you more control when optimizing your images. For PNG24s it allows you to reduce the number of colors in the image using a slider or drop-down menu (see Figure 9). Our sample image went from over 54,000 colors to 900 colors when adjusted to the highest acceptable setting, a quality level of 10. The result is a 132K PNG24 file with perfectly smooth drop shadows, more than 45% smaller than Firewords' best PNG24 effort. However, it doesn't apply dithering as intelligently as Fireworks does to PNG8s.

Figure 9: Web Image Guru Optimizing a PNG24

Final Results

From the original 676K PNG24 we reduced the image to two acceptable versions:

• An optimized PNG24 file using Web Image Guru
• An optimized PNG8 file using Fireworks CS4

The PNG24 file was 132K (an 80.5% savings) while the PNG8 file was 94K (an 86% savings, see Table 1). We tried combining the two programs for further optimization but the result, while about 10% smaller, was not quite as smooth as the version using only Fireworks. Overall the home page went from over 1100K to 546K and 506K for the PNG24 and PNG8 versions, respectively.

Table 1: PNG Optimization Results

Graphics Program	PNG24	PNG8
Original	676K	N/A
Photoshop	292K	N/A (banded)
Fireworks	243K	94K (dithered)
Web Image Guru	132K	N/A (banded)
WIG + Fireworks	N/A	83K

Conclusion

Optimizing PNG files is a matter of reducing colors, maximizing repeated pixel areas, minimizing drop-shadows, and controlling any smooth transitions with a judicious application of dithering. With specialized tools you can reduce source images to a fraction of their original size and still maintain acceptable quality. Our test puppy went from 676K to 94K in file size, some 86% smaller. In some cases, the alpha transparency option in Fireworks for PNG8s allows you to overlay smooth transitions on top of backgrounds without resorting to PNG24 images. If you have to use PNG24s, minimize the number of colors in the image first to minimize file size. Always ask for the original layered Photoshop file when optimizing images. With this original in hand you can reduce drop shadows and avoid requantizing a previously quantized image.

Further Reading

Adobe

Makers of Photoshop and Fireworks.

Average Web Page Size Triples since 2003

Within the five years since 2003, the size of the average web page has more than tripled, and the number of external objects has nearly doubled. While broadband users have experienced somewhat faster response times, dial-up users have been left behind.

Graphic Optimization

Tutorials on optimizing web graphics for minimum file size.

NPVetHospital.com

This Yuba City, California veterinarian provided the sample PNG24s to optimize.

Optimize Drop Shadows

Learn how to create optimized drop-shadows in Photoshop to minimize the size of web graphics.

PNG Alpha Transparency - No Clear Winner

A tutorial on including transparency in PNG files by Dave Artz.

Replace GIF with PNG Images

PNGs are designed to be a more efficient, flexible, and patent-free replacement for GIFs. By replacing your GIFs with PNGs you can speed up your web pages and save bandwidth.

VIMAS Technologies

Makers of the Web Image Guru plug-in for Photoshop.

]]>