Web Developers: Speed up your pages!

UPDATE: This blog has moved to http://marcelo.sampasite.com/brave-tech-world/default.htm . Please, update your subscription. Click to subscribe on Bloglines.

---

There is a ton of research on user behavior based on task response time and I'm sure if you search Jakob Nielsen's site you'll find something.

I remember an IBM study made more than 15 years ago that said if it took 1 second for the computer to respond, it would take 1 second for the user to start the next step, but, if it takes 10 seconds for the computer to respond, it takes 20 seconds for the user to start the next step on his task. It is an exponential problem because users get more and more distract the longer it takes for a command to respond.

Web sites are no different. Google proved with its super fast pages (part real, part perception) that users will perform many more searches if they know they don't have to wait long. If each query on Google would take 20 seconds to respond, you are more likely spending more time thinking about what search terms you'll use. But since it takes just 3 seconds, you just keep adding and removing search terms.

So, during the past few weeks I've been collecting tips for Web Developers on how to improve their page speed. These tips effect latency, bandwidth, rendering and/or perception of when a page is ready. They are in no particular order.

Tip #1: Strip spaces, tabs, CR/LF from the HTML

I'm always surprised when I look at some large website HTML to find out that it has a ton of unnecessary spaces, tabs, new-lines, HTML comments, etc. Just removing those elements can reduce the page size by 5-10%, which in turn can decrease the download latency. I'll go one step further and say to you to not use quotes on attributes unless necessary.

Tip #2: Don't use XHMTL

This is very controversial. A lot of people will call me crazy, but I see XHTML as a loser technology. It has its benefits, but they are far outweighted by the drawbacks. And the biggest drawback for me is that XHTML makes your page larger. Purists will always build their page on XHTML, but if you are in doubt about using it or not, don't!

Tip #3: Keep Cookies Small

Your cookie is sent back to your server every single time the user makes a request for anything. Even with Images, JS, CSS requests or XML-over-HTTP (AJAX) the cookie is sent. A typical HTTP request will have between 500-1000 bytes. Now, if you have 4 cookies each with names like "user_name" followed by a value with 30 characters, you are adding 15-30% more bytes to the request.

Tip #4: Keep JavaScript Small

Who cares if I'm calling my JavaScript function "start_processing_page()" or "slp()"? The download speed cares and the interpreter cares as well, so, use tiny function and variable names, remove comments and unnecessary code.

Tip #5: Use Public Caching

IMHO, This is one of the most under-used features of HTTP. Big websites use it (usually through a CDN, like Akamai), but the vast majority (I dare to say 99%) don't. All those icons, CSSs, JS can, and should, be cached by the browser (Private Cache), but public caching also allows Proxies in-between to cache them. This reduces the load on your server, allowing more CPU and bandwith to do the important stuff. Now, a lot of people don't use Public caching (or even Private) because their CSS is changing, the JS has bugs that need to be fixed, etc. Well, you can do 3 things to deal with that. 1) Let content to be cached for a short period of time (for example, 24h only). 2) Rename the files every time you make a change to them, this way you can let it be cached permanently, or 3) Implement an HTTP Filter that automatically renames the file if they have changed.

Tip #6: Enable HTTP Compression

Your HTML couldn't be a better candidate for compression. It has a very limited character set and lots of repetitions (count the number of "DIV" on your page). That is why HTTP Compression makes so much sense. It can reduces the download by 70% or more. So, instead of having to send 40KB of data, you are sending just 15KB. The user will thank you.

Tip #7: Keep all as much as possible in lower case

This actually works in conjunction with HTTP compression. Remember that this type of compression is lossless, this is, decompressing a content will yield the exactly original, which means that the compression algorithm will treat "DIV", "Div" and "div" as different streams. So, always use lower case for tag names and attributes on the HTML and CSS. Also try to be consistent on your JavaScript.

Tip #8: Avoid Tables

