Welcome everyone. Today I’m going to talk about keeping front end dependencies under control. I’m going to aim to cover the basics as well as some more advanced techniques, and give you a good overview of the options available for making your front-end development run more smoothly. Now I’ve noticed that a lot of presenters like to kick off their presentations talking about themselves and their experience. I’m going to put a little twist on that, I’m going to talk about my dog.

This is my puppy, Kenshin at about 16 weeks. Yes, this is a blatant attempt to cheat at presenting, since no one can resist puppies!

You can follow him on Twitter.

This talk is about control of things that start out nice but can quickly get unruly, like puppies. That’s him getting playful on the first weekend we had him, that’s his first chew toy which he destroyed in an hour, and that’s him passed out next to his first beer. (just kidding) As you can see, he was a natural born troublemaker.

Before we knew it, he turned into…this monster. He can run faster than any human we’ve met, he can knock anybody over, and he can jump a 4-foot fence with no effort at all. He’s extremely cunning and inventive in finding trouble. He’s also aggressively territorial and over-protective of us. We love him, but he causes us problems. The dependencies of your application start out small and cute and easy to control. If they don’t want to obey, you can pick them up and make them do things they don’t want to do. Then they grow up to be 90lb dogs that are smart and strong enough to do whatever they want - like dogs can quickly become unmanageable if you don’t send them to obedience class: you have to put strategies in place to maintain control of your front end. Little things add up. Dog trainers will tell you that every little interaction with your dog is teaching him behavior. Any time you let him get away with something he shouldn’t, you’re rewarding bad behavior. Any time you let your CSS, JavaScript or image break a rule, you’re letting your front-end application performance get a little bit more out of control. This is a talk about all the little, yet important things you can do to keep your front end dependencies UNDER CONTROL from the start, because it’s much harder to do in a complex application after the fact.

Let’s take a look at how pages are loaded into a browser. This screen shot from Firebug shows all the HTTP content that loads on the example web page. Every row is an element on the page, a dependency of the page. The page needs that information to render. Every element on the page is an HTTP request – a request to the server for something. This includes the entire HTML body of the page, any style sheets it links to, any Javascripts it imports, any image it includes. Every time you add something to the page, you’re adding another little hit on the server. This might not be such a big deal, since these hits may be small…except that they can add up. And even more then that, some parts can’t load until other parts are finished. This is where front end performance can be improved. By reducing the size and number of elements you’re loading, you can speed up the load time and responsiveness of your page. But we don’t want to sacrifice the ability to use scripts or images, right? So that’s why we need some guidelines and best practices for improving performance while getting access to the dependencies we need.

So just to be clear, here’s what we’re talking about when we say dependencies. JavaScript, CSS and Images. Anything else that has to load besides your HTML page to give you behavior and style. HTML depends on Javascript, CSS, Images for a complete front end, so we’ll attack some best practices in each area

Front end performance matters. In fact, Yahoo has did research that showed that most of the time to display on a typical web page is front end loading and rendering, not back end data access. This means that there is great performance gain to be had by improving the performance on the client side. This research is what led them to develop the front end performance analysis tool Yslow, and to publish their guidelines on front end performance. When you’re using a page of an application, much of the perceived speed of that application is in it’s responsiveness and pliability – how fast does it react when you interact with it? Is there lag between your click and the result? That’s front end performance. We spend a lot of time optimizing our code on the back end, but what do we do about the front end? Bandwidth is the big bottleneck that you can't control, but you can do many things to minimize the bandwidth you need to deliver a UI. Much of this talk will be about implementing Yahoo’s recommendation for high performance websites

When it comes to JavaScript, the culprits of slowness tend to be loading too many scripts, and loading them in the wrong places. It starts innocently with one really useful library. Then you find out that library doesn’t do everything you need it to do, so you add another library or perhaps a plugin. And another. And another. Soon you realize that maybe this library wasn’t the best one for your project, but it’s a LOT of work to go back and refactor and migrate to a new library. How do you keep it from getting out of hand, and how do you deal with it when you have to load more libraries than you might want to in a perfect world?

