3 ms·
If google, in theory, determined that users almost immediately hit the back button when they hit a 404 page, it would make sense to have the page load & render
by teej 17y ago
If google, in theory, determined that users almost immediately hit the back button when they hit a 404 page, it would make sense to have the page load & render as fast as possible. Right now, the page size is ~1.3k for me.
I also have a feeling that the 404 may be implemented in a different part of the stack than search. In a very unscientific test of data, the response times for 404 pages according to firebug are at least 10% faster than the normal response on the same subdomain. Also, of all the subdomains I tested, only m.google.com, picasaweb.google.com, and docs.google.com had different 404 pages.
Like I said, this is all blind guessing, but my feeling is that Google has reasons for not better utilizing 404s. Having better 404's isn't rocket science and there are google properties that have them (youtube) so there's certainly reasoning behind it.
- houseabsolute 17y agoYou'll probably notice that the 404 pages across most Google properties is the same. For example: http://images.google.com/mapss http://images.google.com/mapss And you might also notice that no matter what subdomain you hit, the path is all that seems to matter: http://images.google.com/maps http://images.google.com/maps http://maps.google.com/images http://maps.google.com/images It would be logical to conclude that there's some server you're hitting before you get to the service specific backend, and that maybe that is the reason the 404 pages come back faster.
- erickerr 17y agoSpeed here is a subject of debate. Does Google want to minimize the load time of this particular 404 page (so you can do whatever you're going to do), or do they want to minimize the time to your intended destination? I think it's the later.