Whimsical.Nu » Frontend Friday

FF: CSS Optimization Tips

Angela — Fri, 12 Sep 2008 05:00:10 +0000

A lot can be gained in terms of website performance by the wise use of cascading stylesheets and styles on the website, and these are relatively easy things to accomplish. They revolve around styles and stylesheet placement.

Stylesheets at the top

One important rule is placing stylesheets at the top, within the HEAD tags. While most browsers will load all styles eventually regardless of placement on the page, putting styles in the HEAD helps the page load progressively, giving users visual feedback that hey, something is loading. One of the worst things that could happen if your styles aren’t in the tag is that the page does load–but there are no styles attached to your HTML elements, and then the page flickers to include the styles. It’s like going out without your clothes on, and then going back in to put them on.

Externalizing stylesheets

Styles can be included in the page source code itself in two ways: either within tags, or within the style attribute of an HTML element. These are the “easiest” to do, however, it’s better if you put style rules in an external .css file, for a number of reasons:

CSS files can be cached for users, and subsequent returns to your page serves the CSS from the user’s cache instead of asking your server for a copy for download. Your page file size is smaller since it doesn’t have style rules associated with it, and the external stylesheet itself isn’t downloaded on subsequent visits if it’s stored in the visitor’s cache.
Other pages on your website can reuse this same external stylesheet. The optimization gains to this obviously means that all your pages will have a smaller size since there aren’t any styles on the source code itself. The development gains, however, are even better: one change in one file can update all your styles for your pages.

If your website uses a lot of inline styles, it may be quite a challenge to move them out to external stylesheets. It will usually mean a lot of editing and updating of files, the complexity of which depends on how fragmented your styles are.

Linking stylesheets instead of importing

There are two ways of including external stylesheets: via the use of the tag, or @import. The former links your stylesheet to your page, and the latter imports one stylesheet into another. The two ways look like below:

@import can be used to hide styles from earlier browsers, but in Internet Explorer, it behaves the same as using at the bottom of the page–which pretty much negates the above best practices I’ve talked about.

CSS expressions are evil

Okay, so Internet Explorer is quirky. Sometimes CSS expressions seem to be the only way to fix it–I’ve seen a couple of IE fixes/hacks that require CSS expressions. They look similar to:

width:expression(document.body.clientWidth > 799? "800px": "auto" );

Unfortunately, they’re run pretty much every time the user interacts with the page: they’re run on page render, on browser resize, on page scroll, or even if the mouse moves over the page. If one needs to dynamically set styles, use JavaScript. If you really, really need to use an expression, use one that, in the end, overrides the style declaration so that it’s only run once.

IE filters are also evil

The most frequent use nowadays of IE CSS filters are to fix PNG images in Internet Explorer 6 via the AlphaImageLoader filter:

However, this filter stops rendering and freezes the browser while the image is being downloaded, and since it’s done per element and not per image, each time this element shows up in the browser, you’ll get a bit of a freeze. It’s better to gracefully degrade to using PNG8 which works fine in IE6. If there’s no way out of using the AlphaImageLoader filter, user the underscore hack (_filter) or other IE6-only hacks to keep the style rule limited to IE6 users.

Good luck with optimizing your stylesheets! You can take a look at the other posts in this optimization series below:

FF: Minimizing HTTP Requests

Angela — Fri, 05 Sep 2008 04:00:10 +0000

As I mentioned last week, I’ll be talking about a few of my favorite techniques for making websites load faster–the rules and practices that I find interesting and intriguing as a web developer obsessed with a dash of challenge. ;)

One of the best ways to speed up website performance is by reducing the number of HTTP requests the website makes — it’s the first rule in YDN’s Best Practices for Speeding up your Web Site and YSlow, which is arranged according to what technique would have the most impact on your page’s performance. This rule can be quite tedious to do when optimizing a current website/layout, so the best case, really, is to start a project with this in mind.

The article explains it well, so I’ll just quote them (italics mine):

80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.

