up

Zoompf's Web Performance Blog

5 Common Causes of Slow Website Performance

 Mark Isham on April 22, 2013. Category: Alexa Research
TwitterLinkedInGoogle+FacebookShare

One of the benefits of working in the website performance industry is the treasure trove of interesting data just sitting out there in the public domain. Over the last few days we aimed our website performance scanner at the Alexa Top 1000 websites to gather various performance metrics of interest. In this post we’d like to highlight the top 5 most common high impact performance causes we uncovered in those scans.

Our testing methodology was simple: for each site in the Alexa top 1000 list, we performed a homepage analysis using the Zoompf WPO product, recording the # of issues found for each of the 400 performance best practices we analyze. A distinct count of each issue type was then summed up across all 1000 sites and ranked in the order of decreasing frequency as discussed below.

1. Unoptimized Images

Sites impacted: 90%

Unoptimized images were the clear winner, impacting 90% of the Alexa Top 1000.  In this context, we refer to unoptimized images as any image that can be reduced in size without visual impact to your user, also known as “lossless” optimization. Images that are optimized using lossless methods are visually identical to their original images, just stripped of extraneous metadata that helps describe the image (useful to the designer, not needed for the end user).

A few best practices to consider:

  • PNG image files are often needlessly large. This is due to extra data inside the PNG file such as comments or unused palette entries as well as the use of an inefficient DEFLATE compressor. PNG images can be optimized using free tools like pngcrush that reduce the size of the file without changing or reducing the image quality.
  • JPEG image files can also be needlessly large for similar reasons to PNG. By using free tools such as jpegtran you can convert JPEGs into progressively rendered JPEG files to reduce the size of the file without losing image quality.
  • PNG files are best used for icons and logos while JPEG is preferable for photos. Because PNG images support transparency while JPEGs do not, the PNG format is commonly overused for images that are better served as JPEGs. By utilizing JPEG instead, you often can realize file size savings as large as 80%. If possible, consider reworking your design to avoid the use of transparency. Alternatively, you can often append a smaller transparent PNG image alongside the larger JPEG image to achieve the same visual effect at substantial file size savings
  • For GIF images, check out our earlier blog post on Optimizing GIF Images.

 For more information about image optimization, check out this presentation as well.

2. Content Served Without HTTP Compression

Sites impacted: 72%

Enabling HTTP compression on your webserver can dramatically reduce the size of the downloaded page, significantly improving load time. This is a high impact change, but is not always as easy as it may seem. We actually did a dedicated blog post on this topic over a year ago here, so i’ll defer most of the details to that.

For Apache 2.0 and above, load the mod_deflate module to enable compression. For IIS, check out this page for more information.

3. Combinable CSS Images

Sites impacted: 69%

Browsers make an individual HTTP request for every background image specified in your CSS pages. It is not uncommon for over half of your total HTTP requests from a single web page to be used for loading background CSS images. By combining related images into a small number of CSS sprites, you can significantly reduce the number of HTTP requests made during your page load. More information on CSS Sprites can be found here.

4. Images Without Caching Information

Sites impacted: 65%

HTTP Caching allows the browser to store a copy of an image for a period of time, preventing the browser from reloading the same image on subsequent page loads and thus dramatically increasing performance. To cache your images, update your webserver configuration to provide an Expires header to your image responses from the server. For images that do not change often, you should specify a “far future” Expires header, typically a date 6 months to a year out from the current date.

Note that even with a far future Expires date, you can always change the image later by modifying the referenced filename using versioning, for example MyImage.png becomes MyImage_v2.png. For more information, see revving filenames.

5. Domain Sharding Not Implemented

Sites impacted: 64%

Most browsers typically support 2-4 concurrent downloads of static resources for each hostname. Therefore, if your page is loading many static resources from the same hostname, the browser will bottleneck in a stair-step fashion downloading all the content. By splitting resources across 2 different domains, you can effectively double browser throughput downloading the required links.

Note that it may be administratively difficult to physically move your files to different hostnames, so as a clever “trick” you can utilize DNS CNAME records to map different hostnames to the same origin. For example, static1.example.com and static2.example.com could both map to static.example.com, thus prompting the browser to load twice as many links concurrently as before, without requiring you physically move the files on the server. For more information see Maximizing Parallel Downloads in the Carpool Lane

Of course too much concurrency has its own drawbacks on performance, so testing should be done to find the optimal balance.

Want to see if your website has these problems? Try a free performance scan to learn more about these and 395 other performance best practices.

Comments

    April 23, 2013 at 12:09 am

    Thanks for summarizing the major performance issues. I don’t think the point “5. Domain Sharding” is as significant as it used to be. This is because modern browsers now support more than 2-4 concurrent connections. I am not sure about mobile browsers though.

    Although its good to have this implemented because it can allow to have cookie less domain or some light weight http server to serve the static content.

    April 23, 2013 at 3:42 pm

    The claim that browsers only open “2-4″ connections per host is badly outdated– that was true in 2008, but is untrue today. Sharding your content across multiple hosts can hurt performance, and it becomes an anti-pattern in HTTP/2.0.

    April 29, 2013 at 11:32 am

    Fair point on the domain sharding as modern browsers do push the boundaries in the 4-8 range, but still is a good general best practice on heavily laden resources as well as a transitional change as legacy browsers finally age out. Of course, with any change “too much of a good thing” can be detrimental so best judgment should be exercised to which resources are appropriate. Thanks for keeping us honest!

    October 9, 2013 at 7:40 pm

    […] every major site today shows these same symptoms in different proportions. As Mark explains in this post, these 3 are part of the ‘top 5’ performance culprits in a majority of websites […]

Comments are closed.