Web Performance Best Practices and Rules
Yahoo!’s Exceptional Performance team has identified 34 rules that affect web page performance. YSlow’s web page analysis is based on the 23 of these 34 rules that are testable. Click each performance rule below to see the details.
- Minimize HTTP Requests
- Use a Content Delivery Network
- Avoid empty src or href
- Add an Expires or a Cache-Control Header
- Gzip Components
- Put StyleSheets at the Top
- Put Scripts at the Bottom
- Avoid CSS Expressions
- Reduce DNS Lookups
- Avoid Redirects
- Remove Duplicate Scripts
- Configure ETags
- Make AJAX Cacheable
- Use GET for AJAX Requests
- Reduce the Number of DOM Elements
- No 404s
- Reduce Cookie Size
- Use Cookie-Free Domains for Components
- Avoid Filters
- Do Not Scale Images in HTML
- Make favicon.ico Small and Cacheable
Server Response Codes
To make it easy for you to differentiate between the HTTP response codes in the waterfall chart, we’ve color-coded the text and background of each URL.
URL2xxThe server responded with a successful code
URL3xxThe request was redirected to another target
URL4xxA client error occured, for example 404 page not found
URL5xxA server error occured, for example 500 internal server error
URLErrorConnection error, no response from the server
Content that conforms to the HTML 4.0 standard will load faster and work in every browser because the browser then knows what to expect. Note that Microsoft-based tools create content that does not even use the standard ASCII character set, but instead uses many proprietary Microsoft characters that will display in Netscape as question marks and can slow down rendering.
If left on, reverse DNS will log a client’s machine name rather than IP address, but at a large performance cost. It is better left off. You can always run log analysis tools which look up the names later.
I’ve provided a free analysis tool at my Web site that can tell you whether or not your bottleneck is in DNS, or because of connection time or content size, or is on the server side. Work on improving the slowest part first.
Use simple servlets, CGI, or your Web server’s API rather than any distributed object schemes like CORBA or EJB. Distributed object schemes are intended to improve a programmer’s code-writing productivity, but they do so at an unacceptable cost in performance for end-users.
Your Web server, middleware, and database all will probably do better with more memory, if they still use their hard disks frequently. Hard disks are literally about a million times slower than memory, so you should buy more memory until the disks are phased out.
Spectacular improvements are possible if you are inadvertently doing full-table scans on every hit of a particular URL. Indexes allow you to go directly to the data you need.
If you can cache content in your middleware or servlets, do it. Making connections to a database and using those database connections is typically a bottleneck for performance.
There are many network snooping and monitoring tools to help you do this. Intermittent slowness is often due to packets being lost or corrupted. This is because a time-out period needs to pass before the packet is retransmitted.
- Check for standards compliance by using Weblint or other HTML checking tools.
- Turn off reverse DNS lookups in the Web server.
- Try out a free analysis tool.
- Use simple servlets or CGI.
- Get more memory.
- Index your database tables well.
- Make fewer database queries.
- Look for packet loss and retransmission.
- Set up monitoring and automated graphing of your Web site’s performance.