Amazon’s S3 file storage service started life as just that — a simple way to store static files and pay for only the data you used. When you don’t need an always-on server, S3 fits the bill.

But if you can store static files, why not whole static websites? In 2011 Amazon began allowing you to point your own domain to an S3 “bucket”, a folder in Amazon parlance. Custom domain support made it simple to host entire static sites; the catch was that you needed to use a subdomain — for example, www.

Now the www restriction has been lifted and you can point any root domain at S3 and serve your files directly. The only catch is that Amazon has created its own non-standard DNS workaround, which means you must use Amazon’s Route 53 service to host the DNS data for your domain.

Unfortunately, while the new root domain support is great news for anyone using a static blog generator like Jekyll, Amazon’s documentation leaves much to be desired. To help you get started with S3 hosting, here’s a quick guide to setting up S3 to serve files from a root domain (rather than making the root domain redirect to www.mydomain.com, as the Amazon blog post instructions do).

First, register a domain name and point your DNS records to Amazon’s Route 53 service (the Route 53 docs have detailed instructions on how to do this). The next step is to create an S3 bucket for your domain. In other words, a bucket named mydomain.com.

Now click the Properties button, select the Website tab and make sure that the option is enabled and the Index Document is set to index.html. You’ll also need to click the Permissions tab and set a bucket policy (you can use this basic example from Amazon).

Now upload your site to that bucket and head back to Route 53. Here comes the magic. To make this work you need to create an A “Alias” DNS record. Make sure you name it the same as your domain name. Sticking with the earlier example, that would be mydomain.com. Now click the Alias Target field and select the S3 endpoint you created earlier when you set up the bucket.

And that’s it. Behind the scenes that Route 53 “Alias” record looks like a normal DNS A record. That means things like email will continue to work for your domain and at the same time Route 53 directs requests to your S3 bucket. If you want to make www redirect to the root domain you can either set that up through Route 53 (see Amazon’s instructions) or handle it through another service.

A group of DNS providers and content delivery network (CDN) companies have devised a new extension to the DNS protocol that that aims to more effectively direct users to the closest CDN endpoint. Google, OpenDNS, BitGravity, EdgeCast, and CDNetworks are among the companies participating in the initiative, which they are calling the Global Internet Speedup.

The new DNS protocol extension, which is documented in an IETF draft, specifies a means for including part of the user’s IP address in DNS requests so that the nameserver can more accurately pinpoint the destination that is topologically closest to the user. Ensuring that traffic is directed to CDN endpoints that are close to the user could potentially reduce latency and congestion for high-impact network services like video streaming.

The new protocol extension has already been implemented by OpenDNS and Google’s Public DNS. It works with the CDN services that have signed on to participate in the effort. Google and OpenDNS hope to make the protocol extension an official IETF standard. Other potential adopters—such as Internet ISPs—are free to implement it from the draft specification.

It’s not really clear in practice how much impact this will have on network performance. It’s worth noting that GeoIP lookup technology is already used by some authoritative DNS servers for location-aware routing. The new protocol extension will reportedly address some of the limitations of previous approaches.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

It was in the dark ages of the Reagan era when I logged my first encounter with the File Transfer Protocol. I was involved in some nefarious video game-trading ring of the innocently naive variety, and a friend of mine had that hot new copy of Vladivostok Putting Challenge that I wanted oh so badly. The only problem was that he lived all the way on the other side of Orange County. Being too young to drive, neither of us had access to a car, and snail mail was just too darned slow. I wanted to lay down sloping fifteen-footers and rub it in the face of the Reds today, not in a week. “No problem,” my friend assured me. “Just log in to my server and grab it with FTP.”

“FTP? What is that?” I asked. My friend let out an Oscar-worthy sigh and gave me the quick run down of the Internet protocol that would forever transform my life.

Last I heard, my friend is collecting Galaxie 500s in Michigan, so calling him up with your FTP questions isn’t really an option anymore. Lucky for you, I’m here to give you a holier-than-thou sigh of my own and send you down the dharma path. For those of you who are entirely new to this whole game, we’ll start with a basic primer on the most comely of acronyms.

What is FTP?

