How to Shave 73% Off of Your Load Time (It’s Really, Really Easy)

49 点作者 AlaskaCasey超过 8 年前

12 条评论

aembleton超过 8 年前

That 916 word article takes over 4.2MB to download. Over 1MB dedicated to some js file and nearly 1MB to a JSON file [1] containing indexes, the output of which I can't see in use on the page.1. <a href="https://www.netlify.com/js/lunr/PagesIndex.json" rel="nofollow">https://www.netlify.com/js/lunr/PagesIndex.json</a>

00deadbeef超过 8 年前

I ran the test about ten times and it only completed once.The TTFB score it gives is the average score from around the world. Do I need to care that somebody in Brazil has to wait a whopping 219ms to see my English language entirely UK-centric content? I don't feel this average TTFB is therefore very useful when my target audience will get my full HTML in less than 14ms as measured by this tool (this is actually the score from Germany as for some reason the site tests from London but doesn't display it in the results table).I also disagree that "slow and expensive legacy dynamic" PHP sites are necessarily slow. My personal site built in Slim 3 executes in less than 10ms, thank you. The only optimisation I did was turning on opcache. You'd be surprised how fast PHP 7 actually is. If I wanted I could turn on nginx's caching and serve up thousands of requests per second.Finally, this article doesn't explain how to shave off 73% of my load time without using Netlify, despite the author's claims that his "goal with this post [wasn't] to get you to use Netlify".[Edit]Their servers seem to be struggling with the tests. My site is now scoring over 1000ms which is not possible.

topaz0超过 8 年前

I'm not impressed if you're making me download 4MB to see the 5kB of text in this blog post.

caseydurfee超过 8 年前

The webpagetest of the blog post is pretty telling: <a href="https://www.webpagetest.org/result/170215_26_MSDP/1/details/#waterfall_view_step1" rel="nofollow">https://www.webpagetest.org/result/170215_26_MSDP/1/details/...</a>6.5 seconds to fully load the page in a desktop browser over cable modem. Over 18 seconds on a low-end Android phone. 9 web fonts loaded. Over 1.5 MB of javascript downloaded. Tracking beacons from ads-twitter, multiple "netlify.com" subdomains, addtoany, segment, intercom, mixpanel, twitter analytics, double click and GA, most of them blocking the load of the page.TTFB is kind of a vanity metric. If you're serious about it, the way to achieve that is using varnish + edge caching rather than switching to static HTML pages. You can have good TTFB and still have a slow rendering page, as this illustrates.(edit: spelling)

Kluny超过 8 年前

They have a website speed test that they want you to try. That's the whole point of the post, but you have to read to the bottom to figure that out. I tried the speed test. After 6 minutes of "connecting to Sao Paolo" I lost interest.

petercooper超过 8 年前

With 441ms to fully download the HTML, HBR.org is already much, much faster than the average site.Except it really isn't. They have a giant interstitial ad that takes up the entire page when you get there, so then you have to hunt down the link to close it. So they just wasted a couple of seconds. I don't care how quick it loads if the experience is that bad.

slantyyz超过 8 年前

Surprising result: news.ycombinator.com scored 0 out of a possible 100 points.<a href="https://testmysite.io/58a4993871e20a1fdab44dee/news.ycombinator.com" rel="nofollow">https://testmysite.io/58a4993871e20a1fdab44dee/news.ycombina...</a>-- edit - looks like time to first byte is what really kills scores

评论 #13654155 未加载

jshawl超过 8 年前

tl;dr: use a static site generator instead of dynamic pages when possible

wink超过 8 年前

Maybe it's me but their test seems to hate sites hosted in europe. (Strato, Germany)First I tested my site's landing page:43/100 - ok, no SSL, so HTTP2 and 367ms TTFB - I also apparently committed the capital sin of including a 160kb CSS file (foundation) without stripping it. Serves those 5 visitors per month well! Comparison: 66(mobile)/77(desktop) of 100 from Google PageSpeed Insights (with more useful hints what to fix) and 75/100 from tools.pingdom.com (224kb incl JS and CSS is apparently still too big and missing caching/Vary header).But now my gripe:Same host, https, an empty page with 0b - only gets 72/100 because of missing HTTP2 and slow TTFB of 185ms.Insights doesn't even render this page and it gets 83/100 from Pingdom. Faster than 99% of sites, 0B and still only 83/100. I think most of these metrics are a bit off...Edit: just amended my empty test page to be exactly 200 bytes and be real html. Insights: 100/100, Pingdom: 100/100, Netlify: 0/100 because 1067ms TTFB

评论 #13657078 未加载

mdekkers超过 8 年前

I read a rant about having to shift all my stuff to the "JAMStack", because what i'm doing is old fashioned or something, but I don't see how that will shave 73% off my load time. I also don't see how a static site generator is good for most of my sites, seeing that they extremely dynamic applications. Also, the site talking about big pages being bad is pretty big.

bobfunk超过 8 年前

Author here - cool to see our test on HN :)We made the backend for the test open-source - it's a very straight forward Go binary that we run in several data centers around the world.<a href="https://github.com/netlify/speedy" rel="nofollow">https://github.com/netlify/speedy</a>The test focus on global performance, which might not be relevant to everybody - but for ourself it really does! We have users all over the world and as we've been building out our product we've seen a pretty clear correlation between opening up a new PoP on our CDN, and starting getting clients from that region. The performance matters.For the article itself - it's obviously not as lightweight as motherfuckingwebsite.com! That said, the 4.2MB download number is just plain wrong. We're currently transferring 1.2Mb on a page load when caching is disabled (everything is gzipped), but the critical path contents (the HTML + CSS bundle) is 68.5kb and once that's loaded the page starts rendering.The lunr.js index is very nifty - click the looking glass in the corner to try out the instant search. It's of course cached between page loads.

评论 #13654998 未加载

supervill超过 8 年前

Lol you have to download a huge file first, so it only works IF you site is already very large

评论 #13655682 未加载