Website Performance: Taxonomy of Tips introduced a classification scheme to help us organize the many performance tips found on the Internet. In Empty Src and Href Attributes, Component Caching, and Image Processing for Performance, we examined tips that affect the “journey from the server to the client.” We wrap up this discussion today by summarizing a few other tips that fall into this category.There are several good tips that affect round trip time, but do not fit into the “response’s journey from the server to the client” category. They can be found in the “request’s journey from the client to the server” or “synchronicity” categories.
Data Compression
The sizes of .html, .txt, .js, .css, .xml, .json, and other text files can be reduced substantially by compression. Fortunately, web servers provide an option to compress data immediately before it begins its journey to the client.
Unfortunately, our web server’s default configuration may compress only .html files. It may not compress everything it could. Web servers should be reconfigured to compress all text data. Apache, for example, suggests this configuration:
SetOutputFilter DEFLATE BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary Header append Vary User-Agent env=!dont-vary
Web clients insert the Accept-Encoding header line into the HTTP request to indicate which compression algorithms they support. The web server compresses the response using one of these algorithms and inserts the Content-Encoding header line into the response to indicate which method it used.
Image files should not be compressed this way because they will be processed over and over again at a time when it affects performance. Instead, images should be compressed prior to being transferred to production so the web server can transmit them as-is.
PDF files are already compressed. Asking the web server to compress them again not only wastes CPU cycles, but may also increase the file size.
Avoid Redirects, 404’s, and 410’s
Webpages shouldn’t be asking for components that are missing or moved. The testing phase is supposed to find and remove all such problems. Seeing these in production makes the user question the business’ competence, which leads management to question the developers’ competence.
Apart from the damaged reputations, there is yet another reason to avoid redirects. Sending error information back to the client, making the client then request a different resource, and sending the correct resource back to the client all affect round-trip time, and that affects performance.
Serve Components From Single URLs
Sometimes a component is referenced more than once in a web page. More frequently the component is referenced multiple times from multiple pages. If the pages use more than one URL to identify the component, the browser’s caching mechanism does not recognize the two URL’s as one single component. This means the browser will establish a connection and download the component again, even though it is already in the cache.
Example: If we sometimes refer to Fred’s picture as https://ourDomain.com/image/fred.jpg and sometimes as https://www.ourDomain.com/image/fred.jpg, the browser will see fred.jpg as two different images and will cache it twice.
Every component should be identified exclusively by one single URL.
Monitor Network Performance
Webapps depend on the server’s infrastructure. If the system is not providing acceptable service, this affects the webapp’s performance. Keeping an eye on low-level performance is just as important as keeping an eye on webapp performance. Example If the server is experiencing high packet loss, which results in high retransmission rates, the webapp will take longer to download.
Fortunately, Paid Monitor provides an easy-to-use platform that lets us monitor everything, including low-level functionality. WMI contains all the Windows data we need and Monitoring WMI Data With VbScript discusses how to monitor it. If we are dealing with a Unix system, Monitoring Directory Size shows us that the output from shell commands (e.g., iperf, which reports network performance) can be monitored just as easily.
Set up Monitis monitors to continually measure network performance and to notify you when it is unacceptable. Notifications can be sent by SMS text messaging, e-mail, or posting to a web page you create. This approach gives you ultimate flexibility with very little effort on your part.
Eliminate White Space and Comments That Aren’t Needed
Extraneous white space and comments improve the readability and maintainability of source code, but there is no reason for them to be transmitted from the server to the clients. After creating the source code with all its white space and comments, run it through a minifier to strip out all the stuff the browser doesn’t need. Keep the original for future use and transfer the minified version to production. Keep life simple by automating this as part of the build process.
Eliminate JavaScript and CSS That Isn’t Needed
With the complex dependencies between a large number of CSS and JavaScript files in a typical project, it is fairly common to see duplication within a downloaded web page. Because of this, some browsers request the same component more than once. Even worse, CSS and JavaScript are often downloaded for a page, then never used on that page.
Here’s a solution: Write a server-side function to download JavaScripts and another to download CSS. The functions make sure each component is included only once and all dependencies are taken care of. They can even inline static components into static web pages while keeping dynamic components external.
References
Best Practices for Speeding Up Your Web Site by Yahoo’s Exceptional Performance Team. Published by Yahoo at developer.yahoo.com/performance/rules.html. Accessed 2011.11.30.
High Performance Web Sites – 14 Rules for Faster-Loading Web Sites by Steve Souders. Published by Steve Souders at SteveSouders.com/hpws/rules.php. Accessed 2011.11.30.
Let’s Make the Web Faster. Published by Google at code.google.com/speed/articles. Accessed 2011.11.30. This is a directory of 20 links to performance-related tutorials.
Minimize Payload Size. Published by Google at code.google.com/speed/page-speed/docs/payload.html. Accessed 2011.12.27.
Minimize Round-Trip Times. Published by Google at code.google.com/speed/page-speed/docs/rtt.html. Accessed 2011.12.26/
Paid Monitor Free Page Load Testing Tool. Published by Paid Monitor at pageload.monitor.us. Accessed 2011.12.20.
Monitoring Directory Size by Warren Gaebel. Published 2011.12.22 by Paid Monitor at blog.monitor.us/2011/12/monitoring-directory-size. Accessed 2012.01.07.
Monitoring WMI Data With VbScript by Warren Gaebel. Published 2011.11.30 by Paid Monitor at blog.monitor.us/2011/11/monitoring-wmi-data-with-vbscript. Accessed 2012.01.07.
Ten Tips for Writing High-Performance Web Applications by Rob Howard. Published 2005/01 by Microsoft at msdn.microsoft.com/en-us/magazine/cc163854.aspx. Accessed 2011.11.30.
Top Ten Web Performance Tuning Tips by Patrick Killelea. Published 2002.06.27 by O’Reilly at OReilly.com/pub/a/javascript/2002/06/27/web_tuning.html. Accessed 2011.11.30.
Web Performance Best Practices. Published by Google at code.google.com/speed/page-speed/docs/rules_intro.html. Accessed 2011.11.30.
Website Performance: Taxonomy of Tips by Warren Gaebel. Published 2011.12.29 by Paid Monitor at blog.monitor.us/2011/12/website-performance-taxonomy-of-tips. Accessed 2012.01.02
Try Paid Monitor For Free. A 15-day free trial. Your opportunity to see how easy it is to use the Paid Monitor cloud-based monitoring system. Credit card not required.
The Paid Monitor Exchange at GitHub. This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Paid Monitor system to its full potential.