The use of CSS sprites has been around for quite a while now, and is the best way to reduce the number of HTTP requests to your server. A CSS sprite is basically multiple images combined into one single, larger image, which is then positioned into your HTML elements via CSS.

Can you imagine the conversation between the browser and the server for either case?

Browser: Give me the background for the Index menu item.
Server: Here you go, it will take around 1 second.
Browser: While I’m getting that, can you also get me the background for the Blog menu item?
Server: Here it is, another second for that.
Browser: And let’s not forget the background for the About menu item, too.
Server: Of course, here you go, you’ll get it in a second.
…

As opposed to when you use a CSS sprite for your menu items:

Browser: Give me the background image for the navigation menu items.
Server: Here you go, it will take a bit less than 2 seconds.

Short and sweet.

Note, however, that if your visitors are predominantly dialup users, this might not be a good rule for you to follow — mostly because you really can’t stuff any more data into that pipe than that pipe can handle. It will take longer for them to download the image, which will affect their perception of the website, as opposed to an image that gets downloaded faster and shows up on their browser faster. Remember those old-school rules about slicing header images? That’s basically rooted in that scenario: dialup can only download so much, so give them a couple parts of the header to download and see immediately. What’s best for your website depends on your target visitors.

There are a couple of CSS sprite tutorials and generators around:

CSS Sprites Generator – a simple generator, giving the sprites in PNG and GIF and giving background positions for each image
Website Performance’s CSS Sprite Generator – contains a lot more extra configuration options for sprite generation if you want finer control, allows you to choose what image format to generate
A List Apart’s CSS Sprites: Image Slicing’s Kiss of Death article
CSS Sprites: What They Are, Why They’re Cool, and How To Use Them
Image Sprite Navigation With CSS

…to name a few. If you’re just getting started with spriting, I’d suggest you create your sprite manually in your preferred image editing application before trying one of the generators and work on something simple like navigation or lists with icons for the first few times. This should give you a better grasp of what happens with a sprite.

Something to keep in mind: sprites will add complexity to maintaining your design. Adding another image to an existing sprite, updating your CSS code to reflect that (and possibly impacting current CSS rules on other images using that same sprite) is slightly more time-consuming than just uploading a new image and a new CSS rule to use that single image. And of course, the more images on a single sprite, the more difficult it is to keep that image and the accompanying CSS rules maintainable. One of the ways to combat this is to organize sprites according to use. As opposed to one über-sprite containing everything and the dust on the coffee table, a sprite for navigation and a sprite for list items separately is easier to maintain and organize.

Good luck with minimizing your HTTP requests!

FF: Website optimization

Angela — Fri, 29 Aug 2008 04:00:15 +0000

One of the things I’ve realized when I started working for Yahoo! is the importance and “interesting-ness” of website performance optimization. In an industry where things can get repetitive (how many

tags can you code in one day?), the challenges brought about by ensuring a website is properly optimized in terms of performance and page load is welcome and quite engrossing.

With high-speed Internet, a lot of times we tend to forget about the size of the files we put up on the Internet on our websites, much less worry about how long someone takes to load our website. It’s easy to forget, but when you’re on a crappy dialup or using your mobile phone as a model (er, like me while transitioning houses!), or you’re, say, a trouble-checker for one of the fanlisting networks out there, the wait for websites to load can take its toll, and feel painful on the pocket.

Two reasons why optimizing websites — even if you’re not Yahoo! — are:

You keep visitors longer, because the wait time is less, and people like things faster than you can chug them out. It’s all about instant gratification these days.
You save on bandwidth! Something smaller by even 10kb can mean megs or gigs of bandwidth savings in the long run. If you pay for hosting and you have a fairly popular website, this is a big deal.

A lot of this work is done on the frontend side of things. After all, once the server has cobbled together the page, the bulk of serving the page code and objects rely on the user’s connection. The HTML code is just one part of what’s served out to people, but images, stylesheets and other media are downloaded all after the source is available. And these are the things that users see and perceive. The image below shows around a third of Firebug’s Network tab on one of my websites:

