Blog
Gzipping content may make Firefox unbearably slow
I set out yesterday on an enormous task, to improve the performance of my PHP framework, Hierophant. I've been working on Hierophant since early 2005. One area that I never put much focus into was in the area of download and page load performance. It was always on the todo list, but kept getting pushed back for one reason or another. So yesterday I set out to patch this gaping hole in my framework's functionality.
I began with the most obvious enhancement, supporting gzip for various dynamic HTML documents, CSS, and JavaScript. Gzip can reduce the download size of a document somewhere in the neighborhood of ~67% for most documents. For example, I took Base2's already compressed base2-dom-fp.js (original compressed with Dean Edwards's Packer) and took it from 47KB to 15KB. Stylesheets went from 10KB to 2KB.
In addition to gzip, I implemented aggressive caching, setting the expiration times of scripts, stylesheets, and most images to 10 years.
So, agressive caching and gziping should alleviate a hefty chunk of performance issues, right? It did, in fact, in IE6, IE7, and Safari. But not in Firefox. Firefox 2, and the latest Firefox 3 Beta 5 were slower with gzip turned on than with it disabled. Not just a little bit slower, a lot slower. It takes literally eons for Firefox to load up gzip'd content.
Safari and even, gasp, IE6 and IE7 run circles around Firefox with gzip'd content. On the other hand, disabling gzip in Firefox brought its performance back on par with Safari and IE, which is completely baffling to me.
Ultimately, I did the only thing I could have done and that was to disable gzip for Gecko-based user agents, and left it enabled for all else.
So word to the wise, if you're going to experiment with gzip, Firefox and its Gecko-based brethren may not be up to the task.
Going back to caching, how do you update content that is set to expire 10 years in the future? In my framework I opted to append the last modified time of the file to every path output to HTML. So, for a script you'd see a path that looks something like this:
/Library/base2/lib/base2-dom-fp.js?hFileLastModified=1207280248That causes the document to be stored indefinitely, per the client's settings until the path changes. When the timestamp changes, the file automatically updates on the client-side. And I'm taking the same approach for images. This method allows you to utilize external scripts and stylesheets to their full potential, and as a result makes browsing blazing fast. Combine with other various optimization techniques, and you can make your site even faster than fast!
As a side note, if you've never heard of Hierophant before, I'll be blogging about that more in the future.
OK, "em" Units Just Might Be Useful...
A bit of an about-face in my thinking has taken place recently. A while back I wrote a blog post about how I think "em" units are worthless for their intended purpose, that is to say, scalable font design that can stretch or contract to accommodate changes to the font size.
I still think that em units are probably never going to see the kind of use that some standards advocates hope they will. That's just one cold, hard truth of the web... you can make the tool available, you can outline its benefits in no uncertain terms, but the majority of so-called developers and designers out there are either completely uninformed, don't care, or both. So I don't believe that the usability portion of the em unit will ever be realized.
But after some thought, I did have a change of heart about the em unit itself. You can do some very cool things with em units. One example would be animation. You could design a box so that it's dimensions are all em based, then with a little JavaScript you could animate its size doing nothing more than changing the font size of the containing element.
Don't get me wrong folks, I long for the days of resolution-independent, scalable design, vector graphics, and accessibility. I just don't think em units fulfill the usability role very well, since most developers won't use them. Now that all of the major browsers are implementing the zoom feature, I think that will make the em unit obsolete for that particular application. And yes, zoom isn't perfect, its clear that will need to be refined too. But the em unit is an incredibly useful feature, and I recant saying otherwise.
First Impressions of IE8 Beta 1
It's pretty buggy. Lots of stuff coded purely to standards and not to a particular browser isn't rendering correctly. All in all though, that's expected, this is not the final product, they're still hammering away on some pretty big things.
On the topic of CSS, I'm happy to see some big things from CSS2 that are finally being supported. The table display types, the box-sizing property, generated content. I'm disappointed that they still haven't done much with CSS3 though. Some things in CSS3 seem pretty trivial to me to support, like most CSS3 selectors, for example, or the :target pseudo-class. JavaScript libraries on the client-side have been supporting CSS3 selectors for ages in their various Selector API implementations.
On the JavaScript front, I'm pleased to see that IE8 will support the querySelector() and querySelectorAll() methods from the new W3C Selectors API draft specification. That makes Webkit and IE (of all browsers) the first native implementations. That's a prediction I made that I'm pleased to see fulfilled.
I'm puzzled about some baffling ommissions in the JavaScript arena as well though. Why don't we finally have W3C events? Where are things like DOMContentLoaded, forEach, etc. The IE team, at least, in my opinion, could deliver more here, and again, it seems pretty trivial to me for them to add support for most of these things. So why are the improvements so slim?
Perhaps we can hope that the IE team is not yet finished with their improvements, but IE team, if you're listening, please add support for as much of these trivial things as possible. I appreciate the big, complicated bug fixes, but, in my mind I see a lot of little things that you could easily add support for, but for whatever reason are not. I'm not going to make blanket statements like, why don't you support x specification entirely, nor am I going to spit in the face of what you've accomplished, I can see that what you do have is pretty significant, but try not to overlook the smaller things that make everybody's life easier, that you could probably get an intern to do on a Sunday afternoon.
Satan Needs a New Winter Coat
Temperatures plummeted to new record lows in hell today on the recent news of an about-face to IE8's standards mode default. If you haven't been living under a rock, I'm talking about the recent news that IE8 will, in fact, by default, act like IE8.
If you still need IE7 compatibility in IE8, fret not, there is an out for you in the form of Microsoft's <meta> tag/HTTP header proposal.
Seriously though, this is no less than awesome. The amount of goodwill and thanks shown by the development community on the IE team blog is unprecedented.
I woke up this morning with a strange, unyielding desire to hug Microsoft. It looks like the web is finally going to move forward in a big way.
This makes me feel like the end of Return of the Jedi, when on Endor, Hans and his Ewok friends finally managed to bring down the Empire's shield generator so the Death Star and the Galactic Empire could be obliterated once and for all, and then it was, and a victorious inter-galactic celebration ensued! Showing my true nerd colours.
Why I don't bother with "em" units anymore
I used to think that "em" units were the bee's knees. The cat's meow. The way it should be done.
Then I encountered weird bugs and design glitches and spent hours trying to figure out how to fix them. IE 5.5 was a real bear to whip into submission. IE 6.0 has some trouble with em units too.
Then I saw how Opera handled text zooming by zooming the whole page, rather than just increasing the text size. IE7 followed suit. And now Firefox 3 will support it too.
So I came to a rather obvious conclusion. The simple fact of the matter is that the overwhelming vast majority of websites do not implement designs in em units and never will. At that only a fraction of the percentage of people implementing bonafide, best practice oriented, standards-driven designs will bother with em units because of the design complications it introduces.
On the surface it's a cool idea, and makes you feel good because you're promoting an accessible design. But it doesn't work in the real world, and is a feature of CSS that is doomed to failure because it puts the burden on the website designer/developer rather than the browser, and it's a burden you can completely ignore, so most people do.
When you give it any thought you realize that page zooming is the correct way to approach the problem, because it works for every website, even the bloated, non-standard crap infesting this web's hallowed halls, rather than only the handful that take text resizing into account.
Visual disabilities are pretty common. There are a lot of people who have trouble reading text... however... the "em" battle is a battle that cannot be won... and page zooming is a superior solution to the problem that helps people with visual disabilities surf the whole web without hindering a single site. If I know someone with visual disabilities that need to be able to zoom text, I'd recommend Firefox 3, IE7, or the latest Opera.
Page zooming should be standard. em units (and similar units) should at the very least be abandoned for this purpose if not deprecated all-together.
A Shrink-to-fit Epic: You Too Can Make IE Your Bitch
Yes, you too can make IE your bitch, if you're determined and crass enough.
Throw your sensibilities about logic and standards out the window, because you don't need them here.
Recently, I set out to implement a simple, seemingly remedial technique for custom borders and backgrounds on tabs in none other than everyone's favorite browser, IE6.
It's worth mentioning, IE7 also gave resistance to this technique, but was slightly easier to whip into logic.
A battle of wits was to ensue. Would I let it defeat me? Would I let it send me back to the bowels of table layout or less-semantically reasonable markup? No, damn you, IE, you will not take me without a fight!
This technique is a rather easy exercise in floating elements and custom borders... I set up a list... not unlike this one:
<ul id='tmpProductTabs'>
<li id='tmpProduct-Overview' class='tmpProductTab tmpProductTabSelected'>
<div class='tmpProductTabWrapper'>
<div class='tmpProductTabTopOuter'>
<div class='tmpProductTabTopMiddle'>
<div class='tmpProductTabTopInner'>
</div>
</div>
</div>
<div class='tmpProductTabOuter'>
<div class='tmpProductTabMiddle'>
<div class='tmpProductTabInner'>
<span>Overview</span>
</div>
</div>
</div>
</div>
</li>
<li id='tmpProduct-Warranty' class='tmpProductTab'>
<div class='tmpProductTabWrapper'>
<div class='tmpProductTabTopOuter'>
<div class='tmpProductTabTopMiddle'>
<div class='tmpProductTabTopInner'>
</div>
</div>
</div>
<div class='tmpProductTabOuter'>
<div class='tmpProductTabMiddle'>
<div class='tmpProductTabInner'>
<span>Warranty</span>
</div>
</div>
</div>
</div>
</li>
<li id='tmpProduct-ApplicationNotes' class='tmpProductTab'>
<div class='tmpProductTabWrapper'>
<div class='tmpProductTabTopOuter'>
<div class='tmpProductTabTopMiddle'>
<div class='tmpProductTabTopInner'>
</div>
</div>
</div>
<div class='tmpProductTabOuter'>
<div class='tmpProductTabMiddle'>
<div class='tmpProductTabInner'>
<span>Application Notes</span>
</div>
</div>
</div>
</div>
</li>
<li id='tmpProduct-Firmware' class='tmpProductTab'>
<div class='tmpProductTabWrapper'>
<div class='tmpProductTabTopOuter'>
<div class='tmpProductTabTopMiddle'>
<div class='tmpProductTabTopInner'>
</div>
</div>
</div>
<div class='tmpProductTabOuter'>
<div class='tmpProductTabMiddle'>
<div class='tmpProductTabInner'>
<span>Firmware</span>
</div>
</div>
</div>
</div>
</li>
</ul>
OK, so that's a lot of markup for a simple aesthetic enhancement. Namely, I just want rounded corners on my tabs! For the love of God, why does it have to be such a chore?
I covered a similar technique in my second book, CSS Instant Results, but admittedly, it was just a tad more remedial.
To get the custom border effect, I divide an image created in PhotoShop or your graphic editing environment of choice into nine slices, for the top left corner, top middle border, top right corner, and so on. In HTML, I need three block-level markup elements for each slice, and depending on what copy is being inserted a separate inline or block container for the actual content going in. Then, using nothing more than CSS background properties, I specify a background image for each markup element.
Still with me so far?
So, in this tidbit, I have the top border elements prefixed tmpProductTabTop. To make the slices work, all you do is put the left slice in the outer element (non-repeating, positioned, ahem, top, left), the right slice in the middle element (non-repeating, positioned, top, right), and then in the inner element, you specify the top middle slice, and repeat it along the x-axis, positioned to the top. Then you set the left and right margins of that element equal to the widths of the left and right sides, respectively. Finally, and this is important, if the element has no content, you need to give it a height equal to the height of your slices, otherwise it will be invisible.
Semantically speaking, this is all completely meaningless. It clogs up your page size and bandwidth, but it's pretty safe, in my opinion.
Now, for our old friend IE. To make this lot into tabs, you float the <li> elements, and given them a bit a margin on the left or right sides to separate each tab.
When you float an element, its sizing model becomes shrink-to-fit, aka shrink wrap. The element expands only enough to accommodate its content. However, IE has this mechanism called layout, a vile, evil device designed to torture web developers. Whenever it is triggered, Microsoft actually slaughters a baby kitten, and the world turns just a little more gray. Layout is triggered when you use a select handful of properties, one of which is explicitly setting a width or height on an element.
In terms of floated elements in IE, when a floated element contains a block element, and that block element has "layout", the floated element's head spins off and it switches from shrink-to-fit mode, to expand-to-fit (against the standards, of course). In other words, your layout is screwed, your kids start doing drugs, and Bob's your uncle.
In my case, the little, completely logical thought process of giving that inner element an explicit height wreaked havoc with my layout. How stupid of me to consider that a possibility...
Sigh... but... once you know of this evil plot, you too can overcome it with a quick well-thought-out flank of the enemy's position. Instead of height, set the padding. Padding will not trigger layout.
Ah, but Richard, my layout, it's still screwed. Worry not! For there is more for you to learn! If your sliced images' height is less than the default font size or line-height, you will have to zero out those properties as well to get layout serenity.
But wait, my elements aren't even visible! For the love of all that's holy, give each element a relative position... and they will materialize again.
Thankfully, these woeful requirements do not affect the rendering splendor of better browsers. You may be left with some minor aesthetic glitches in IE6, however, if that is the case use the star html hack to fix them.
I would like to share the actual CSS with you, but I'm too lazy to format it, and I don't yet have a code formatting algorithm for this nifty blog. If popular demand requires it, I shall accommodate.
See also: http://www.satzansatz.de/cssd/onhavinglayout.html
Go in peace.
I Heart Webkit
Let's all have a love-in for Webkit, the first browser to officially support the new W3C Selectors API.
Curses, foiled again!
I've come, I've saw, I've done battle with the big blue "e"! Curse you Internet Explorer! Were you real, we'd have hunted you down and strung you from the gallows like the dog you are!
I will make you my bitch, if it's the last thing I do!
The IE8 Standards Default is Wrong, Wrong, Wrong!
Kudos to the IE team for making the HTML5 DOCTYPE invoke "super, super" standards mode without the <meta /> element. Still unknown are the XML and XHTML MIME types, one can only assume those trigger super standards mode too.
The more I think about this idea the more I think about how there could be other ways, and how this idea is the wrong one.
One flaw that I can see, beside the obvious ones I've already talked about is that the new rendering mode switch is also an HTTP header. This being the case, what if proxies, ISPs, firewalls, or HTTP servers decide to, by default, include this HTTP header, X-UA-Compatible: IE=edge? Then none of the supposed benefits of backward compatibility remain because depending on who gives you your content, someone with an agenda could decide what rendering mode is best for you. For example, let's imagine that the Apache software foundation decides to, by default, include this new HTTP header, a scenario that isn't too far off considering how badly received Microsoft's proposal has been.
Another thing that strikes me as wholly unreasonable is how the IE team, and the few people that agree with them, seem to have their heels dug into the sand on this issue, and seem to see this <meta /> tag as the only possible solution to their quagmire. Also unnerving is why only a few industry experts were consulted and the community at large were not? I like Meyer, Zeldman, Koch, WaSP and all, but they don't speak for me, I didn't elect them to be my representatives, and I strongly disagree with their respective stances on this issue.
This idea means that IE7 never dies. Already we have forever set in stone and forever available the backwards compatibility mode that we all know and love, quirks rendering mode. There is no official cut-off date for this rendering mode, even when the web has advanced to HTML 6 or 7, we'll still see web pages from 1993 able to go on about their merry way in quirks compatibility mode.
Technology changes, it's a fact of life. In this technological adolescence, we aren't going to get things right on the first try, or the 2nd, or the 3rd, and we know that nothing will ever be perfect and not everyone will be satisfied. Does that mean that we keep our mistakes and our inferior ideas around and in-use forever? Soon analogue television will no longer exist in the United States. A clear, definitive cut-off date was established by the FCC. By 2009, analogue television will be a relic of the past. Some people aren't happy that this event is imminent, and are fighting it profusely, but the technological improvements and innovations that will come from this obsolete technology being put by the wayside are too great to ignore. And it doesn't hurt that the replacement services will be far more lucrative and efficient than those that came before it.
That is another flaw that I see with Microsoft's proposal, and, in fact, also with quirks rendering mode. There is no cut off date for backward compatibility, no point in time where the old, obsolete way of doing things can be formally abandoned and the world as a whole move forward. We can't say, update your content by this time, or risk it breaking.
With this frozen in time approach to rendering, we'll be teaching and coping with the ways of Internet Explorer past for long into the future, this significantly raises the bar for new web developers, who already must struggle with an immense amount of information.
Additionally, where is the incentive for these websites with horribly outdated code to move towards a more standards-compliant approach? Sure, I understand that some people don't care about standards, but, in my mind, if you can't be bothered to read the blueprints on how to build a website, then why should you be guaranteed your website work forever? The web was designed to be interoperable and platform neutral. Some companies didn't approach the web that way, they thought that the web was Microsoft's, and Internet Explorer's. So, Microsoft, you want to make a way for those vendor lock-in sites to continue to function? Then do it with Active Directory, and leave the web alone. Intranet sites are the anecdote of the day for this compatibility mode... use intranet tools to fix the problem.
For the web at large, if you're really hell-bent on compatibility, design a database just like you did for phishing. Start with your biggest customers, because apparently those are the only people you care about, and the only people who have any say in the future of the web. (Prove me wrong, I want to be wrong about that!) Put those hostnames in a database that triggers "backward-compatibility" mode. Give the hostname owners a way to remove their hostname from your database, or opt into better standards compliance through a code-based override.
I did everything I was supposed to do. I used only conditional comments to target specific versions of IE to hack specific IE bugs. I didn't use CSS parsing hacks because I recognized they were a really dumb idea from the start. I didn't blindly target IE without also targeting the version. I taught others to do the same in my CSS books. And yet Microsoft still expects me to make up for the incompetent assholes that didn't do it right. Fuck that. So, you painted yourself into a corner? Fine, I understand. Find a way to fix it that doesn't put standards in the back seat and that puts a definitive cut-off to the old way.
This approach facilitates vendor lock-in, preserves the old, tired way of doing things perpetually, and punishes the wrong people.
HTML 5 DOCTYPE
So it turns out that IE8 will trigger "IE8 Standards Mode" for at least the HTML 5 DOCTYPE, and according to Chris Wilson "any unknown DOCTYPE".
This makes the proposal of the <meta /> element a little more palatable, but I still feel it isn't enough.
What I'd really like to know is do XML and XHTML MIME types trigger standards mode? And are there are any other DOCTYPEs that will trigger standards mode?
Based on currently available information, I don't feel like the HTML5 DOCTYPE is enough... if Microsoft would just be more forth-coming with information then I don't think this would be nearly the issue that it is. There are a lot of unanswered questions that any one of the IE team members could have spent five minutes on a blog post answering. And speaking of the closed nature of Microsoft, Molly Halzschlag has posted a blog article on this very topic.
