they decided to test 41 shades between each blue to see which users preferred. In the test, Google showed each shade to one per cent of its users, and found that users were more likely to click on a slightly more purple shade.
In your defense, it's only the 2nd sentence of TFS, can't noone expect you to have that high of an attention span, as it would certainly take you half an hour to read all the way till there.
My comment was short because I didn't feel like continuing to read yours after
It took my browser 25.5 seconds* to download it all [whereas with a single response] the browser would have to wait 25.5 seconds before it could even start rendering the page?
because it is so obviously flawed reasoning that I had to assume you're trolling. You can certainly have a full answer:
This page loaded 488KB of data. It took my browser 25.5 seconds* to download it all.
So we agree there's a problem. You do realize (since you're going to mention it) that most of this time is spent traversing the "dependency graph" to pull external resources.
What you're suggesting is all of that page data be included in a single response?
I wasn't suggesting anything particular, but if so I'd be suggesting to do away with most of the junk entirely.
So the browser would have to wait 25.5 seconds before it could even start rendering the page?
I'm startled about how you could possibly believe it would still take 25.5 seconds, when you at the same time seem to realize that a lot of the delay comes from external sites. That's like complaining about your 3km commute taking 1 hour in stop-and-go traffic, but then arguing that the alternative, 1 hour of high-speed driving, would be just as exhausting. Do you see the flaw?
Where it'd be difficult for the browser to then cache content that could be shared across multiple pages?
Of which there is a huge lot, right? Especially big images and videos are frequently shared across multiple pages. Oh wait, they aren't. It's tiny, irrelevant shit like facebooks "like"-icon that might be shared, but then again, this isn't worthy to cache. Furthermore, caching is mostly irrelevant if non-cached requests don't take very long in the first place. This is basically the same flaw in reasoning as pointed out in the preceding paragraph.
Compare that to the current dependency structure where the DOM was loaded in 2.41 seconds & the page was considered loaded at 5.91 seconds.
I'm not sure what your point is, or what this has to do with the matter. Feel free to elaborate.
Browsers are already pretty good at doing things in parallel
Except, according to you, starting to render an incomplete page before the </html> tag is encountered. You should note that what external resources are going to be fetched is not a-priori knowledge, though, so your browser cannot just parallelize from the start. It has to wait for the main document which contains references to 1st order depencendies, which it *then* might attempt to parallely fetch, until those contain references to 2nd-order dependencies, and so on. Sometimes not before the javascript engine hat its go at them. There is no such thing as a This-site-will-require: <exhaustive list of resources> HTTP-header.
and with proper web development,
..which seems to be the exception..
you can sensibly prioritise external content so that the user can see the important/useful bits of a page
..like the "This page requires javascript to work"-document..
while the rest downloads in the background
..which sites already do, with moderate success..
to add the polish on the turd.
FTFY. Seriously. "Adding polish on top" makes it sound like the status quo was already very good.
I'm obviously being pedantic here because I'm sure that's not what you literally meant.
I'm not sure what that refers to.
It could be argued in my example that the majority of/.'s 25.5 second load time was for non-critical assets/content considering the page was usable mu
It's called gravity assist. You gun it down a hill then coast up the next.
Which still gives a net loss of efficiency, thanks to non-linear air drag, mainly. Plus, it should be fairly obvious that you're not going to gain more energy by going down a hill than you'll be expending on the climb of the next hill of the same height, regardless of what speed(s) you go.
That said, unless I'm misremembering it, ICEs efficiency peaks under high load, so by coasting uphill you're missing out on an opportunity to operate your engine at max. efficiency, even.
Come to think of it a bit more, probably there's a slight bias towards the front since there should be more head-on collisions than people rear-ending with the rear end. I'd assume the impact of this on the 50:50 chance to be negligible, though
Slashdot Mirror
that outloud, that outloud, that outloud, that outloud, that outloud.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition.
they decided to test 41 shades between each blue to see which users preferred. In the test, Google showed each shade to one per cent of its users, and found that users were more likely to click on a slightly more purple shade.
Way to give a meaning to noise.
time stops for you, forever
*facepalm*
Too bad there is no Phoenix in Starcraft
Then again, rsnap is a seven kilolines perl script around rsync...
The same way it interferes with your redundant RAID array.
and rembrandt was fucking REMBRANDT
For fun or for the sole purpose of procreation?
While I agree about not being a GNU Project, "Linux project" makes no sense at all.
Wasn't HKCU just one part of the "whole windows registry"? In win98 it was, anyway.
I wasn't aware gnome was broken like that. FWIW there's always xsel(1)
I don't want tabs adjusted so they align
Then you don't want tabs, it seems?
- Intel Chips that are not Xeon's
- AMD chips that are not Opteron's
Tough shit, where can I find Xeon and Opteron, and why do they have all the good hardware?
OS X could be the LED.
You mean the LED as in cheap, or as in energy-efficient?
It seems like a moron was successfully cued as the subject said.
Take this whoooosh from me and treat it with care.
/. only "refreshed" the home page when it was adding new content.
Right, the server informed your browser via magic that there's new content, so your browser can refresh to check it out.
2.6.32 had ~9.8 MLoC
Most of which are device drivers.
current kernel at ~16.8 MLoC
Most of which are device drivers, and some more device drivers.
Yeah, what coul
this secure concept, single-user desktop OS
possibly be?
In your defense, it's only the 2nd sentence of TFS, can't noone expect you to have that high of an attention span, as it would certainly take you half an hour to read all the way till there.
what saved reactor 2's pressure vessel from exploding?
I'd suspect it was the same that saved reactor 1, 3 and 4's pressure vessels from exploding.
Until the clocks run out, presumably.
My comment was short because I didn't feel like continuing to read yours after
It took my browser 25.5 seconds* to download it all [whereas with a single response] the browser would have to wait 25.5 seconds before it could even start rendering the page?
because it is so obviously flawed reasoning that I had to assume you're trolling.
You can certainly have a full answer:
This page loaded 488KB of data. It took my browser 25.5 seconds* to download it all.
So we agree there's a problem. You do realize (since you're going to mention it) that most of this time is spent traversing the "dependency graph" to pull external resources.
What you're suggesting is all of that page data be included in a single response?
I wasn't suggesting anything particular, but if so I'd be suggesting to do away with most of the junk entirely.
So the browser would have to wait 25.5 seconds before it could even start rendering the page?
I'm startled about how you could possibly believe it would still take 25.5 seconds, when you at the same time seem to realize that a lot of the delay comes from external sites.
That's like complaining about your 3km commute taking 1 hour in stop-and-go traffic, but then arguing that the alternative, 1 hour of high-speed driving, would be just as exhausting. Do you see the flaw?
Where it'd be difficult for the browser to then cache content that could be shared across multiple pages?
Of which there is a huge lot, right? Especially big images and videos are frequently shared across multiple pages. Oh wait, they aren't. It's tiny, irrelevant shit like facebooks "like"-icon that might be shared, but then again, this isn't worthy to cache. Furthermore, caching is mostly irrelevant if non-cached requests don't take very long in the first place. This is basically the same flaw in reasoning as pointed out in the preceding paragraph.
Compare that to the current dependency structure where the DOM was loaded in 2.41 seconds & the page was considered loaded at 5.91 seconds.
I'm not sure what your point is, or what this has to do with the matter. Feel free to elaborate.
Browsers are already pretty good at doing things in parallel
Except, according to you, starting to render an incomplete page before the </html> tag is encountered.
You should note that what external resources are going to be fetched is not a-priori knowledge, though, so your browser cannot just parallelize from the start. It has to wait for the main document which contains references to 1st order depencendies, which it *then* might attempt to parallely fetch, until those contain references to 2nd-order dependencies, and so on. Sometimes not before the javascript engine hat its go at them. There is no such thing as a This-site-will-require: <exhaustive list of resources> HTTP-header.
and with proper web development,
..which seems to be the exception..
you can sensibly prioritise external content so that the user can see the important/useful bits of a page
..like the "This page requires javascript to work"-document..
while the rest downloads in the background
..which sites already do, with moderate success..
to add the polish on the turd.
FTFY. Seriously. "Adding polish on top" makes it sound like the status quo was already very good.
I'm obviously being pedantic here because I'm sure that's not what you literally meant.
I'm not sure what that refers to.
It could be argued in my example that the majority of /.'s 25.5 second load time was for non-critical assets/content considering the page was usable mu
I think you answered your own question there.
What you're suggesting is all of that page data be included in a single response?
No. Please think harder.
would still be cooler if there was no 'dependency graph' of dynamically loaded resources behind my every HTTP request.
It's called gravity assist. You gun it down a hill then coast up the next.
Which still gives a net loss of efficiency, thanks to non-linear air drag, mainly. Plus, it should be fairly obvious that you're not going to gain more energy by going down a hill than you'll be expending on the climb of the next hill of the same height, regardless of what speed(s) you go.
That said, unless I'm misremembering it, ICEs efficiency peaks under high load, so by coasting uphill you're missing out on an opportunity to operate your engine at max. efficiency, even.
Come to think of it a bit more, probably there's a slight bias towards the front since there should be more head-on collisions than people rear-ending with the rear end. I'd assume the impact of this on the 50:50 chance to be negligible, though