For starters, plan ahead. I think we can all generally agree that it makes sense to start with a preexisting library. Stand on the shoulders of the giants. But how do you choose? How do you find the library that will handle *most* of what you need, and last longer than the current version? Here are some things to evaluate: where does your project fall on the website-to-application continuum? Libraries tend to have their specialties. Effects, DOM querying and manipulation, AJAX/data, UI controls – or some combination of them. What parts and pieces are most important in your project? use a framework that matches and fits your style of development find a library that has all the parts you need, or at least complements what you have When you decide on a library, keep all your scripts in one place, a central script directory /js/ - this makes it easy to figure out what libraries you have available across a team, without installing one-off scripts all over your server. If you’re working with a lot of your own scripts, package them into libraries by feature so there are logical places to put new code, and it’s easy to find old code. For instance, you might create your own libraries for validation, or common display manipulation like showing and hiding elements.

Sometimes one library isn’t enough, or other technology you’re using is influencing your choices. A couple years ago, it was necessary to use multiple libraries to get all the features you need. Today, many libraries have added features and matured to the point that most provide a pretty wide range of features. Thus, the best pairings tend to be the multiple solutions from the same vendors, or pairs that are made to work together. Are you using cf? try EXT. CF makes it so easy to use EXT – there’s no configuration or installation, and there are CF tags for all the UI controls. EXT also covers a really broad range of features. If you’re using CF8 which came with EXT 1.1, and you haven’t liked it – I understand. But I’d encourage you to take a look at EXT 3 which will be included with CF9. It’s come a really long way and it now provides great UI controls, and DOM query features. Nothing is easier to use with CF. Another good CF pairing is CFAJAX and Spry. CF has a tag to easily convert data sets to spry data - <cfsprydataset>. And Spry’s effects and widgets are simple and easy to work with. Everybody loves jQuery. It’s so easy to understand, so lightweight and well supported. Between jQuery and jQuery UI, most of your library needs will be covered. Some of the more advanced UI libraries are more mature than jQuery UI, but jQUI does have a great themeroller which makes it drop-dead simple to match your UI controls to your application. jQuery plays well with *most* other libraries, but don’t assume that because you need DOM manipulation that jQuery is the only way. Most other libraries now have mature DOM components that do the same thing as jQuery, so that can mean loading one less library – just by being aware of what features your library does have. YUI is end-to-end – they have a comprehensive list of controls and utilities so it’s a very complete solution. Being Yahoo, the creators of Yslow and the first to crusade for front-end best performance, they also support all the best practices in this talk very well. Then there are some of the more old-school (and by old school, I mean a couple years) libraries that are still solid choices that work well together – Prototype as the core library and scriptaculous for effects. I’m not going to attempt to provide a compatibility matrix here, you should find out about any compatibility issues as you consider multiple libraries.

I can’t say it enough. Externalize your scripts!! It forces you to write code that is more modular and reusable, forces you to think longer term about how you construct scripts, and it enables those scripts to be cached. If you’re writing more than a few lines of JavaScript that is page-specific, it’s still worth externalizing it. However, if you get into the habit of writing external scripts, you’ll probably find you write them a lot less and import them a lot more. So let’s talk about some best practices for loading external scripts. Because scripts have the potential to load their own content or manipulate existing content, nothing else can download or render while a script does. IE is also known to simply refuse to load pages with scripts in the body if they attempt to modify the DOM or use a document.write(). Therefore, it’s best to put scripts at the bottom of the body element, right before the closing bottom tag. Simply moving a script from the middle to the bottom can substantially improve loading performance.