Building and serving out the page takes up only 715ms. But the rest of the objects on the page are then loaded, and I end up with a 4.08-second load time. That isn’t so bad, but all the rest of the objects on that page form the bulk of the load time that users have to endure. If we save a few milliseconds from each object, overall we can get a snappier load time for the whole page.

In The Psychology of Web Performance, Andrew King highlight a few interesting results of bloated load times, in case you’re still not convinced:

Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006).
Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007).

Over the next Frontend Fridays, I’ll talk a little more about some ways to optimize frontend performance. I’ll mostly be going through the rules Yahoo! has published, but I will probably cherry-pick and talk about the ones I like most, the ones I like doing. Stay tuned :)

FF: Another look at skinning websites

Angela — Fri, 22 Aug 2008 04:00:31 +0000

I’ve always liked themes and website skins, the type where visitors can change the look of a website using a switcher. I even made a script for it. I think they’re a fabulous tool for making a website interactive, and giving users the power of choosing how they want to experience the website in question. This is most useful and prevalent in forums and boards, where users are many and varied: some prefer reading in dark environments, and some prefer lighter ones.

But of late I’ve been thinking that theming and skinning websites isn’t all that great, especially viewed in certain conditions. To clarify: I’m talking about a theme or skin being more than a color-only difference between themes/skins.

I realized that one of the drawbacks for me is the false sense of “interactivity” in the website. Understand, the websites I’ve skinned are all smallish fansites and fanlistings, containing minimal updates. Skinning has become one of the most popular “interactive” features of a fanlisting. Unfortunately, it’s lulled me into feeling that it’s “enough”. Which is a bad place to be for anyone who owns a website. More content and other forms of interactivity should be the focus; there are plenty of other ways to do that.

It’s lulled me into keeping old layouts around. I’m ashamed to say a couple of them are half-assed layouts that are there because the more skins there are, the nicer the website is! And, why skin a website when you only have two skins? So keep them all and give the users choice. Uhm, wrong tactic there. Skin retirement should be done semi-regularly, to keep layouts fresh and up-to-date.

I also can’t help but feel that there has to be some brand dilution there somewhere, unless skinning is carefully managed, of course. You have a subset of users using one skin, another subset using another, and unless these skins are quite similar (like the really nifty Day/Night skins I’ve seen crop up recently) the users of skin 1 will tend to approach the website differently from users of skin 2. Websites who’ll have these problems will probably be few and far between, but I can’t help but feel that this is a valid concern.

I certainly feel that skinning is one aspect of website interactivity that one should take a look at when planning a website, but shouldn’t be taken lightly. It adds a bit more complexity to managing the website and the users of the website, but when done well, it’s a fun feature for visitors. I still can’t get over the Day/Night skins some websites use; if it would work for one of my websites, I’m soooo there! ;)

But for now, I’m steering clear of skinning until I’ve real reason to use it.

Frontend Friday: Too much AJAX

Angela — Fri, 08 Aug 2008 06:00:00 +0000

Alex asked in last week’s Frontend Friday:

I just wanted to know how you decide how much AJAX is too much AJAX? You don’t seem to use much (if any) on this website.

It’s a good question, but the answer isn’t too straightforward: it will always depend on a large number of factors. For me, an indication of a developer/team getting too AJAX-happy would be when the site becomes unusable when JavaScript is turned off or isn’t working. For example,

a website that loads all (or most) of its content via AJAX, therefore rendering the page content-less without JavaScript; or
a website whose navigation is inaccessible without JavaScript.

JavaScript should enhance websites and applications, no doubt about that. Most, if not all, of the well-loved web apps of today are due to the snazzy-ness of AJAX. But we can’t always rely on JavaScript being present: even if users have it turned on, spotty connections and unexpected data returns can result in JavaScript being pretty much nonexistent. Progressive enhancement and/or graceful degradation should be important when working with JavaScript–whether or not you’re doing asynchronous calls or not.

