TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why are pages slow?

25 点作者 eduadecastro超过 12 年前

5 条评论

rhplus超过 12 年前
I'm interested to see what's said for "poor cache-ability". It's an area where the assumption of "more caching is better" can be wrong. I've seen real-world A/B test results that indicate <i>client-side</i> caching can often be <i>slower</i> than re-fetching a resource from the network. Typically, this is true for small resources being loaded from the disk cache (i.e. your home page on a new browser session). It's counter intuitive, but many network connections to hot CDNs are faster than fetching from a local physical (spinning) disk.
评论 #5290940 未加载
评论 #5291080 未加载
评论 #5291275 未加载
评论 #5291098 未加载
olegp超过 12 年前
I've spent a fair amount of time (over) optimizing <a href="https://starthq.com" rel="nofollow">https://starthq.com</a> and would say that network latency needs to be at the top of the list of things to look at.<p>The solution has been to serve static HTML, i.e. the index page of the single page app part, with a one hour cache expiration and links to other static resources (JavaScript, CSS, images etc.) decorated with their E-Tag and loaded from a CDN. For non static pages the set up is the same, but the caching time is lower. The static resources have far off (one year or so) expiration headers so are cached permanently.<p>By using a CDN for all your assets you can reduce a 200ms roundtrip to 8ms for all users worldwide, bringing the page loading time to way below 200ms with an empty cache and well below 100ms with a primed cache since you still need to do an XHR to check the login status.<p>Small time saving tip: if you go with CloudFront, go all out and use all edge locations - it's cheap. I tried using Europe only at first only to eventually find out that I was still being given an edge location in the US despite being in Finland.
lennel超过 12 年前
Most single page javascript apps that don't prerender are the biggest sinners in a multitude of ways. 1) with the amd loading system you spawn multitude http requests, where 2) none of the code went through a tree shaking to remove dead code (ala the closure compiler in advanced mode - or something which cross compiles) you download a whole steaming heap you don't need thus extra bytes 3) no pre-rendering, so now you are blocking the users experience till your whole steaming pile has managed to trickle down onto a mobile device, the joy
ww520超过 12 年前
Install the YSlow plug-in and see the bottlenecks right the way.
ohwp超过 12 年前
Says the page that take 3.43s to (down)load in my browser, loading 8 CSS files and a lot of JS files.<p>On a serious note: I think Opera Dragonfly is also a great tool for this providing even more information.