FTP is short for File Transfer Protocol. A protocol is a set of rules that networked computers use to talk to one another. And FTP is the language that computers on a TCP/IP network (such as the internet) use to transfer files to and from each other.

You’ve probably encountered FTP out there on the net already. Ever downloaded a fresh nightly build of Firefox or grabbed MP3s from some kid’s personal server in Sweden? Then you have probably used FTP without even knowing it. Today’s web browsers allow you to download files via FTP from within the browser window. It’s very convenient, and it’s great for those times you need to download a file or two, but the browser-download method does not offer much in the realm of flexibility. You can’t upload, force a particular transfer mode, or ask the server any questions. And don’t even get me started on the security issue. But if you are doing any sort of web development, you need all this functionality.

The best way to pursue file transfers is with a bona fide FTP client. You use an FTP client to log into an FTP server, navigate the server’s folder structure, and exchange files. That’s pretty much all FTP clients do — unlike Web browsers, FTP clients are tailor-made for such duties. The latest full-featured web editors like Dreamweaver and RapidWeaver have FTP fuctions built-in. As far as stand-alone FTP clients go, there are literally hundreds out there. Some are free, some are more expensive than a night on the town.

We’ll take an in-depth look at the joy of using an FTP client in the pages that follow, but first, let’s look at exactly how an FTP session works.

Logging In

Connecting to an FTP server is very similar to connecting to just about any other server on the Web. When you log in to your Hotmail account or a secure shopping cart system (such as the one at Amazon.com), you have to provide a server address, a user name, and a password before you can exchange information with the server.

Let’s take a look at an example login set for an FTP server.

site:ftp.fakesite.org

login:mcalore

pass:h4x0r4lyfe

port:21

The first line in the example above, the site address, is simply the address of the FTP server that I’m connecting to. The “ftp” in the prefix of the URL identifies it as an FTP server. Pretty straightforward so far. The second and third lines are my user name and password, respectively. In this particular case, I have already had the server administrator set up a login account for me on the server. Even if I didn’t have a login account, I still might be able to gain access to the server by logging in anonymously. We’ll go into that more a little later.

The last line of the example login is the port number that I’m connecting to on the server. A port is best envisioned as a little door on the server. Most servers on the web have a multitude of such doors, each with its own purpose. Each port number is dedicated to a corresponding application on the server, and the traffic intended for an application (such as an FTP server or web server) passes through the application’s dedicated door. Each port handles a specific type of transaction between the server and client. For example, the FTP protocol is handled by ports 20 and 21 by default. HTTP (the protocol that’s used to serve web pages to a browser) requests are handled by port 80.

Often, the port number will be attached to the end of the server’s Web address, separated by a colon, like this:

ftp.fakesite.org:21

It isn’t important that you know every single TCP/IP port for each internet application out there, but you have to be able to recognize a port number when you see one. This becomes especially critical when you are connecting to servers that route FTP connections to other, more obscure ports.

Note: This quandry brings up the sometimes-confusing issue of passive FTP versus active FTP, two different modes of data transfer between a client and a server. Which one is being used depends on how the client and server firewalls are set up. Since this issue is beyond the scope of this article, I will point you to a detailed discussion of active versus passive FTP over at Slacksite.com. So don’t be alarmed if you notice that your FTP connection is jumping to port 1013 all of sudden — that’s just your data being routed via passive FTP.

Anonymous FTP

Many public servers on the Internet allow users to log in and download files via FTP by connecting anonymously. This is a very common practice in the world of open-source and freely distributed software.

When you connect anonymously to an FTP server, you’re not really anonymous in the truest sense. Most of the time, you are required to enter “anonymous” as your user name and your email address as your password. This is a gesture of courtesy toward the server administrators so that they can get some idea of who’s logging in and downloading their files. Even if you are connecting anonymously and you aren’t required to give any personal information during the connection process, any sysadmin worth her salt is logging your session. This means that if you do anything nasty or illegal, the server administrator has your number (quite literally, your host domain and IP address). You can be put on probation, blocked, or prosecuted. So, here’s a tip to remember:anonymous is never really anonymous as far as anonymous FTP is concerned.

Check Out the Logs on That Server!