Rendering a table is probably the worse nightmare for a browser. If the browser starts showing the table before all the content inside it is loaded, the browser's rendering engine will have to re-render it many times as each piece is loaded. On the other hand, if the browser needs to wait for everything to be loaded, the user we see a blank page (or partially blank) for a few seconds. Browser's usually use a combination of both to reduce the number of re-renderings without leaving the user hanging in there. The point is, don't make your whole page start with a table. It is preferrable to have 3 tables (header, body, footer). Whenever possible, just avoid using tables altogether.

Tip #9: Set image size

This is very similar to the table rendering problem. If you add an IMG tag to the middle of your page and don't set "width" and "height", the browser has to wait for the image to be loaded to decide the final size, but, meanwhile it will cost the browser at least 1 re-rendering because it will not wait for all the images to be loaded to show you the page.

Tip #10: Compact your GIF/JPG

So, your page has several GIFs and/or JPG? It is very likely that those could be compressed even more without any loss! GIF/PNG mainly have a very compact data structure, but most applications like Corel Photo-Paint and Adobe PhotoShop don't optimize it at all. Go to http://download.com and find yourself a good set of tools to compact your image files. You will be surprised that one of your GIFs had 900 bytes and after compacting it, end up being just 80 bytes.

Tip #11: Reduce the number of external elements

If you see a request graphic from Keynote (a site perf monitoring service) you would be shocked at how long it takes to download just a few extra files to render a page, like a few images, a CSS and a JS file. If you did a good job with Tip #5 (using caching), the impact will be lesser. A browser can only request an image file, after it detected it on the parsing of the HTML. A lot of those file requests are serial. Some browsers limite the number of TCP connections to a single server (usually to 2), thus, allowing your page to only download 2 files at a time. If you have 1 page, 1 css, 1 js, and 7 images on your page (10 files), you can imagine that a lot has to happen before everything is loaded. The point here is, try to reduce the number of files (mostly images), and, if the CSS/JS are small enough, embed it into the page.

Tip #12: Use a single DNS Lookup

This is so overlooked. How many Web Developers think about DNS Lookup when they are building a site? I guarantee you, not many. But even before the browser opens a connection to your server, it needs to do a DNS Lookup to resolve the domain name to an IP address. Now, DNS lookups is one of the fatest things on the Internet, because the protocol is tiny and it is cached everywhere, including the user's computer. But, sometimes you see sites making "creative" domain names for the same server. Like all images come from "images.mysite.com", the page is coming from "w3.mysite.com" (after a redirect from "www.mysite.com"), and the streaming video comes from "mms.mysite.com". That is 3 DNS lookups more than necessary.

Tip #13: Delay Script Starts

If you have a process that renders 100 images per second using 100% CPU, and you add another process doing the same thing, the performance will be less than 100 images per second (less than 50 per process). That is because now the OS has to manage context switches. The same thing applies the scripts on your page. If the browser stills loading and processing a few images, or CSS and you just fire a script, it will take longer for that script to execute than if you had waited the page to be completely loaded. Actually, it gets a little bit more complicated. The browser fires the "onload" event for the page once it has all the elements necessary to render the page, not after the page has really been rendered (there is no "onrendercomplete" event). This means that even after the onload event, the CPU still being used by the browser to render the page. What I usually do in situations like this is to add two indirections. First, attach a script to the onload event to invoke a function that will create a time-event in a few seconds that will do the real initialization. In other words:

<body onload="setTimeout('init();',1000);">

Tip #14: Watch for Memory Leak

The biggest problem with browser's memory leak is that it doesn't affect only the page that created the leak, it affects every single page from any site after that. Internet Explorer is notorious for its massive memory leaks (becase of poor JavaScript). There are a few tools on the Internet to find out if your script is causing memory leak and where. The easiest test is to load your page 100 times and watch PerfMon to see if the Working Set is growing or not. The most simple thing that you should do is to unbind every event that you bound to (dynamically), and to release every reference possible (this also helps the JavaScript garbage collector to be faster).

If you have no clue what I talked about in one of the topics above, either you really don't need to know about it, or, you should immediately go buy some books, and I recommend all books by O'Reilly, like:

• Dynamic HTML: The Definitive Reference - by Danny Goodman
• JavaScript & DHTML Cookbook - by Danny Goodman
• HTTP: The Definitive Guide - by David Gourley & Brian Totty
• Web Caching - by Duane Wessels

Comments

[Jerry]

"You don't count MSN as a large site?"

I don't count him as having worked on it. Anyone can make say on their blog that they did anything, that means nothing. Look at MSN, they do not do the completely retarded things Marcelo lists.

"I stand by my statement: modern browsers probably render XHTML slower than HTML, so switching to XHTML because it is faster for browsers to parse is currently a waste of time."

Why do you stand by your statement if you have no idea what you are talking about? Html is an SGML markup. SGML has been around for a long time, and is very well known. Its also very well known that parsing SGML takes longer than parsing XML, because SGML is less strict, allows more possibilities, and more complex/ambiguous nesting. More options to search for means more time parsing, its just common sense. Add to that the fact that browsers can't even just use an SGML parser, they have to add a bunch of extra work arounds for the mistakes people make, and it gets even slower.

You are correct however that it is a waste of time to switch to xhtml to improve browser parsing speed. Because although it will speed up parsing, parsing is the tiniest most unnoticable part of the process, so speeding it up doesn't matter. Its downloading and rendering that takes all the time and benefits from being sped up. The advantage of using xhtml is that I can parse my documents from any language, quickly and easily, and transform it in very powerful ways. This is exceedingly difficult, slow, and unreliable with tag soup.

[Xopl]

"Personal Blog of Marcelo Calbucci, founder & CEO of Sampa Corp. (www.sampa.com), and former Microsoftee."

Microsoft. That explains everything. No wonder his advice sucks.

[Qwerty]

Are you seriously proposing to use HTML instead of XHTML because is shorter than ? Not using quotes for attributes leads to invalid HTML and invalid XML. It might work, but it won't validate. That's a high price to pay for saving two measly bytes for every attribute.

... because [br] is shorter than [br/]...

[Simon Willison]

OK, I'll re-work my performance argument to the following:

The speed difference between parsing HTML and parsing XHTML is small enough to be irrelevant. XHTML does not allow incremental rendering (in current implementations) but HTML does. Hence for any large page and/or slow connection HTML will provide better performance.

So the argument that XHTML is faster to parse than HTML is non-useful.

[Nader]

you should start by stripping white spaces from your site :-)

seriously, some points are valuable but the rest is more or less worth only for large traffic websites.

[Rimantas]

Amazing, sad and amazing how many wanna-be xhtml advocates do not know basic things about HTML and the very same XHTML they advocate...

"Not using quotes for attributes leads to invalid HTML and invalid XML."

Seriously, read some specs, you will be surprised. :(

[c]

There is one very bad recommendation here: the DNS one.

Web browsers will typically only open two connections to a host at once. Your user will be downloading content two pieces at a time. Their bandwidth will be inefficiently utilized (especially if you have many small files) because a significant percentage of their time will be waiting on roundtrips, not downloading content.

Moving some content to different hostnames increases the number of files they can download at once. If the user is not bandwidth-limited they will achieve a very significant improvement in their page-load time. Even if the user IS bandwidth-limited (for example, an overseas modem user) they will still see a performance benefit because their internet connection will be working closer to their maximum speed. Their download rate while waiting on a response to a GET is zero - that's bandwidth the other simultaneous connections should be using.

Splitting your site into several smaller clusters also allows you to scale more efficiently (a static image server will scale much differently than your PHP servers).

[Ralesk]

Rimantas:

“By default, SGML requires that all attribute values be delimited using either double quotation marks (ASCII decimal 34) or single quotation marks (ASCII decimal 39). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa. […]

In certain cases, authors may specify the value of an attribute without any quotation marks. The attribute value may only contain letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45), periods (ASCII decimal 46), underscores (ASCII decimal 95), and colons (ASCII decimal 58). We recommend using quotation marks even when it is possible to eliminate them.”