Not only should you load scripts in the right place, you should load elements ONCE, and only when you NEED them. This sounds obvious but it can get tricky when you’re working with pages involving many view files – as is often the case with frameworks, or you’re trying to create small, self-contained bits of code – how can you ensure that the script that’s required for that file is available, while not loading it again? Sometimes you only need certain elements or scripts, and not the whole package. So how can you make sure that you only load what you need, when you need it…while only loading it once? One technique is to manage it on the client side. This example by Christian Heilmann does just that. What it essentially does is keep track of what’s loaded with JavaScript, so you always have a variable available to check and determine if a script is loaded or not. Here’s how it works Define an object for the entire app (a good practice) Define objects for each script you might use, then assign properties for the URL of the script, and a flag to tell if it’s loaded or not Define a function that adds any of the defined components, first checking to see if it’s loaded already, and if not, adding it to the script stack To use it, on the page where you need a script, you’d simple call the addComponent() function for the script you need, and the rest is taken care of for you You can either use this example, or roll your own that has any additional features you need

There are also open source and commercial libraries that do the same thing. Yahoo has their loading utility for YUI. It also has a GUI that lets you click to choose what parts and pieces you need, it builds your import code for you and gives you many optimization options – pretty cool stuff. Dojo has their loader component. There’s a framework dedicated just to loading JavaScript called AJILE. The best one for you is what you’re comfortable with. If your library has one, use it. If not, consider one of the general libraries like AJILE or writing your own.

This can also be done on the server side with what I call a “bundling” component. There are a few versions available for CF and other languages, in fact the first one I saw was PHP. These components work by taking a list of files that a page needs…then the component concatenates those files together, shrinks and compresses the complete file, and caches it on the server. You use a simple CF tag to pass in the list of files that a page needs. If the component finds a cached “bundle” of files that matches that list, it uses it…or it creates it on the fly. The two most popular ones for CF are Scriptalizer and Combine.cfc This is an example of Scriptalizer by Aaron Lynch. Basically, if you use this tag and CFC combo, you hardly need to worry about any of the other loading issues. It works with both JS and CSS, you just need separate instances of the tag because of course, you don’t want to combine your JS and your CSS files. It’s not something you’ll want to use in development, but it gives you the freedom to work with as many files as is convenient, without worrying about all the loading overhead. I’d encourage you to do some testing in your own application to see what mileage you get out of it. The overhead to use the component may not exceed the benefit in load time. So you have to weigh that benefit against just combining the files together and minifying them in your build process. However, I will say that in my experiments, my results were about an 80% fewer bytes loaded, and about 20% faster load time.

