After spending a few months looking over the huge number of resources on optimizing websites, a few features have emerged:
- There are lots of ways to optimize your website, increasing speed, reducing CPU cycles, HTTP requests, and downloaded bytes
- Front-end developers bear the brunt of optimization, rather than server-side programmers
- Some optimize strategies are pretty simple to do, and could be included in “boilerplate” templates (though they typically aren’t at present)
- Other optimize strategies require understanding a great deal about servers and programming, and are unlikely to be implemented by a typical web designer/developer.
- Some require re-thinking the whole organization of your page and assets (which implies that we also need to re-think the design we got from the Art Director/UI/UX person)
- Lots of initiatives are unknown to the general web design/develop community (like the W3C Performance Initiative), even those interested in “sustainable web design”
- WPO (Web Performance Optimization) companies are springing up, but only large companies will be able to afford them
For example, I was totally unaware that a performance API was being developed by the W3C Web Performance Workgroup, and that stuff like what I write below was even possible:
var timing = performance.timing;
var loadTime = timing.loadEventEnd – timing.navigationStart;
Well, well, this looks like something almost everyone could play with in the future when it is available in all browsers (currently Chrome and newest IE).
But how to get the word out to all those hybrid designer/programmers?
To enable the hybrids we’re going to need rules, schemas, boilerplates that hybrid designers/(front-end) developers can use . If optimization is restricted to big teams, most websites won’t be optimized, period. If sustainability guidelines for projects become as severe as they are in, say, architecture, lots of smaller web developers won’t be able to compete for projects anymore. At the higher levels of the Internet ecosystem, we will have the biomimicry equivalent of ecological succession – the adaptable weeds will be replaced by big, unchanging forests far more vulnerable to environmental change. We’ll end up with big sites, huge compartmentalized teams, and less innovation and diversity in websites.
One can argue that this is something that happens to all media over time – the “little” professionals disappear and only big companies are left (think of 1920s radio versus radio today) – but it runs counter to the goals and intent of the web itself, as it has been conceived. Imagine a world where you have to make sites sustainable, and it costs about $50,000 US to do so. That’s a world more like network cable and, and less like the web today.
So, it makes sense to spotlight ideas that are relatively unknown, but can be implemented by the general web design community to improve sites and meet larger goals of “virtual design sustainability”. So, one thing I’m going to do is to start showcasing ideas that anyone can implement during the development process. Here are some related to CSS.
Simple Stuff in CSS
Lots of general guides out there, like this one:
I came across a neat example on Milan Adamovsky’s Blog on organizing CSS, with the result that the code is easier to maintain (project/team sustainability) and removes duplicate blocks and style properties (code download/execution efficiency).
To improve CSS, Milan suggests ordering your CSS by
- Use decreasing scope order (which is the exact opposite of what I do)
- Sorting everything alphabetically
To implement score order, you should set up your CSS files with general to specific rules, e.g.
- Tag-level selectors (DOM elements)
- Class-level selectors
- Id-level selectors
He doesn’t say where to put complex CSS statements, but other sources, e.g. Yahoo! Exceptional Performance say to leave them out entirely, as they are computationally expensive. I wonder if tools like SASS generate CSS statements, or “compile” down to RISC-like basic CSS?
Once you do the big sort, you sub-sort alphabetically:
- First, sort by the selector. Start with the “a” tag and end with “p” or later.
- After that, we sort classes from .aardvarkclass to .zebraclass.
- Finally, we sort Ids from #apple to #zulu.
After that is done, we sort the style rules alphabetically.
- Start with border:
- End with width: and z-index:
The benefit of this is that if you need to enter a new style selector or rule, you’ll be guided to a specific location in the CSS file, and if you have duplicate definitions, you’ll see them right away. Another (mentioned in the comments) is that Firebug automatically alphabetizes properties, so your code will match Firebug output.
More good rules about CSS Selectors
This page provides a rationale for creating CSS selectors. The take-home: make your tag selectors specific. use Id or class, rather than tag-level selectors:
It turns out that CSS evaluates a style selector from the RIGHT TO THE LEFT. So, in the following expression:
div ul li#second
the #second is evaluted FIRST. Then, the CSS engine checks to see if it is inside the li, ul, div ancestors. In other words, if we just use the #second selector, we’re already there – no need to write more. So it make sense to use ids as unique, and not bother with the description of where they are. CSS id lookups are pretty fast, compared to looking up a class, and looking up tag names is the slowest of the three.
This means that a CSS file could be refactored to remove the useless selectors. It also means that using a few ids and classes and avoid tag selectors could speed things up.
Here’s another CSS optimization example – this time, at a higher level by using a specific CSS construct. The Media object is a standard way of implementing a common UI element – left-hand avatar image, text to the right-hand side, some some additional links
The idea is to standardize a small widget of HTML plus css, in a way that makes it flexible-grid and cross platform, and relatively independent of its parent DOM.
Stubbornella extends the idea further with a designer-style implementation of “Object Oriented CSS”. The idea is to make common widgets using what I could call “design patterns”.
- First step – identify common repeating visual design patterns
- Second step – Abstract into an HTML/CSS/JS snippet of code
- Third step – Reuse throughout the site
This type of informal OOP (as opposed to making a OPP-based language cross-compile to CSS) allows for “drop in” things that will work, and accelerate “prototype in code”. However, it’s a sure bet that some visual objects will be very difficult to make into independent code snippets. Looking forward to more work in this area.
How to test it all
Right now, we don’t have any “web sustainability” tools. For the moment, Web Performance Optimization (WPO) tools provide a way to see if your site is becoming more sustainable. If you haven’t done so, you should install and use Yahoo! YSlow to analyze performance. Here’s a great link describing how to use YSlow in your development path: