11–18 of 18 posts
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.
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.
https://github.com/netlify/speedy
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.
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
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. https://github.com/netlify/speedy 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…
1.2MB is still too much, even if it's deferred and compressed. For that, you should be blowing me away with your amazing multimedia blog post.
I'm on Firefox+Noscript, and it's 676k. That's more like it, and I don't feel like I'm missing anything, the least of which is that search index of your entire site.
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)
Lol you have to download a huge file first, so it only works IF you site is already very large
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 wha…
a) they're testing from within their network (bullshit). b) they purport that you'll get 6ms ttfb if hosted on netlify. Dishonest.
I've intentionally imported sites to remote hosts, and tested them there — they performed better away from netlify, and, netlify's speed testing tool gave them bad scores, despite them performing better than the same site hosted on netlify.
Oh well. They've got some nice tools, if it weren't for their fraudulent testing tool.