Unimportant because with Google Chrome, Firefox, Safari, etc. - going to the google homepage is almost entirely optional. Google is working so hard into baking themselves into almost any facet of web functionality that their homepage is becoming less and less important over time.
The only reason I check the google homepage is to look at the doodles.
User adoption is what drives features like this to remain, not how useful they are.
One vigilante sent Google an anonymous email every so often just listing a number, like 37 or 43. Eventually Mayer and her colleagues figured out it referred to the number of words on the Google homepage—the implication being that someone was keeping track, so don't screw up the design
– The Google Story
"The size of the index of a search engine is estimated on the basis of a method that combines word frequencies obtained in a large offline text collection (corpus), and search counts returned by the engines. Each day 50 words are sent to all four search engines. The number of webpages found for these words are recorded; with their relative frequencies in the background corpus, multiple extrapolated estimations are made of the size of the engine's index, which are subsequently averaged. The 50 words have been selected evenly across logarithmic frequency intervals (see Zipf's Law). The background corpus contains more than 1 million webpages from DMOZ, and can be considered a representative sample of the World Wide Web."
Now don't get me started on the results page though...
The '.html' file for google.com has most of the 'fanciness' embedded in it in the form of a ton of JS and all the CSS.
I think this architecture was put in place when instant search/preview went live which is the cause of the first large spike. I'm guessing the second spike is integration with google+.
Perhaps OP forgot to put id_ after the capture timestamp in the archive URLs? The id_ makes sure that the Wayback Machine only returns the page as it was when it was indexed.
If the plot had a similar curve from 0-50kB would everyone still be commenting? What about 0-5 kB?
Is this about the absolute values or the curve?
Unless everyone is expecting exponential page size growth to continue indefinitely (and ignoring bandwidth increases), I don't see the point.
google used to prize page load times for their search landing page. i wonder if the increase is coming about because they recognize they can indeed get away with it and maintain their performance goals, or if they re-shifted priorities and/or acceptable values for load times.
And I haven't checked, but perhaps most of the k weight comes in after the page has rendered, in which case it wouldn't negatively impact perceived load time.
The page is also more featurefull than it used to be when in the logged in state.
I don't know how often google changes that code, but even if it were as often as weekly, users would gain the benefit of caching those files and loading locally, thereby making the page even less to download.
Or are those two http hits really that expensive?
The only reason I can think it is a bad idea is caching could hurt them. If the browser doesn't handle caching correctly, and they do change the source, frequently or infrequently, users may see broken pages and/or broken functionality. Not all users know of Shift-reload, none should need to, and I find it doesn't work reliably myself.
What is the best practice here? 2 http requests, embedded code on the page, arbitrary http requests that are cached, no caching, etc.?
Typically you just use a new URL to get around this ... Frequently changed cacheable files (css, js) are usually timestamped or contain version information in the filename.
Nowadays there are lots of really fat websites with tons of resources. Personally, I think that's kinda convenient. This way it's a lot easier to make sites which are much faster than those of the competition.
More and more people start to merge all of their CSS and all of their JS files, then they minify them, and finally the whole thing is gzipped. This surely helps a lot. However, their sites still continue to grow, because they continue to add more and more crap.
In reality, it was 28.8Kbps up to 1999, then has remained in the 2-3 Mbps range ever since.
Does anyone have a good CLI for Google and duckduckgo that I could use from within putty with clickable links? (similar to surfraw, but just dumping text + URLs from the results to stdout instead of launching a text mode browser)
$ curl -sL http://google.com | wc -c
#bytes * (1 kilobyte)/(1024 bytes) = #kilobytes
or bytes/1024=kilobytes, for short.
Basically, it's a conversion factor, not a definition.
It is a tradeoff, it avoids the need to explain which definition of kilo is used, at the cost of using a far less common term.