Now that the current version of this weblog has reached the end of its lifecycle and should give way to something new, I think about what I liked and what I did not like about it, what limited me in what I want to do and what should be continued in the next version. Changes will be incremental as I don't see much change in starting over from scratch.
Having a high content-to-code ratio is something I for sure want to continue. Currently, approximately 40% (33% ... 48% depending on paragraph count, currently 48%) of the code served to your browser is content, 60% are markup, layout and meta data. Decreasing the weight of these code elements increases content weight. How do I measure it? Have a look at the fine print section of my sidebar and click the "content ratio" link. A tiny Adrian Holovaty script does the math. Why is measuring it important, even with Adrian saying that results are trivia at best? A to be able to see if layout/markup code improvements actually work, B to keep traffic within control, and of course C to see how cool this web standards thing really is.
Benefits of web standards, namely page weight: everyone raves about it, hardly anyone actually seems to measure it. Saying "It loads fast enough anyway" is of no value, presenting actual numbers is. If you measure things, you can make qualified statements on page weight improvements and you can engage yourself in iteratively fine-tuning your layout/markup code. Maximizing content/code ratio minimizes the amount of traffic wasted on non-content. In its current markup version, this site causes roughly 6 GB traffic per month, consuming 60% of my free amount. With the introduction of a photoblog this is likely to increase heavily, so I want to make sure right form the beginning that most of what goes over the wire actually is of value. Anything below 40% content/code ratio won't make it into productive use.
Try GetContentSize with your own URL >
