TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Not as SPDY as You Thought

27 pointsby muriithiover 12 years ago

5 comments

justinschuhover 12 years ago
This was on HN eight months ago, when the post was actually made. And the takeaway is pretty clear, you probably won't see a benefit in using SPDY in front of a site optimized in ways that don't take advantage of SPDY's strengths. If you want to see big improvements with SPDY (like Google does) then you need to adjust how you're serving your resources. Resource prioritization is a perfect example of this: <a href="https://insouciant.org/tech/prioritization-is-critical-to-spdy/" rel="nofollow">https://insouciant.org/tech/prioritization-is-critical-to-sp...</a>
评论 #5124569 未加载
ck2over 12 years ago
<a href="http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-you-thought/" rel="nofollow">http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-...</a>
starik36over 12 years ago
Like others said, an old post. To be sure, he is testing the SPDY speed from a client to a SPDY proxy that then connects to a real HTTP site.<p>It makes no sense to correlate these results with real SPDY web servers serving real traffic.
Sami_Lehtinenover 12 years ago
Http vs Spdy: He didn't mention http features like, keep-alive and pipelining both can make huge difference when sending data over connection having notable latency
评论 #5125228 未加载
jamestyrrellover 12 years ago
Yeah, this is a pretty old post.. Domain sharding, which is how resource rich sites enhance parallel loading, doesn't suit SPDY at all.
评论 #5125237 未加载