41–50 of 56 posts
It's 100 kB now. 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.
I find this interesting as well as unimportant at the same time. Interesting because it shows that Google has responded to increasing connection speeds by adding bells and whistles to their homepage. That's really great. 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…
I find this interesting as well as unimportant at the same time. Interesting because it shows that Google has responded to increasing connection speeds by adding bells and whistles to their homepage. That's really great. 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…
Strangely, Google is killing off the one thing that keeps me going to their sorta homepage , iGoogle. When they finally do kill it about a year from now, I'll have to come up with some substitute which may not be so Google-centric.
This is ignoring the fact that a whole bunch of assets (CSS/JS) are embedded into the page to reduce the number of HTTP requests.
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.?
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)
This is ignoring the fact that a whole bunch of assets (CSS/JS) are embedded into the page to reduce the number of HTTP requests.
Wouldn't it be better to have two asset pages, one for JS and one for CSS. ( unless there's a way to merge those two ) 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 id…
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.
I always enjoyed this interesting story: 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
[1] http://web.archive.org/web/20030205061559/http://www.google....
Earlier quoted context omitted.
No, #bytes * (1 kilobyte)/(1024 bytes) = #kilobytes or bytes/1024=kilobytes, for short. Basically, it's a conversion factor, not a definition.
Might want to consider using the unambiguous term kibibyte instead. http://en.wikipedia.org/wiki/Kibibyte 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.