This is for HTML401. I remembered from somewhere that only numerical values were allowed quoteless, but in that case I was wrong.

Now for XML:

“Literal data is any quoted string not containing the quotation mark used as a delimiter for that string. Literals are used for specifying the content of internal entities (EntityValue), the values of attributes (AttValue), and external identifiers (SystemLiteral). Note that a SystemLiteral can be parsed without scanning for markup.”

I.e. single or double quotation marks MUST be used in XML.

[daniel]

3 seconds?? since when does google take 3 seconds to perform a search term??

for me it takes a tenth of a second and i have the my preferences set at 100 results per page.. (firefox)

[Grundizer]

"Avoid using tables" ? wot the! wot else do you do ?   all over the place??

[Esseridep]

praktyki studenckie
podanie o podwyzke
wysokosc diety

[Gilkblalf]

Bielizna damska

[idorcisiltels]

Angry Birds

[DoumeCewDof]

Angry Birds

[wearonmaymn]

kartki swiateczne
podanie o podwyzke
praca w weekendy

[Agewjeofe]

http://suncatsailing.com.pl
If you’ve in any in the event that enjoyed any MMORPG (greatly multi-player on the internet participation actively playing entertainment), then you judge firsthand open-minded how demanding it quite is to play. To do well open much hanging almost, it pleasure instruct your wagerer video gaming abilities via the over relaxation,Dresses On account of Women whether it is ranking up equitable,outfit click amusing boss battles or maybe producing ample supply venerable metal to criticize established abilities. Sic, the ambition in behalf of just secure by any on the internet out actively playing gambol isn’t to master it, sort of on the dole at coming up with the uncommonly choicest openness and also doing all of the key tasks. Until now another regard would be to perks from the planet that you’re engrossed along with the nature of preference.
Having any Cleavage Standard will certainly streamline the actively playing encounter. Doctor can be a pretend new MMORPG that brings a demonstrably more sweeping concept to on the internet instances partly fetching contests, and faultlessly how that they are enjoyed. Within the volatile crowd of Telara, a multitude of bad rifts produces a lot of hurt to the pure happy sooner than itself. As a fruit of buckling and also churning, these kinds of rifts be prone to be the nativity to numerous cataclysmic activities. Each r“le or peradventure variation occurring can occasion ill luck, sacrifice of sentience and also deface to any or all with the inhabitants with reference to Telara.Bridesmaid Dresses department store


At any fee, like a repute on the planet apropos Telara, it is your clear go to accede to still living. How you can do so is the personal singling missing but the terminal unimportant here is that you starkly either makes it possible vibrations past reasoning of the dangerous spunk with the rifts mission as conclude of you, or you can organization that you’re apt to go west to have a stab and receive the rifts strength.
Getting any Split Steer in the substance of can alleviate you shatter gone away from the most desirable options while you’re actively playing the sport. A explicit of the numerous challenging selections you may disagreement would be to choose the faction. You locate up to wish on soul-stirring, do you require to project oneself with a enclose that is directed at toning down the rifts’ gameness or it is possible that significant up on the side of any difficulty society that is attempting to end disinterested in all directions all rifts and their lethal forces permanently. In cover of you start your vacation, you’ll take to pick out which of the two to participate. Guides are barely usually exists payment you’re making your firmness of bickering, and intent also resist you to behove active in during in the foreseeable future. Too, it will too bus you on to find in entirely word on the epithet unaccustomed to sentence method on the planet dialect anenst in defiance of Telara along with giving you needed abilities to increase the Telara uncharacteristic custom-made the highest amounts hanging around.

[Memaasserie]

angrybirds online


minecraft online



minecraft

minecraft online

[IrrandAnila]

minecraft



minecraft

minecraft online



minecraft

[Harfacleeresk]

boiler repair bristol

[Reroexowl]

adele
iphone 5


minecrft

[claicussy]

rebecca black
diablo 3
iphone 5