So we’ve briefly touched on this already, but let’s get into it a little more. In addition to only loading files you need, you want to make sure the files you load are as small and efficient as possible. You can try to minimize white space and line breaks, use short variable names, avoid comments and use shorthand syntax… but all of that makes for unreadable, unmaintainable code! Don’t worry, you can continue to write code how you like without worrying about those issues, because we have Minification and GZIP. Minifying is the process of eliminating any unnecessary characters in a file, things like white space, comments, extra semicolons and line breaks, and it generally provides about 20% reduction in file size. My favorite minification tool is yui compressor [http://developer.yahoo.com/yui/compressor/]- you can install it as a command line java app, or use a hosted version on the web, and upload or paste in your file [http://www.refresh-sf.com/yui/]- there are a couple sites that have built web wrappers for the component. A few other popular ones include JSMin and Packer, and Dojo has a compressor. Just be sure to keep a copy of your original version for development! In addition to minification, some tools provide obfuscation. Obfuscation shortens variable names into tiny 2-3 character combinations, making code indecipherable to human eyes and shortening the file. This is a protection of sorts to help your code be less human readable, but it’s main purpose is to reduce file size even further. Gzip is a type of compression delivered by the web server and understood by the browser. It’s set in the HTTP header, and once configured on the server, it just takes care of itself. Gzipping usually provides about 60% improvement in loading speed. There are a couple things to note: You can gZip HTML, Scripts, and CSS but Don't compress files already compressed (images and pdfs) – anything over 1 or 2 k should be beneficial The slower the connection, the greater the benefit Consult your web server documentation to learn how to GZIP your files, or ensure that Gzipping is being done.

Another great boon to fast performing, responsive front end code is the browser cache. By serving a smaller number of the same files over and over, you maximize the amount of information in your users’ browser cache, and minimize what has to be loaded fresh with every request. But in order to take advantage of caching, you need to externalize your scripts. The only code that should be embedded in the page is the code to load and call external scripts. This also promotes better code reuse and consistency, because you won’t be tempted to copy and paste repetitive code “just on this one page”. Now that you’re using 100% external scripts, what else can you do? Set expires headers on those scripts. An Expires HTTP header tells the browser to use the cached version of that script until the date specified in the header. By setting this date to 1 year or so, you can ensure that the script will be loaded from cache wherever possible. Setting an expires header is quite easy, and if you don’t have access to do it from your server, you can do it with the <cfheader> tag. Now there are a lot of common libraries out there that you use on your site, and I use on my site…if someone has already visited a site with jQuery and now has it cached in their browser, do they need to reload it when they come to my site? Well if I’m serving it from my own URL, they do – because the browser won’t know it’s the same script. But if you use a centrally hosted script, the chances of being able to use that cache are much more likely. Google hosts popular AJAX libraries on their site, so use the Google hosted versions. Not only do you gain the caching benefit, but your script will be hosted on an optimized CDN that is highly available. What could be easier? One of the lesser known and more confusing web server performance features are entity tags, or e-tags. E-tags provide additional information about caching for components (images, scripts, styles and documents) to the server. They help determine if the component being evaluated is the same one that is cached. Often in multi-server environments, they are not configured to validate components across servers. So if I have cached an image on server a, but then my request moves to server b, it won’t recognize that I have cached that image and will reload it. By configuring e-tags optimally for your setup, or disabling them altogether, you can ensure that e-tags won’t be slowing down your site. There are specific instructions for configuring them on the Apache and MS/IIS websites, so check out the article that applies to the web server you use.

Here’s the screen to set an expires header in IIS

Here’s the tag to set an expires header in Apache

If you don’t have direct access to your web server configuration, for example in a shared hosting environment, you can use the CFHEADER tag like this – the header name is expires, and the value is a date 1 year from now. Use the getHTTPTimeString() function to ensure your date is formatted according to the http standard.

Everything we’ve looked at until now has to do with loading, processing and serving files. But I felt I would be remiss if I didn’t provide this quick tip on how to write better JS from the start. So my last recommendation for JS is to use JSLint – a tool that inspects your javaScript and makes recommendations for how to improve and optimize your code. Though it is not directly correlated to performance, it will help you write better code which can in turn improve performance and make the management of your code less problematic.

You don’t see many coding standards or best practices recommended for CSS in the development community. If you follow the design community, you might see some occasional tips, but from looking at most of the CSS I see developers write, they aren’t reading them! You’ve probably figured out by now that CSS files can get large and unwieldy without a plan. Have you ever seen a CSS file littered with !important statements? It’s a common symptom of a poorly planned style sheet. Are there styles that you just can’t get to work and can’t figure out why not? Are there duplicate style declarations all over the place because someone just wrote a new style instead of figuring out which existing one to use? These are very common CSS problems to have, you are not alone. I’m going to attempt to share some things that have worked for me, and some techniques that people much smarter than me have recommended.

For the same reasons we use external JavaScript, we should also use external style sheets. In order to recognize the benefit of caching, you must externalize your CSS files. Caching only works if the exact file you’re referencing has been loaded before, and if you’re embedding CSS throughout your files, not only are you probably writing a lot more CSS than you need to, but you’re wasting the opportunity to cache. Embedded styles are generally a bad practice anyway, because they make it harder to debug problems and more likely that some type of conflict of style will occur in your style declarations. You won’t know where to go to hunt for styles. I always have my core style sheet open while I’m working. Then I’m less tempted to sneak in an embedded style. That said, there are a couple places where an embedded style sheet may be justifiable: on commonly loaded pages that have a lot of unique styles that won’t be used anywhere else – such as your home page – and your site has many entry points outside the home page. on pages with frequently updated styles and caching actually becomes a problem Although Google won’t host your site’s style sheet like it hosts common JS libraries, if you use YUI, you can link directly to their common style sheets like reset, fonts and grids. And when you link to external style sheets, you should put that link in the <head> tag. This ensures that the styles load at the same time as the rest of the page. Just remember that the best place to load CSS is the opposite of JS – CSS at the top, JS at the bottom. The @import directive doesn’t execute until the CSS is parsed, which means it will be slower to load. This causes a phenomenon we know as the “FOUC” or “Flash of unstyled content”. The @import directive gained popularity in the early web standards days because it was a seamless workaround to hide advanced CSS from older browsers. However, unless you need to support Netscape 4, it’s doesn’t offer any benefit today. So the accepted method is to use the <link> tag. In most browsers, the <link> tag will also download at the same time as other elements, while the @import method will not.

Here’s what can happen if you use @import instead of link. It causes a phenomenon known as the Flash of Unstyled Content, or FOUC. This simulation shows how a page will flash for a moment without style sheets, then suddenly load styles and look normal again. It may seem minor, but it looks unprofessional and it’s easy to prevent by using the <link> tag. Here’s why that happens. The <link> tag is processed as part of the HTML page markup. The @import directive is processed as part of the style sheet evaluation. Well, the HTML is going to be loaded and processed first, then the style sheet will be parsed. So we want to load the style sheets as early as possible, with the HTML. Not only that, but linked style sheets can parallel-load with other elements, but imported style sheets can’t. So externalize your CSS, and link it in the head.

Here are some quick tips for writing smaller CSS files. Use shorthand Use small hex values Don’t use units for 0 This can help make your CSS less verbose. But you ask – why does it matter if I can just minify my CSS file? Just like JavaScript, CSS can be minified. But because of the cascading nature, it can’t be minified as much as JavaScript. The minifier can’t always tell if rewriting your CSS will change the appearance of your site once it’s interpreted. So it’s best to write your CSS as concisely as possible, and use minification to reduce white space and remove comments. The YUI compressor supports CSS.

Just like with javaScript, you only want to load CSS once, and you need to make sure that all the styles you need are included in the page. You can use javascript to load CSS like the example we looked at earlier, except instead of dynamically adding script elements, we add style elements. However, that means you have to write JS every time you want to include CSS, and that sounds like a lot of unnecessary runaround to me. So my preferred method with CSS is to manage it on the server side. Here’s one strategy – a simple custom tag I wrote to offer a convenient and consistent way to load CSS files. If all your CSS links run through a central file, it’s easy to make global changes, and provide your entire team with an easy way to use best practices. The way it works is that you either wrap it around some CSS for embedded styles, or point it to a style sheet, and it takes care of the include code for you. This is a basic solution, but if you need more features and performance, or you have a large app with lots of style sheets, you can also use one of the bundling components that we looked at for JS – Scriptalizer or Combine.cfc.

CSS needs comments – as with any language, use many as you need but no more. Just because the syntax is simple doesn't mean interpreting styles is. Explain hacks, workarounds and redundancies. Denote section and page specific areas. Denote areas of style sheet such as layout, header, nav, sidebar footer, typography. Add comment hooks for searches that make sense. Some like to indent related and cascaded styles together - I personally find this hard to read but it may work for you

within the file, declare your rules from the least specific to most specific global helper page structure page/section specific This helps you to manage the Cascade effectively, because the cascade looks at order and specificity. If you have highly specific rules at the top of your file, when you go to write a rule that overrides it, you have to mess up your order…if you even realize that you have that problem! This method takes the confusion out of the cascade.

When you write styles, rather than trying to declare every property of a style, make the definition as minimal as possible. Only write declarations that are essential for that particular rule, and utilize the cascade for the rest. You should also put your rules as high up the cascade as possible – that is, apply them to the body element rather than the p,ul, and table elements – this way you’ll be declaring the same rules a lot less often. This will give you more flexibility in combining and cascading styles, without having to overwrite others.

One of the most essential tools for CSS is a good reset style sheet. Stop worrying about inconsistencies in how browsers treat font sizes, padding, margins, bullets and default styles. A reset removes or standardizes the styles on all elements that differ across browsers. Firefox may add a default padding of 1em to list elements, and IE adds 1.2ems – your reset style sheet sets them both to 1em. It will help your sites look more consistent across browsers, and will prevent you from having to write one-off rules to standardize. There are two popular, good ones out there that most others are based off of – Eric Meyer (Patron Saint of CSS) and YUI. They both take slightly different approaches. Eric Meyer’s removes everything to its most basic appearance; YUI just standardizes the key elements and leaves in a little more “style”. Try them both to see what you like better.

This is an onion-skin overlay example of the same site, markup and css with no reset styles. This shows IE overlaid on Firefox, and you’ll notice that there are differences in the spacing that create a lot of differences between the rendering in the two browsers. The more content you have, the more dramatic the difference.

This is the same page, with both browsers using a Reset style sheet. The style sheet has standardized the display across the browsers, and also eliminated some default formatting like bullets and heading font size. Now we have a better baseline to start from.

The reset options do vary – this shows the YUI reset overlaid on the Eric Meyer reset. They each handle the standardization and stripping of formatting slightly differently. Neither is better, it’s just a matter of what you prefer.

You should be using a modular layout system. Don’t write custom positioning for every element on the page, you’ll end up with a lot of repetition and it makes it really difficult to keep your layout consistent. Instead, design reusable classes that assign common positioning rules, and then add them wherever you need them. Not sure where to start? Use one of the popular CSS frameworks. They take care of standardizing positioning across browsers, and give you a series of layout modules to make positioning painless. They help minimize duplication and they also help abstract your CSS layout from the skin of your application. If you’re more comfortable with the concept, perhaps you can create your own grid system for your specific project, or your own framework that you can use across all of your applications. This article by JSM helps you get started.

You can create modular layouts…and you can create modular styles. By taking advantage of the Cascade, you can create classes that only define their most unique features. Then, you can apply multiple classes to elements to build the styles upon eachother. Here’s an example of a set of styles for alerts and notifications. You know those little messages that appear at the top of the screen to let your users know if something worked…or some other bit of info they need to know? Here’s how to create a simple and easily memorized set of styles that provides you with consistent message formats. First we have our base notification class – it defines the default colors, fonts, positioning and sizing. It’s our green message, and we’ll use it for most confirmations. Then we’ll add a class for warnings, it looks the same but it’s yellow instead. The only thing we need to define is a new border and background color. We’ll do the same for errors.

Here’s what the HTML looks like. We mark up each notification the same, they all get the notification class. Then they get another class based on the type of notification.

The rendered version looks like this. This is a useful technique in many areas – for buttons, form elements, just about anywhere. Don’t try to override and avoid the Cascade, embrace it and use it to your advantage.

Working with multiple CSS files can be good and bad. if you use multiple files: split them up according to area of concern – keeping in mind that we’ll bundle them together when we serve them up – this is only for development framework (grids, typography, reset)  that can be used across many applications, then app-specific core (application specific) - the skin and styling sometimes useful to have a separate sheet for certain parts, such as view vs edit, or admin vs public hacks and browser-specific (conditional comments for IE, cf cgi.http_user_agent for safari or others) file organization schemes that don't work: separating colors and skins from other parts – not talking about client customization, just your own stuff separating typography from layout (just creates more work and headache) The main exception to breaking out typography and colors are if you’re creating a user-skinnable app or in some situation where you want only certain styles to be swappable. But in this case, you should use a style sheet that overrides the defaults, so it’s in addition to – not instead of – the basic structure. You’ll occasionally see some frameworks split up css into separate files for each widget, and then import them all into one style sheet that gets linked in the html. This is nice for development, but adds a lot of loading overhead. If you want to take a similar approach, just bundle the files together at build-time or runtime. Bottom line – splitting files should be done according to how it works best in your development, then those files should be combined for delivery to the user, either as a part of your build process or dynamically on the server.

Back to basics. Images are one of the first optimization techniques we use when we learn web design, and they tend to get more attention because of their file size. However, I felt I would be remiss if I didn’t cover some of the more important and modern techniques to optimize images, because it’s such an important foundation.

file organization and planning keep images in a central place, and create a virtual directory if you need to - or use a CDN – don’t let images get scattered throughout the site separate structure and skin (corners, background textures); ui elements (buttons and tabs); icons and sprites; from content – illustrations, photos and other images that support content Have one logo folder (or am I the only one who's seen sites with 20 copies of their logo all over the place?!) – have a specific and obvious place where logos go and where your team knows they can be found. If you have many versions of the same image – perhaps your logo, or a diagram or icon you use a lot – come up with a naming convention that makes it clear which version it is. Perhaps you have a transparent or knockout version, or a small or large version. Name the file with its dimensions and other unique attributes. This also makes it easy if you change your logo – you have a complete list of what files need to be updated to universally replace the logo across your site. Look at the specific needs of your application, you may also need a central place for uploaded files, for user-uploaded content, documents, etc. and these should not be mixed in with your site’s media. If you have partner or client content, give them a dedicated directory The philosopy is to separate images by concern, without fragmenting them into so many pieces that you can’t find what you need.

optimization PNG files tend to provide the best optimization results: smallest file with best appearance, you don't have to use alpha transparency, you can use index transparency or none at all JPEGS for photos and multiple color or continuous tone images, and smooth gradients GIFS for simple illustrations, logos and blocks of solid color (especially horizontal stripes, because that's how the files are written) BUT there are few reasons to use a GIF when you can use a PNG (for the very smallest dimensions, a GIF is often smaller than a PNG).

use the 4-up option in your graphics editor Fireworks does a better job at compression that Photoshop, most of the time SmushIt removes non visual data to further reduce image sizes: http://developer.yahoo.com/yslow/smushit/strip color profiles

There aren’t too many loading strategies with images, except to say that you can also set expires headers on frequently used images like logos and navigation….otherwise the main strategy is to….

One popular technique for doing this is with CSS sprites Several images of the same size? Navigation tabs. buttons. icons. Tile them all in one image (single http request, cached once) and use background positioning with CSS REALLY easy for theming sites, conveniently portable do you really need an image? rounded corners, alpha transparency/RGBa in modern browsers eliminate many extra image needs target the "polish" for modern browsers, all websites do not have to look the same! they just need to work! if the effect doesn't make a functional difference, target newer browsers (icedorhot.com example) Trim images to minimal dimensions Use a small tiled background behind transparent foreground images (keep tiles to at least 10-20 pixels, too much tiling can slow down the browser)

So let’s talk about sprites. These are my two images I’m starting with. That’s right – two. I’ve tiled several icons in a single image file for each state – on and off. I’ll use these as background images for my toolbar style

You can see here I’ve styled some link elements to each use these background images. The default, link and visited state shows the “off” image. The hover and active states show my “on” image. I’m using the same base styles for all my icons.

I’ve also created a separate class for each icon. Then I’ve assigned background positioning for that class that aligns the visible area of the link with the location of the correct icon in the image. When I view the finished HTML, it looks like 6 different images but I’ve accomplished it by only loading 2 images. The other bonus is that if I need to add another icon in the same style, I only need to add another tile to my image and everything stays neatly together. If this all went over your head just now, just do some googling for “CSS Sprites” to find many tutorials on the web that cover this technique.

Now we’ll just recap some general advice and tools that can help you make the right decisions.

find something that fits your philosophy and works for you don't worry about the standardistas, if it allows you to be productive, it's good - use web standards to the extent that they future-proof your site and help you write good code, but don't bang your head against a wall. You don’t work for standards, standards work for you! Work with what you know and what you’re comfortable with. There’s nothing wrong with learning something new on a project, but don’t bite off too much at once, try to find something with some familiar elements and then build on that. That’s one of the reasons I believe jQuery is so successful – it takes all your knowledge of CSS and puts it to use with Dom manipulation. analyze your stats to determine what you need to support. Forget about industry-wide statistics and benchmarks, it's your specific audience that matters

It used to be that Firefox was the only browser that cared about developers, but now, thankfully, all the major browsers have developer tools. These are the popular ones, download them!

no notes exist for this slide

no notes exist for this slide

RIAUnleashed – early bird is only $30 and they are almost out of spots, then it goes up to 50 and then 60 is the standard rate. Fantastic deal for a 3-track conference.

no notes exist for this slide