Sometimes, the easiest way to wrap your head around a new concept is to dig in and examine the bare bones. In this case, we can learn a lot by simply reading the log from an FTP session.

All FTP servers and clients will log FTP sessions. A log is basically a text record of all of the activity that goes on during a session. Your client should save your FTP logs locally, so you can open them up in a text editor and have a peek at all the nitty-gritty FTP commands and transfer hoo-hah.

Let’s take a look at a sample FTP log. I’m logging in to my server with the user name “mcalore”. This log simply shows my client connecting to the server, logging in, and asking for the list of files inside the default directory on the server. That’s all that’s going on here!

Status:Connecting to ftp.fakesite.org ...

Status:Connected with ftp.fakesite.org.

Response:220 ProFTPD 1.2.4 Server (ProFTPD) [109.41.xx.xxx]

Command:USER mcalore

Response:331 Password required for mcalore.

Command:PASS **********

Response:230 User mcalore logged in.

Status:Connected

Status:Retrieving directory listing...

Command:PWD

Response:257 "/users/mcalore" is current directory.

Command:LIST

Response:150 Opening ASCII mode data connection for file list.

Response:226 Transfer complete.

Status:Directory listing successful

Starting at the beginning of the log, you can see that my FTP client wants to connect to the server at fakesite.org. My client knows that the server is active and waiting, so it sends the first command, which is “USER mcalore”. The server says, “OK, but I need a password”. My FTP client sends the next command, which is “PASS ********”. This is all pretty simple — my client sends a Command, and the server sends back a Response. The communication goes on like this during the entire session. It looks like my client and my server are becoming fast friends, eh?

There are several commands that a client can send to an FTP server to find out information, switch directories, or request files. In the sample log above, the PWD command — which should be familiar to Unix users — is used to find out the current directory you’re working in on the server. You can view a full list of FTP commands on Columbia University’s Academic Information Systems site. Even though your client will take care of all the server commands for you, a good Monkey should be able to look at the logs and understand what’s going on.

At this point, you’re just about ready to grab your own FTP client and start experimenting. However, by showing you the sample FTP log, I opened a can of worms that we haven’t discussed yet:transfer modes.

ASCII versus Binary

Let’s go back to the last four lines of the sample log that we examined in the previous section.

Command:LIST

Response:150 Opening ASCII mode data connection for file list.

Response:226 Transfer complete.

Status:Directory listing successful

See that server response that reads “Opening ASCII mode data connection for file list”? That’s very important. File transfers over FTP take two different forms, ASCII and binary.

ASCII, otherwise known as American Standard Code for Information Interchange, is a set of 128 symbols that any computer in the world can display. You may be familiar with ASCII text, ASCII art, and ASCII files. Any file that is made up of text or text-based components, such as an HTML file, text file, or PostScript file, is an ASCII file. Binary files, on the other hand, are structured differently, and therefore require a different style of transfer. Images, applications, and algorithmically generated packages such as .zip and .tar files are all binary file types.

Just about every FTP client out there will automatically detect which transfer mode is required and treat your uploads and downloads accordingly. Most clients run in binary transfer mode by default, only using ASCII mode when it’s absolutely needed. This is because both ASCII and binary files can be sent in binary mode with no problems, but sending a binary file in ASCII mode will corrupt the binary file’s structure. ASCII mode makes for faster transfers, but if you accidentally upload a Microsoft Word file or JPG image in ASCII mode, your file will hit the server dead on arrival. If there’s any question, transfer in binary mode.

Of course, we wouldn’t have such a handy rule without one exception:CGI scripts. You must use ASCII mode when sending CGI scripts. They just won’t work otherwise! Luckily, any files ending in .pl or .cgi are usually recognized as CGI scripts by your FTP client.

Quickly, here are some guidelines:

These file types are safe for ASCII transfer

• Text files
• HTML files
• CGI scripts

These file types must be transferred in binary mode

• Images
• Applications
• .zip, .sit or .tar packages
• Proprietary file formats such as .doc, .xls, .fla, .swf
• Anything that’s not made entirely of text characters!

Now that you possess basic knowledge of the File Transfer Protocol and its many gifts, how about digging in and actually trying out some clients? Thought I’d never ask, huh?

Giants Among Clients

Most FTP clients in the less-than-US$40 range have all of the basic features that you’ll need to become a power FTP user. Even so, it may take a short period of trial and error before you find an FTP client that you totally jive with. When choosing an FTP client, you should aim for an application which:

• Has an easy to use interface that clearly displays both the local (your computer) and remote (the FTP server) locations
• Has a tool to manage multiple login accounts on multiple servers
• Logs your FTP sessions
• Provides a way to select between active and passive FTP when connecting
• Auto-detects or warns you when ASCII mode is required
• Allows you to set folder and file permissions on the server (essential when installing a server-side application such as Movable Type)
• Allows anonymous FTP

Windows Clients

An easy-to-use and entirely free application called FileZilla is a great place to start. It was created by an open source community headed by Tim Kosse, and even though the user interface is a little intimidating, FileZilla has all of the features you’ll need to get cracking.

CuteFTP, made by GlobalSCAPE, Inc., costs $40 per user license.

Another crowd favorite in the world of Windows FTP clients is WS_FTP Pro by Ipswitch. Also $40 per user license, WS_FTP offers a clean interface and connection management tools.

Mac OS X Clients

If you’re using a Macintosh, most people point you toward Fetch Softworks’ ever-popular Fetch client. It’s simple, it’s easy, and it costs $25 per user license.

A personal favorite client for the Mac is Panic’s Transmit. It has the cleanest user experience I’ve ever encountered in an FTP client. Transmit costs $24.95 per user license.

An excellent free FTP client for Mac OS X is Fugu. The user interface is a tad spare, but Fugu supports ultra-secure OpenSSH SFTP encryption.

The free FileZilla client is also available for the Mac.

Linux Clients

Linux users who want to try FileZilla can grab it through their system’s package manager or compile it themselves using source code.

FTPing with the Browser

As we have seen, the best way to run FTP is through a real FTP client. However sometimes it’s just plain easier to grab files off an FTP server using a web browser. As you’ll notice, when a browser is pointed to an FTP server instead of a web server, the http:// in the address field changes to ftp:// since you’re working with a different protocol, after all. Your browser’s address field will look something like this:

ftp://username:password@ftp.fakesite.org/

When using a browser to connect to an FTP server, you may be asked to log in just like you would if you were connecting with an FTP client. Once inside the server, your user name and the password you give will be reflected in the server path, as shown above. If you logged in anonymously, your username would show up as the word “anonymous” and your email address would serve as the password. Most browsers are set to log into FTP servers anonymously by default.

A web browser can navigate an FTP server much like any other file system. You can click on folder’s name to browse that particular folder and click on files to download them. But even though browser FTPing is nice an convenient, as a general rule use an FTP client whenever possible. Browsers offer minimal functionality and, not surprisingly, minimal security in FTP mode.

Tips & Advice

Be courteous. The people that run public FTP servers are just that:people. They don’t like being hassled by impolite users, or even innocents who haven’t learned how to properly use their FTP clients. Many FTP admins place readme files in the root directory of their server (“root directory” being the main directory you’re dropped into when you log in). The readmes aren’t there to take up space or look pretty, they are there for you to read. Also, administrators sometimes put their user guidelines in the flood of server information that you receive when you first log in. Open up your FTP logs and browse them for rules, requests concerning your behavior, and the sysadmin’s contact info in case anything goes wrong.

Be patient. Some servers are extremely popular, so it may take you a few tries to gain access. If your client allows you to re-try logging in after a server timeout, all the better. Set your re-tries to one minute or longer, and don’t hammer the FTP server with log in requests. That’s an excellent way to have your IP address banned.

Find the Pub Once you’ve connected to a strange server for the first time, you may have trouble accessing certain folders. That’s because permissions have been set that only allow certain users to get into folders where sensitive files are stored. Unless the readme files point you elsewhere, your best bet is to aim for /PUB, the standard public directory on Unix systems. If you are downloading anything for public use off of a public FTP server, that’s where you’ll find it.

Public Sites You Can Visit

Speaking of public FTP servers, I have a few favorites that I’d like to pass along. There’s some wonderful software available on the Free Software Foundation servers. You can download academic Linux builds from the UK Mirror Service, or find out when your Uncle Jeb emigrated to West Virginia by scrounging up genealogical data. If you have a spare SGI machine lying around that needs some software, the University of California at Santa Cruz has its own directory of FTP sites carrying public domain software. If your girlfriend is an astronomy buff like mine, go grab some space research materials and impress her with your Carl Sagan impersonation.

The world of FTP has billions and billions of practical applications, and now you’re ready to start exploring. Why the blank stares? C’mon, this is the kind of stuff I do for fun. Seriously!

A picture’s worth a thousand words. An old saying, but true enough on the web where you can transfer chapters of text in the time it takes to download just one big image. Ever notice how pictures are always the last thing to show up when you’re surfing? That’s because the biggest hunk of download time comes from the image files.

Over the next four days, we’ll be looking at all the different ways to get pages down to their leanest and meanest. Today we start with the most egregious and most obvious culprit: images.

By the way, a lot has changed since the first edition of this tutorial – there’s more to optimizing image performance today than just knowing your GIFs from your JPEGs. (Though we’ll review that, since this may be your first time around.) There are now other file formats (like PNG) worth considering, and improved weighted-optimization techniques to throw into the mix.

And, hey, quite a bit hasn’t changed. For one, web users haven’t gotten any more patient. It doesn’t matter how ice-cool your images may look – if they can’t be downloaded quickly over a 56K modem, very few people without broadband will stick around to see them.

Fortunately, there’s still a host of tricks and optimizations that web designers can implement to speed image downloads. Let’s start with the easiest thing in the world.

Don’t Need It? Don’t Use It.

Nothing tricky or techie about this, but, friend, it works wonders. Before you do anything else, remove every superfluous image from your page’s design. Now “superfluous” doesn’t mean your company logo or a useful map to your office. We’re talking about that clever, animated envelope next to your Send Mail link. Or, if your site has a splash page with a big logo and a [CLICK HERE TO ENTER!] link, ditch it and send your audience directly your main page. Trust us:a fast-loading, functional website gives your business a better image than some splashy intro that offers the user no real content, and nothing to do but wait for the next page to load.

Remember, shaving a paltry 10KB image off your site may not sound like that impressive an improvement, but if you’re working with a 40KB page, that 10 KB represents a healthy 25 percent reduction in download time not a bad trade for the loss of hi-res picture of your new Hello Kitty toaster.

If you’re really hell bent about creating split-second page loads or you have a page that desperately needs trimming, consider axing graphical submit buttons and replacing them with text submits. They are recommended by user interface experts and users alike.

Click to Submit Data

Also, you can replace animated GIFs with static images, which take a fraction of the time to download.

Finally, a lot of fancy “header” and navigation graphics can be replaced with larger text, appropriately styled with a tag or CSS. These days, this option works better than ever, because Windows XP and Mac OS X browsers natively support text anti-aliasing. This process smooths the jagged edges around fonts, giving screen type a more natural, refined look, especially at bigger font sizes.

Image Formats

Unless you’re bent on evoking that retro-fly ARCHIE or GOPHER feel, you’re probably going to be using some images on your pages. Just follow a few simple guidelines as you generate your images, and your pages will download in record time.

To begin with, decide whether a given image ought to be a GIF, JPEG, or PNG. This may seem elementary, but it’s a mistake that’s still slowing down a good percentage of web pages out there.

GIF is the oldest and most compatible file format for pictures on the web perfectly suited for smaller graphics that need to look crisp and clean, but don’t need more than 256 colors. GIFs can also be saved with one “transparent color,” allowing them to have irregularly shaped borders. Simple company logos, icons, and navigation buttons are good examples of graphics that should be saved in GIF format.

Now, PNG is a lot like GIF – in fact, it was developed to be a patent-free alternative to GIF, created with the same sort of uses in mind. PNG builds on GIF’s basic features, with improvements like more colors, fancy multilevel transparency (ideal for delicate drop-shadow effects), even gamma-correction, which ensures that colors look the same on Mac, Windows, and Linux computers. Best of all, not only are PNGs just as good as GIFs in almost every way, but PNGs use better file compression so they’re smaller files which load more quickly.

