Live data from Hacker News

A 2x Faster Web

blog.chromium.org

41–50 of 69 posts

Re: A 2x Faster Web

#41
post #12

I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web: Update their PageRank algorithm to take into account website speed, and then publish this as a fact. The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and…

This is a horrible idea. Yes, it would result in increased focus by some people on speed, but probably the same people who focus on "SEO". So now content relevancy has yet another adversary in the battle for SERPs. There's a LOT of really incredible, original content out there written by amazing people who do it in their spare time and don't give two shits about their SEO or the speed of their server, and now that co…

You are correct that SEO people would latch onto the idea and start producing faster sites. But so will many legitimate sites that want to provide a good user experience. Is that really so bad?

I think that site speed does correlate with a better user experience. A site that loads quickly shows that the person who made it cares about my experience more than a bloated site that takes forever to load.

I will admit that it's certainly not as as strong an indicator as the content, inbound links and other factors that are rumored to be part of PageRank but speed does matter. All other things being equal, I would much rather visit a site that loads in 2 seconds than one that loads in 20 seconds.

Re: A 2x Faster Web

#45
post #31
post #7

Impressive, how Google are taking on challenges that pretty much no other company could possibly address... replacing email... enhancing HTTP, etc... They're the only company with the means to take on such massive, unprofitable projects, and at the same time enough street cred that everyone won't immediately assume they're trying to make the web proprietary. The fact that they tend to open up these things from the ge…

They're the only company with the means to take on such massive, unprofitable projects, and at the same time enough street cred that everyone won't immediately assume they're trying to make the web proprietary. They are hardly the only company doing this. Microsoft Research do a ton of pretty visionary / far-reaching work, much of which has nothing to do with MS-proprietary platforms. For example, the VL2 architectur…

Another example: Simon Peyton-Jones and Simon Marlow, which make up a huge chunk of power behind Haskell and specifically GHC, are Microsoft researchers. (Although Haskell and GHC are not Microsoft projects, they get paid by Microsoft to work on them.)

Re: A 2x Faster Web

#46
post #29

Regarding the use of SSL by default, they better require the use of the SSL mode which sends the hostname before the crypto negotiation. Otherwise that's a lot of IP addresses required for virtual hosting!

We will.

Even so, the current certificate issuing process is lengthy and expensive. Requiring SSL would be a major hit to the mom-and-pop type websites that just want a simple webpage on their own domain for their business.

They'd now have to pony up for an SSL cert, which at least doubles the website ownership cost, as well as potentially go through a very complex process to get the certificate issued.

It also completely eliminates the possibility of them having a free website on their own domain, unless an easy and free method to obtain an SSL cert becomes available.

The gain to them in these circumstances is negligible, if they aren't doing any e-commerce.

Re: A 2x Faster Web

#47
post #11
post #8

Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// ). It see…

You could browse to the page the regular way, then load a Javascript or Flash library which would use SPDY for all further communications. In your typical web app the user experience could be visibly improved. You can already do this with Flash today, and it would be much easier for Google to push it into the DOM than to touch the transport protocol.

I'm missing how javascript has the abilities to touch the transport layer in such a fundamental way -- could you explain?

Re: A 2x Faster Web

#48
post #20

I've a bad feeling of this potentially making the web layer more complex. Also the encryption bit may not be a good idea if you are not Google... In general I'm more happy with web standards . Google doing research on this is great, but if they unilaterally push solutions that will anyway hit the mass market because they are Google is not good. All the web, the idea of HTTP APIs and so on are based on the fact that H…

I wouldn't be so afraid of Google being able to unilaterally effect change without consensus. Even getting adoption for their Chrome browser seems to be an extreme uphill battle.

Re: A 2x Faster Web

#49
post #29

Earlier quoted context omitted.

We will.

Even so, the current certificate issuing process is lengthy and expensive. Requiring SSL would be a major hit to the mom-and-pop type websites that just want a simple webpage on their own domain for their business. They'd now have to pony up for an SSL cert, which at least doubles the website ownership cost, as well as potentially go through a very complex process to get the certificate issued. It also completely eli…

mom and pop brochure sites are not the sort who would be using spdy anyway, they'd just use http.

Re: A 2x Faster Web

#50
post #8

Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// ). It see…

Wouldn't spdy capable browsers declare this capability so the server could immediately redirect to spdy:// those clients that support the protocol?
Post reply on HN