However, like I said, the answer isn’t straightforward. Some applications really do rely on the existence of JavaScript, and for good reasons. Graceful degradation can be prohibitively difficult when you’re dealing with some specialized web applications, like mail: Yahoo! Mail and GMail come to mind. User interactions with both of these are so fine-tuned and uses a lot of convoluted interlocking parts, and degrading gracefully would be a pain. That’s why both apps have a no-JavaScript version as well (Mail Classic and Basic HTML view, respectively).

As for the second part of the question–no, Indiscripts doesn’t use any AJAX :) Mostly because I don’t see a need for it, or the “need” to use AJAX is lower than the time I have budgeted for designing and coding up my tech blog ;)

Frontend Friday: Got questions?

Angela — Fri, 01 Aug 2008 07:03:13 +0000

For this week, I’m doing a free-for-all: if you have something you’re curious about in terms of HTML, CSS and JavaScript, post your question in the comments and I’ll cover your question in future Frontend Fridays. Nothing is “too simple”, so feel free to post questions (please try to keep clear of Enthusiast-only questions though! ;) ).

The reason for this (rather abrupt) post is that due to my rather freaky schedule this week (I’m moving by end of the month, and we’re hopefully signing a tenancy agreement this coming Monday, finally), I wasn’t able to prepare for this week’s Frontend Friday. I had a draft in the works but unfortunately, it needs more research than I have time for this week.

Let me know in the comments! :)

FF: Hidden data in Jpegs

Angela — Fri, 25 Jul 2008 00:00:52 +0000

We all know about EXIF data in photos we take with our digital cameras, which is one type of metadata that can be present in images. This metadata provides additional information about the picture, and for photos taken with digital cameras it can include the make of the camera, shutter speed, aperture, and various other information. There are other formats like IPTC and XMP.

This metadata provides good information, but how important is that information when porting images on the web? Metadata is information enclosed in the file, hence any metadata adds to the file’s total size. This is good, except when we’re talking about, say, a preview/thumbnail metadata of a thumbnail image for your photo gallery. Redundant much?

I actually have been hit by this quirk–I kept wondering why my newly installed Photoshop kept giving me 100×100 jpegs that were 100kb in size! (Yes, I was making Livejournal icons.) I found out (after a week or so of confusion whenever I’d try) that I was including previews in my saved files because of a default setting. I got my 100×100 jpegs down to 39kb, from 100kb+. That potentially saves me ~61kbs of bandwidth per image fetch!

Stripping this metadata can be done via several methods. One is via the use of IrfanView, which I’ve heard around, but as it’s Windows-only I haven’t tried it out. I also found jhead, which is a free, open source program that runs on multiple platforms. It’s all command-line though, so if you like GUI, you might better stick with the former.

I did try out jhead, and I’m quite satisfied. It’s a quick, no-nonsense program which has a lot of capabilities, but it also does the job I want quickly: remove all metadata.

To use jhead, you should download an appropriate release from the website, save it somewhere, then open up Terminal (or the Command Prompt) and change the directory to where you downloaded jhead. If you’re using Linux/Unix/OSX, remember to set the executable bit if you downloaded the pre-built executable files by typing chmod +x jhead at the prompt.

For my case, I did a test with a background pattern I’m using at Seasonal Plume:

 $ ./jhead -purejpg stripped.jpg
Modified: stripped.jpg

And that resulted in an image that was 8kbs smaller.

This is a quick, painless way to help you save on bandwidth costs and have your websites load faster. I’ve recently gone through a Site Integrity Seminar at work and this is one of the things that I came away with that’s easily done to speed website performance. Given the fact that I did encounter this problem not too long ago, I hope this week’s Frontend Friday was helpful ;) and that you can use it for your own websites.

Frontend Friday: What do you do?

Angela — Fri, 18 Jul 2008 02:15:01 +0000

This is something that I’ve been wondering about for quite a while now: What constitutes “web development”, and what exactly are we called? The definition for this, ah, way of life/subset of tasks seems to differ from culture to culture, even from person to person.

I’ve come across the following, all on the subject of “web development”:

everything to do with how information is presented to the user; built up of HTML, CSS, images (spriting etc), and presentational JavaScript; or
everything that’s rendered client-side, which is all HTML, CSS, images, and all JavaScript, or
everything to do with how and what information is presented to the user; build up of HTML, CSS, images, JavaScript, and PHP that’s served to a browser
everything that has to do with the web: HTML, CSS, images, JavaScript, PHP, MySQL, web servers, etc.

Even though the web has been here for a while already, there seems to be a lot of differences between how we (who work on the web) are called, and what is expected of us. Personally I’ve always viewed web development as a mix of the last two options, basing on the phrase, “I develop for the web”. The lines blur especially when we’re talking about JavaScript and PHP. Both are programming languages, and might fall in the realm of software developers more.

As someone who works (be it as full-time work, freelance, or as a hobby) on the web, what do you consider part of what you do? Let me know in the comments!

Frontend Friday: Implementation focus on Indiscript’s lettered menu

Angela — Fri, 11 Jul 2008 00:00:22 +0000

For this week’s Frontend Friday I wanted to get a little more technical, and decided on focusing on and working though the implementation of Indiscript’s menus — the main navigation up top, and the script highlights on the sidebar:

What’s interesting about this implementation is that if I were to rename sections around, add new scripts to the sidebar, and otherwise need “new” menu items, I’ll never need to do anything more than just add the menu/link item, and every menu item or link presented this way makes use of just one 61.5kb image.

When I was working with the Indiscripts revamp, I knew I wanted something relatively simple, light, and easy to implement and extend for if/when I need to add new sections to the website. Usually that meant that artsy menu items were out…but I didn’t want to give up so easily. The result is the menu/link style you see now: an artsy letter serves as a background, usually in plain grey. The active menu item is green, and when you’re hovering over it, it becomes orange. If I wanted to use blue, pink, yellow, brown, etc–that’s all possible, with the help of CSS and PNG.

To make sure I have everything ready for if/when the time comes to add sections, I prepared a sprite image containing all the letters of the alphabet. For the uninitiated, a sprite (in terms of web development/CSS) is an image made up of several smaller images in measured distances from each other, in the interests of reducing HTTP requests and speed up website load times (see Website Performance’s What are CSS sprites?).

Part of my letter sprite looks like this (black background added for clarity):

A couple of notes on this sprite:

The distances between each sprite is carefully calculated, and yes, manually done. That means that if I have a menu item that is too long (say more than 550 pixels wide), the letter next to the sprite shows up. But we’re talking menu items here, anyway, so this isn’t a big issue. I could even go as low as a width of 300 pixels.
If you scrutinize the above sample, the letters are cut off at the top and left of the letters, because this forms the upper left corner of the menu item. There is pretty much no reason to keep the swirls at that portion of the letters, because it will be cut off, and keepting them would add complexity and raise the file size of the sprite. However, it is important to keep the swirls to the right and bottom of the letter, because the menu items will probably expand to the right and/or grow taller depending on the content of the item. Its limitation? I can’t have these artsy letters aligned on the right.
I could have used GIF, but I went with PNG. PNG is well-supported now, except for IE6, but basically PNG here lets me have different, CSS-specified backgrounds for the letter, and have the letter blend cleanly against the solid background. Win!

Once that’s ready, it’s time for the markup. Basically what we’re doing is we need at least two separate “layers” for each menu/link item. One for the colored background (grey, green, and orange); one for the letter on top of this, which should let the colored background show through; and then our actual menu item, if we have multiple-word-set menu items.

Time for some pretty code (with just one, current menu item):



  
    
      Blog
      tech babble

Now we need to have the menu list items line up horizontally, and we do that with floating things:

ul.menu li {
   list-style-type: none;
   float: left;
   border-right: 3px solid #fff; /* whitespace between each menu item */
   font-size: 85%;
   height: 54px;
   overflow: hidden;
}