In short, PNG is an excellent substitute for GIF, built to handle the same types of graphics (logos, icons, irregularly-shaped items, et cetera) better and faster. There’s just one BIG drawback:a tiny, tiny percentage of browsers won’t display PNGs at all! And, because of this, hardly anybody uses PNGs yet.

So should you risk stepping up to PNG just to make your pages faster? Well, probably, “Yeah!” We’ll come back to that decision, but first, let’s talk compression basics, and see how underdog PNG and old-timer GIF stack up against JPEG, the hulking file format that crushes photo-realistic data into teensy-weensy files.

JPG and PNG Basics

PNGs and GIFs use a lossless compression format. Unlike a JPEG, the details of your graphic won’t get blurry. If you’re scanning something like a finely detailed map, or creating anything with small text, you should choose the GIF or PNG format. Just keep in mind that using GIFs (and even PNGs) for large pictures leads to huge file sizes and long download times.

For example, take a look at these three images:

12 KB GIF

13 KB PNG

12 KB JPG

The first is a GIF, the second is a PNG, and the third is a JPEG. All three files are comparable size-wise, right around 12K. If this were a map to your office, which two formats would you consider? Right. So why use JPEGs at all, then?

Well, take a look at these three images:

49 KB GIF

44 KB PNG

12 KB JPG

Again, the first is a GIF. Even though it’s maxing out at 256 colors (it’s 8-bit), it looks OK, but you’ll notice that the file size is huge. The second is a picture-perfect PNG, displaying thousands of colors at once, so the shading between similar colors is really nice and smooth. But again with the big file size.

Now the third file, a JPEG, is also using thousands of colors, and lookin’ pretty good, too. And check out the small, superslim file size! See, JPEG has the advantage of “lossy” compression in which some information is actually discarded when creating the file. So while you might see some photographic details being blurred, and other tell-tale digital artifacts that are the bi-product of lossy compression, the overall image looks OK, and the file size is a fraction of what can be achieved with more accurate lossless methods.

JPEGs are the perfect file format for color photographs on the web, whether they’re scanned or straight from the digital camera. Just keep in mind that JPEGs can’t do animation or transparency, and they don’t handle detailed drawings as well as GIFs or PNGs.

Standard Image Compression

Grab a demo of GraphicConverter, Photoshop, or Fireworks and experiment with compression. Try a bunch of different settings and see what you liked best in terms of display quality and file size.

JPEG offers the widest range of compression levels, technically speaking, but it’s pretty intuitive: The more you compress an image, the worse it looks. Image-editing programs generally offer Low, Medium, and High options for image quality. Photoshop and Fireworks let the user twist the compression dial anywhere between levels 1 and 100. (Yes, and Nigel Tufnel would be impressed – but may we suggest a level 101?) Avoid the extremes, obviously, but determining the right level of compression on a given photograph is ultimately up to you.

You can’t variably compress GIFs or PNGs per se, but you are able to reduce their color bit depth, which limits the number of colors used. To calculate the number of colors at a given bit depth, take 2 to the power of the bit depth (i.e., 8-bit color = 256 colors). The fewer the colors, the smaller the kilobyte size of the image. Say you’re building the Coca-Cola website – you can probably reduce your logo to a bit depth of 2 or 3. 2-bit color allows you a bold red and a white, but 3-bits buys you a few extra shades of each to smooth out rough edges. Speaking of extra shades, optimization pros will notice that using anti-aliased text in graphics makes it much harder to lower image bit depths. The anti-aliasing effect requires many extra colors to give text that softer look. If you must use type in your images, keeping it plain helps shrink file sizes and makes the text easier to read.

Above: 2-bit and 8-bit versions of the same image. If you don’t need an extended range of colors, there’s no need to use higher bit depths!

Advanced Compression Techniques

Even the simplest image-editing utilities let you play around with bit-depths and other compression settings. Photoshop offers a superb interface for previewing and managing compression options. Controlling color tables, dithering, and transparency while you fine-tune an image’s size is a breeze with these two titles.

