Michal Migurski recently posted an article about download sizes of popular websites. I couldn’t replicate his results ^[1] , but it is obvious that gist of Michal’s article is correct, websites have indeed ballooned significantly in last few years.

This blog’s homepage has a footprint of around 250KB-270KB ^[2] . About 90% of its size are fonts and jQuery which is a big penalty for making it look and behave a bit nicer. So should I remove those parts?

Well, for most visitors to this website that difference doesn’t matter. Pages for them are neither slow nor expensive to load. Unless of course they are doing it over your average hotel Wi-Fi or a slow mobile network where speed around 56Kb/s is not unheard of. On such connection it would take about half a minute to load this blog. It can also cost more than 10 euro cents to load it when roaming in Europe.

It would be great if I could offer a choice of serving bigger and nicer or smaller and faster version depending on visitors needs.

Measuring speed is not easy, but certainly doable as Gmail has demonstrated. You could start a timer immediately in page header, measure how much time it takes to load a smaller version of a website and if that happened quickly enough upgrade it to full bling. Android browser also added support for navigator.connection Javascript property which, where it exists, probably has more details than you would need.

However there is no way to measure price of a visit. Even if I could, how would I decide what is too expensive for an anonymous reader and should I make such decisions at all? I think not.

Gmail’s approach is really just a band-aid over what should be a visitor’s decision. I use same laptop and browser at home and while I travel, experiencing all combinations of connection speed and pricing. I never know how much it will cost me to visit a page, but I always learn quickly if I would prefer something small or full-featured. There is just no way I can communicate that preference.

It would be great if my browser had a switch for this purpose, like Firefox’s “Work Offline” toggle. So if I switched to bandwidth saving mode, then every subsequent request to web server would communicate my preference with a HTTP header field like:

X-Bandwidth: save

In principle you could have multiple levels of bandwidth consumption, but that would likely be an overkill. Common practice suggests that at most two levels would really get used, one aimed at mobile devices and other at desktop.

Header like that might be enough, but even better would be if Javascript environment got another property describing current state of user’s preference (like say navigator.bandwidth ). Coupled with a bandwidth event triggered on change you could really optimize every modern web page, even those with more complicated loading of resources and execution paths.

Right now such functionality doesn’t exist or at least I couldn’t find it (I even searched Mozilla’s bug database for any future plans). I think my proposal is both user and developer friendly and workable. If you can think of a reason why it would be problematic, then I would really like to hear it.

1. Pages are often personalized for visitor. Developer tools of different browsers also don’t report same sizes. They also report amount of data transferred not the size of that data once unpacked. Almost 2M of Twitter’s Javascript is thus reduced into page of “only” about 1MB of data transferred. And that to display couple of sentences. ↩
2. Depends on browser used. Variation in sizes is probably due different formats of fonts used by browsers. It also changed once I published this post. ↩

These have been eventful couple of days for web developers. CSS Working Group chair called on everyone to use all (most?) vendor prefixes and stop making websites for WebKit which is becoming a new (mobile) IE6. Responses have been numerous, including ppk who in his usual obnoxious manner ^[1] made some good points. Testing on mobile devices is an unsolved problem (who wants or can afford to buy so many almost immediately obsolete gadgets?) and introducing -beta- (maybe also -alpha-) prefix would simplify our lives while keeping most benefits of vendor prefixes.

I like -beta- idea and I think adding -alpha- might be even better. There’s still a problem of resolving syntax conflicts between different implementation which I think has a simple solution that closely mimics what browsers already do:

When parsing CSS browsers should apply the last matching -beta-/-alpha- directive they fully understand.

Browsers already ignore directives they don’t understand and they apply last directive found when there are multiple candidates for a DOM node.

Such behavior would give us less CSS code to write and maintain, have predictable behavior and keep browser experimentation without favoring one. I have troubles finding negative sides of this approach, but do let me know if you can think of one.

1. I deeply dislike his complaining about simplistic view of others while himself generalizing and name-calling (the lazy and stupid lot of us). Alas it’s not good to read only people you like and agree with. ↩
2. Almost everything I write on this blog has an intended audience of one: me (no, really!). Why I sometimes write posts like this, which don’t, is a mistery  since their expected and actual effect on anyone is…none.

Warning: this whole post is not much else than a series of speculations and amateur psychoanalysis. If you can’t find fun in that, well, then start reading something else.

I started using IRC almost two decades ago, soon after I came on Internet. I still do, but it’s now a very different experience mainly because today almost everyone is connected. When everyone is around, you tend to hang out largely with people you already know. Back then I chatted with faceless handles and what I found especially interesting were strong feelings and a sense of familiarity that developed between people who would never meet.

I thought of this recently again while discussing appeal of Tumblr and a neologism that I like — tumblrcrush. It wasn’t explained, but I understand it as having a crush like feeling provoked by a Tumblr blog.

I never heard of something like that related to WordPress although I am sure it happens. But I feel safe in hypothesizing that such visceral affection for a blog and by proxy for its creator happens more often on Tumblr.

Now, this is surprising on surface because so many Tumblr blogs look like nothing more than collages of other people’s stuff whereas old school blogs often have more what is disgustingly called original content and are more verbose — just like this one. It wouldn’t be unreasonable to expect that writing at length about things that interest me would reveal more about who I am then things I collect. After all I am more likely to divulge facts about me through my own writing than through other people’s work.

However when I write, it’s not really me who does it. Writing, even when trying to avoid self-censorship (unsuccessfully), engages a different part of a brain than responding to an image or a passage of text. I write so I can think, but even when not, I don’t just type a Joyce-like stream of consciousness . I form sentences I would prefer to utter, but usually don’t.

The genius of Tumblr (even with some serious interface screw-ups) is that it makes it easy to republish found stuff and really inviting to do it. Those pieces shared and reshared are revealing exactly because they were created by others. They never had time to be distilled and redacted closer to our self-image because they weren’t selected to represent us. Instead they are mostly curated by finder’s emotional response and its those emotions, part of finder’s subconscious (soul), that sometimes touches us.

Because what does it really mean to know someone? We may admire intellect, but we relate to the person. We don’t know a person until we empathize with her and those small shared bits are conduits for feelings, not information.

This doesn’t mean that you can’t write long, elaborate posts on Tumblr. Many indeed do. Just like many use WordPress to post stuff they found in some web back-alley. But it is Tumblr’s whole fun (and) social experience — unlike a serious, CMS-like sterility of WordPress — that nudges you into a different behavior. In creating we are guided by our tools with what they suggest, not what they make possible.