Here are some minor notes I jotted down during the redesign and partial recoding of our comparison shop engine (www.skroutz.gr).
Semantic HTML is the explicit use of html elements in your markup as they are meant to be used. This among other things means:
- UL/OL/LI should be used to mark related elements as a group. The use of the DIV tag should be avoided since it establishes a very loose coupling of the nested elements. Please note that we need to negate the default values for the LI
li {list-style-image:none;list-style-position:outside;list-style-type:none;}
- DL/DT/DD - Definition lists are very useful in expressing the right relation between a term DT and its definition DD.
- Use of all available HTML attributes. Especially useful the title attribute for showing information that might in the default view be truncated
Javascript minification is a must. Since we use prototype/scriptaculous and there isn't a default compressed version of the bundle available we use YUICompressor and the Rails :cache => true syntax to compress and bundle our js libraries. Log files indicate that a staggering 70% of our users hit the first page and request the otherwise browser-cacheable javascript.
In order to minimize page load time you can combine images on your site into one Sprite. This is one file with all images which can be used with the background-position CSS property to replace all independent file calls and thus avoid all unnecessary server back and forth. We were able to cut down asset calls on our frontpage from ~90 to ~70. For a quick view about how much you could save you can try Spriteme.org and their bookmarklet which will calculate and create a sprite for the site you calling it for.
All modern browsers allow 4 to 8 simultaneous connections to your domain. Have a look at your pages by enabling the net tab in firebug and find out how many calls per page you have. If you have a high enough number of calls you could increase the parallel downloads the browsers starts by spreading calls to your various assets (javascripts,css files,images) to various subdomains. So for the domain example.com you could create assets1/2/3.example.com and use them to reference different assets. Browsers will try to open their max allowed connection number to every subdomain, which means 12 simultaneous downloads instead of 4 when using 2 extra asset hosts. Carefull though that you are able to handle the extra load: Keep an extra eye on the max allowed open filehandles of your server OS allows in order to avoid DOS'ing yourself.
Less CSS or any other framework for creating a maintainable css file is invaluable given the complexity and depth of modern webpages. Less allows nested css rules which to the programmers eye are much easier to handle (folding is possible) and in the long term to maintain. Despite the name of the utility we use though, I have to admit that I am as verbose as possible with my CSS. DRY is a principle which I have found to not perfectly apply to CSS as it does to generic programming, since the variations of a generic CSS class are usually far more and complex then the functionalities of a generic method/class/module.
Last but not least some new tools of the trade that have proven themselves in the field of battle (kudos to @goldstein for pointing them out).
- tools.pingdom.com: Which calls all assets referenced in the css file allowing you to have a complete view of what you use.
- site-perf.com: Simulates browser load and reports back with load times and stats. Amsterdam mirror is nice for us europe based companies.