Photoshop has other options for power-users wanting better control over the image compression process. With weighted optimization, you identify important areas in your image using a masking tool, and then vary the compression settings across the image’s different regions. For example, you could apply maximum compression to the background of a candid snapshot, and apply better image quality to the people in front. Your finished product shows people’s faces without any strange-looking digital artifacts, while the unremarkable background contains evidence of higher compression settings.

Weighted optimization works on GIFs, too. For instance, you might mark off key aspects of logo artwork, so critical image areas wouldn’t dither or have colors jump, when you began adjusting the bit depth.

Nifty, eh? Well, to quote every self-respecting TV infomercial, “Wait! That’s not all!” There are other Ginsu-sharp tools in Photoshop’s “Save For Web” dialog. One is a blur effect for JPEGs that reduces the impact of digital artifacts – most handy, but best used with a light touch. Photoshop also lets you specify JPEGs to be formatted as “Baseline Optimized”, which is a slightly smaller format file size-wise. Disregard Photoshop’s warning that Baseline Optimized JPEGs are less compatible – they look OK in all browsers. Well, except of course for Lynx.

<nerd> (Alright, alright. Since you really want to know, baseline optimized images use different quantization divisor tables and Huffman dictionaries than specified in the old-school JPEG/JFIF standard. So while optimized images may throw some image-editors and encoding software for a loop, the JPEG decoder in a web browser doesn’t care, since it parses the DQT and DHK markers to get those tables! Yeah, like, I know, how wacky is that?) </nerd>

Obviously, JPEG compression relies on extremely advanced mathematics. GIFs on the other hand…

A GIF is just a list of colored pixels. GIF’s only attempt at compression is to abbreviate whenever same-color pixels are right next to each other horizontally. And that’s all.

So with a row of 100 white pixels, the GIF format saves space by using an annotation along the lines of “one white, 99 more of same color”. A row of alternating black-and-white pixels, on the other hand, requires a more verbose description (“one black, one white, one black, one white”) and soaks up more space. Basically, it’s a big deal if colors change on the same horizontal line.

Photoshop does have a “Lossiness” feature for decreasing GIF sizes, which takes advantage of GIF’s fondness for like-color clumps. Photoshop will substitute pixels here and there, and try to increase the number of same-color pixels sitting next to each other. It works okay, but not as well as it sounds; the automated results can look pretty bad, especially on the types of pixel-perfect artwork you’d want to use GIF for, anyway.

If you’re hell-bent on optimizing a GIF’s size beyond reducing its colors, consider the compression scheme while designing it, and avoid changing colors along the horizontal axis. E.G., if you were drawing a logo with a “black-white-black-white” checker pattern in parts, consider using a solid grey instead. Don’t forget, GIF compression only takes horizontal rows into account. Ten vertical lines of white pixels occupy as much space as ten vertical lines of ten different colors.

Bad GIF pattern

Good GIF pattern

Wow! I think we finally have compression covered.

Executed by an expert (that’s you now!), this increased control over image optimization should squeeze a few more kilobytes from each of your images, saving users seconds (and hopefully minutes) when paging through your site. That’s charitable, but remember:when a user doesn’t feel their time is being wasted, they’re liable to do just that – waste serious time. When they do it at your site, clicking link after link, that’s a good thing.

Faster Than a Speeding Progressive Download

Alright. So your images are now as small and fast they can get. Let’s quickly cover one way to make them seem faster without focusing on file sizes.

When you save images in an “Interlaced” (GIFs and PNGs) or “Progressive Loading” (JPG) format, the browser displays your pictures as fast as they can. First, they draw a rough approximation of the picture, then fill in details later. Sloppy as it sounds, this improves the user experience, because basic page elements get assembled quickly. Users can interact with the page – read your text content and such – before the loading process is completely finished.

In the mid-90′s Paleoithic Era of the web, designers used the “lowsrc” attribute of the <img> tag for similar reasons. Browsers can load a super-compressed version of an image first, then load the “real” file later. The lowsrc approach – which requires downloading twice as many images – has been all but abandoned in favor of the progressive-loading technique.

