#1 – It All Goes Back to the User’s Experience
#2 – KISS
#3 – Needed-Now vs. Needed-Soon vs. Maybe-Needed-Later
#4 – CSS & The DOM
#4a – CSS Selectors
Some suggest avoiding CSS selectors completely. As Steve Souders suggested, I don’t think we need to go that far. However, it’s probably a good idea to avoid the following as much as possible:
- too many rules (there’s that KISS principle again)
- id selectors with anything preceding the “#”
- class selectors with anything preceding the “.”
- descendant selectors that descend too much
- overqualified selectors (see Buckthorn’s comment in Souders’ article)
- universal rules
- counting from the end (e.g., :last-child, :last-of-type, :nth-last-child(n), :nth-last-of-type(n))
- anything a novice maintenance programmer would struggle with (likely a performance problem, but will cause other problems, too)
- CSS expressions (only allowed in certain non-conforming browsers; now deprecated in those browsers)
Most of these tips come from Writing Efficient CSS, written 2000.04.21 by David Hyatt.
Very generally speaking, an id selector (e.g., #menuitem) is more efficient that a class selector (e.g., .GaebelQuote), which is more efficient than a child selector (e.g., p>img), which is more efficient than a descendant selector (e.g., p img).
Some suggest that CSS performance is a non-issue for most websites because their CSS is simple enough not to become a problem. It is still a good idea to avoid the above selectors to keep future performance issues at bay.
#4b – Reflows
#5 – Compression
#6 – Caching & Memoization
- browser caching,
- intermediate caching servers,
- caching of file contents in memory instead of on disk,
- HTML produced by the web server’s content generator,
- server-side opcode caching,
- resolve file path caching (relative->absolute paths),
- query caching in the database,
- client-side opcode caching,
- caching session data in shared memory instead of on disk,
- program-controlled memoization,
- and others that I may have missed.
Some forms of caching need to be turned on. Some need to be configured. Some are built-in and automatic. Developers need to make sure caching is configured optimally for their websites and that it is actually being used.
Intermediate caching servers and browsers need to know when each component expires. Until that time, they will use the locally-cached copy. After that time, they will ask the server whether the locally-cached copy is still valid. If it is, they will still use it. If it isn’t, the server will send them the newest version, which they will then cache. We need to make sure the expiry date is as far into the future as possible.
To maximize caching, set all expiry dates 100 years into the future. If a component needs to be changed, rename it (and all references to it). Never reuse a name.
#7 – Number of Connections
#8 – Third Party Resources
#9 – Develop Good Programming Habits
#10 – Benchmarking & Monitoring