Minimalistic code

When I'm writing a web page, I'm always trying to write as few letters, numbers and other signs as possible, because the fewer the signs the faster the page will load.

Generally speaking, I believe that to be true, though it's problably not true in all cases. Further, you won't notice the difference in loading speed between a page with relatively few signs and one with relatively many signs unless at least the bigger page is quite large.

But even if your web pages aren't that big for the moment, they may be in the future when you have added more content and more functions. If you try and write minimalistic code long before your pages have grown so much that loading speed becomes an issue, there's a good chance it never will be.

In December 2006, the size of the presentation page at mkforlag.com was about 10 kB. When I'm writing this article in April 2010, the size of that page is about 130 kB (if you include the HTML code as well as the PHP code, that is). Admittedly, I will probably remove about 30 kB of the content on almost all pages at mkforlag.com as part of the ongoing development of the next version of the site, but even then the size of the startpage will be about 100 kB, an increase of about 1000 % over a four and a half year period. [1] May 9, 2010, the size of the presentation page is actually only 28 kB. Why? Because I decided to convert the menus that appeared on the presentation page (and almost every other page, by the way) to separate pages. The downside is that the menus will load somewhat slower. The upside is that almost every other page will load considerably faster. I haven't benchmarked this, but an educated guess is that the overall performance for most visitors is at least somewhat better.

And the increase most certainly won't stop there. The more fluent I become in languages like HTML, CSS and PHP the more functions I want to add to my web pages.

And if I hadn't taken that much care as I have to write as minimalistic code as possible, my pages probably would have been maybe twice as big as they are now. That's not as much a guess as it may seem. In fact, that's about how much the size of my pages had decreased a couple of months after I stopped using the design view in Dreamweaver and started using the code view. Not to mention how big the pages would have been if I had continued using MS Word, as I did at first!

Suggestions

When a web page has become so big that you notice it takes time to load, I think you should consider splitting it into several pages. Especially pages with many pictures, for example blog pages, would benefit from such an action, I think.

However, before beginning to split a page, you should ask yourself what's most important: increased loading speed or keeping related content on the same page.

For example, I use flash videos for my image galleries even though they take a few seconds to load. There are at least two reasons:

Firstly, the flash format is very compact, which makes the total loading time much shorter than if jpeg or png images are used. If I had used png images to the gallery Pompei, for example, they would have occupied 12 MB disc space, while the flash video made of the same images only occupies 0.8 MB disc space.

Secondly, when a flash video is loaded, the visitor can click from one image to the next without having to wait for the next image to load. Much smoother, I think.

There's also the opposite to web pages that are too big: web pages that are too small.

For example, many of the tutorials on web technologies I have read are split into several very small pages. I see no reason to split content like that. It's much easier to scroll up and down the same page than clicking back and forth between several pages, especially if you aren't that familiar with the website.

Conclusion

Try and write web pages with as few signs as possible.

Split bigger web pages into smaller ones.


Would you like to comment on this page or some other page? Use the contact form. Write the title of the page you want to comment on and your comment in the field Message.