If you’re slipping into the radical optimization mindset, you’ve no doubt noticed that progressive or interlaced images are sometimes a little bigger kilobyte-wise. In this case, learn to live with it – there’s more to making a page “optimized” than just download size.

In fact, there are 3 kinds of speed to think about on the web:

• Download Speed
• Render Speed
• Visual Accessibility

A user makes the split-second decision between clicking through or heading back based upon a combination of these three types of speed. A good designer needs to find a way to balance the three elements, not unlike balancing a house of cards, to create the ideal download.

Note that this timeline ends the first second a visitor is able to access and meaningfully interact with a page, not strictly when the page finishes rendering. In terms of user experience, rendering time is often academic.

Knowing when a page has rendered enough to be useful (as opposed to a concrete ceiling of 10 KB or a “no more than three graphics per page” rule) gives a designer the layout latitude necessary to create a successful page. As long as users don’t ask, “Hey, how big is this page, anyway?”, the page is doing its job.

Cache Is Your Friend

There’s one more important technique that’s key to boosting the perceived speed of your site. Those images that repeat throughout your site – common logos, headers, or navigation bars – don’t need to be downloaded more than once. By default, most browsers set aside a memory cache to store recently-used images in RAM and on the hard disk. If a browser recognizes the same filename, it’ll pull the image straight from the cache instead of downloading it. This provides a massive performance boost that a lot of automated timing programs don’t acknowledge. Just pull out a stopwatch and see for yourself.

Since the client-side cache is such a useful ally, you should design pages with the browser cache in mind. For instance, if your site uses a number of different header graphics that vary only slightly (like a standard logo with various department names underneath it), try breaking up the image so that the unchanged portion (the standard logo) is stored in the cache and always loads immediately. Though you’ll still need to load a new graphic on each page (in this case, a department name), the image is smaller and therefore downloads faster.

Browser caches are conceptually similar, but not the same thing as Network (or “Proxy”) cache, which we cover later in this Tutorial.

Size ‘Em Right

While your image editor is open, make sure the image is the same size (at 72 dpi) as it will appear on the web page. In your HTML, use the WIDTH and HEIGHT attributes of the  IMAGE¢ tag to restate the image’s actual dimensions. This allows the browser to lay out the rest of the page while the image is still downloading – so folks have something to read while they wait – and ensures that people surfing with “images off” will still see the page in its proper layout.

If you’re using tables on your page, image dimensions take on a special importance since dimensionless images sometimes force browsers to clear and re-render the page. This occurs when a browser starts building the table’s structure according to the HTML-specified <TABLE> and <TD> dimensions and then, belatedly, discovers that an image lacking HTML dimensions is, in fact, too large to fit. Browsers will then re-render the table to accommodate the unwieldy image. This inefficient page rendering takes time, and it’s unpleasant for the user to see page elements move around, or disappear and reappear.

You probably know this already, but when it comes to the WIDTH and HEIGHT attributes, the most important thing to remember is never use them to re-size or adjust the shape of graphics on your pages! Re-sizing via HTML is super-bad for two reasons. First, if you increase an image’s dimensions larger than the image’s actual size (at 72 dpi), you’ll end up with a jagged picture. Like this:

Secondly, you’ll take a nasty performance hit. Using HTML to make an image appear smaller than its true size doesn’t always look as bad, but much more data gets downloaded than the browser actually needs for drawing the image, thus adding to the download time.

Rules, of course, are made to be broken, and there is one case where it’s acceptable to fracture this rule. If you’ve been browsing Wired and Webmonkey long enough, you’ve probably seen images like this:

In this case, both pictures are actually the same GIF file, so they take the exact same amount of time to download. However, the one on the right has been doubled in size via the WIDTH and HEIGHT attributes of the img tag. There isn’t any jaggedness because this image lacks any curves or diagonal lines. If you’ve got a logo or design that’s all right angles (lucky dog), you can use a super-small GIF (which downloads cheetah-quick) and then re-size it to your heart’s content in HTML – just remember to keep the dimensions proportional.

You artsy folks out there might want to experiment with using HTML to re-size all sorts of images for creative effect (certainly the designers here at Wired used to enjoy it). Of course, only you know if the company president will care if you take the “artsy approach” with his photo.