We also need to color the background of an ordinary link to a nice light shade of grey, as well as tacking on additional colors for when we have a currently active menu item, or when hovering over. The current menu item is identified with a current class, but otherwise there shouldn’t be any classes involved. This one forms our background layer. We use the tag so that the whole item is a link, plus we can change the background color across all browsers (IE doesn’t recognize the :hover pseudo-class on anywhere other than tags).

ul.menu li a {
   display: block;
   text-decoration: none;
   background: #e7e7e7;
}
ul.menu li a.current { background: #bddcbd; }
ul.menu li a:hover, ul.menu li a:active { background: #eed6b4; }
ul.menu li a.current:hover, ul.menu li a.current:active { background: #bddcbd; }

The next layer is our artsy letter layer, which is the div with a class pertaining to the letter we want to show. First we need set up our actual swirl classes:

.swirl-a, .swirl-b, ... .swirl-x, .swirl-y, .swirl-z { background: url('sprite.png') no-repeat top left; }
.swirl-a { background-position: 0 -30px; }
.swirl-b { background-position: 0 -210px; }
...
.swirl-x { background-position: -1120px -210px; }
.swirl-y { background-position: -1120px -390px; }
.swirl-z { background-position: -1120px -570px; }

I just showed the classes for the letters A, B, X, Y and Z for simplicity’s sake. I separated the style rule for the common background to minimize code repetition. This can be tricky and a bit tedious, but a nice ol’ calculator can do wonders, if you’ve set up your sprite correctly. After all, the distance of all the sprites are calculated and measured.

Now we have the rest of the styles for our swirl

, as well as the

and
tags I use for the actual menu text: paddings, font sizes, colors, etc. If I ever need more menu items, or change a menu item’s name, I can just keep adding/changing the markup for that menu item, and everything’s set up for me immediately.

Hope this entry gives inspiration and ideas for more, better implementations. Feel free to ask away if something’s unclear. :)

Frontend Friday: Watch out for Divitis

Angela — Fri, 04 Jul 2008 00:00:37 +0000

Back when I first started using CSS, my favorite tag was undoubtedly the

. It was so versatile, and I did everything I could with that tag. It introduced me to absolute positioning and the CSS in general, and I’m forever grateful, but it also brought me away from the basics: HTML as a markup language. It’s also known as divitis: that is, having one too many

tags.

The result was code bloat, and once I started weaning away from this practice, I had hundreds of files to update, as they all looked like:


Some heading!
July 4, 2008
This is some of the content of the page. Yay!
Some subheading

(I’m sure if you look hard enough you’ll find a couple of my older sites still sporting this sort of markup.)

Movements and events like the annual CSS Naked Day woke me (and hopefully a few others) to the sad truth that as web developers and designers, we can be so obsessive about needing every single pixel in place, but completely forget about keeping the house clean. The impact may be minimal at the onset (i.e., “hey, everyone sees the pretty decors after all!”) but just like your house after a rush cleaning because people are coming over tonight, you have to deal with guests stumbling into hidden mess, things not in the right place, and a painful cleanup job afterward.

(Of course, there’s the other end of the spectrum where holy wars are raged between the use of a

 tag, which is just as bad, IMO.)
There are three things I do when working on a website to help me keep as close to “clean” as possible:

 Keep markup in the back of your mind when creating your design. The best example of this is creating a navigation menu. Can it be done in lists? What sort of arcane CSS-fu is needed to make it work like so? 
 Start with a bare HTML page. I’m doing this right now for a couple of projects. I have wireframes (structures) where I’ve laid out roughly where things are going, but nothing else. No colors, no images, no JavaScript, just plain ol’ markup-py goodness. 
 Once done, remove stylesheets and take a look. It’s easy for me to lose track of things when I’m on a roll, so this one personally has made me cringe a lot of times. Temporarily removing all styles from my work is a good way to see if it’s still readable and navigable even without all my pretty styles, and that it’s as close to how I designed it as possible. (This pretty much destroys all unordered lists masquerading as tables… so beware.) 
Remember: there are 91 HTML tags available, one of which might serve the need and communicate your intent better. But don’t force it: sometimes saying nothing at all is better than being misunderstood.