What is Digg?1 Comments
- Bogtha, on 10/12/2007, -2/+2> Compression: Enabling compression can dramatically speed up sites which transfer large web objects.
Be aware that Internet Explorer 6 has a bug that can screw this up.
"Internet Explorer May Lose the First 2,048 Bytes of Data That Are Sent Back from a Web Server That Uses HTTP Compression"
-- http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496
> Number of Objects: Reduce the number of objects per page. Most browsers which I’ve used limit the total number of objects the browser can retrieve from a site to 2 or 4 objects at a time.
The limitation to two connections at a time is actually part of the HTTP standard:
"Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."
-- http://www.ietf.org/rfc/rfc2616.txt
> Merging Javascripts and CSS into html file are other common ways of reducing objects.
That's actually counterproductive for most websites as the HTML files are usually far less cachable than the stylesheets and JavaScript resources. Feel free to merge all your JavaScript into one file and all your CSS into one file, but don't merge them into the HTML, keep them as external resources.
> If you can’t reduce the number of objects try to distribute your content over multiple servers.
Also, if you do this, it's usually a good idea to distribute according to what type of resource they are. Stick the static files like images on a fast, lean server, and leave the more flexible Apache to serve the dynamic content like PHP scripts.
> Using AJAX won’t speed up your website
This is simply not true. There are loads of situations in which Ajax can speed up a website. When GMail was first launched, everybody was remarking how fast it was. And can you imagine how much extra bandwidth and server resources Digg would waste if every time you dugg a comment, the page had to be reloaded?
> Enabling expiry tag on objects can intelligently tell browsers to cache the objects for a predefined amount of times.
This is a case where not knowing the right name for something can really confuse people. There's an HTTP "ETag" related to caching. But that's not what he's talking about, he's not actually talking about a "tag" at all. He's talking about the Expiry *HTTP header*.
Terminology matters. Stop calling everything remotely related to the web a "tag".
> I regularly look for 404s and 500s to see for missing pages or application errors.
Wow, you actually do that manually? Don't waste your time, just have your 404 handler email you when a particular resource hasn't been found five times (setting a minimum of five wards off spurious reports caused by buggy bots and typos).
Also, one thing that's rarely mentioned: make sure you are linking to the right places.
For example, if you have a directory /foo, don't link to /foo - link to /foo/ . You don't link to /foo because the browser requests the resource, and the server has to respond with a redirect to the real resource, /foo/ .
Another example is being indecisive about whether you link to /foo/ or /foo/index.html . Pick one or the other, don't mix them. They are different resources as far as HTTP is concerned, and if you use both, that means you are driving your cache hit ratio down for no good reason.
If you are using content negotiation to transparently serve application/xhtml+xml to user-agents that can handle it, rip all that out and throw it away. Unless you have extremely specialised needs, you don't need to serve application/xhtml+xml to anybody, just use text/html. Using conneg again drives down your cache hit ratio, and some caching proxies won't cache resources with a Vary header at all.
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is