
How to Shave 73% Off of Your Load Time (It’s Really, Really Easy) - AlaskaCasey
https://www.netlify.com/blog/2017/02/15/how-to-shave-73-off-of-your-load-time-its-really-really-easy/
======
aembleton
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\.
[https://www.netlify.com/js/lunr/PagesIndex.json](https://www.netlify.com/js/lunr/PagesIndex.json)

------
00deadbeef
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
I'm not impressed if you're making me download 4MB to see the 5kB of text in
this blog post.

------
caseydurfee
The webpagetest of the blog post is pretty telling:
[https://www.webpagetest.org/result/170215_26_MSDP/1/details/...](https://www.webpagetest.org/result/170215_26_MSDP/1/details/#waterfall_view_step1)

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
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
_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
Surprising result: news.ycombinator.com scored 0 out of a possible 100 points.

[https://testmysite.io/58a4993871e20a1fdab44dee/news.ycombina...](https://testmysite.io/58a4993871e20a1fdab44dee/news.ycombinator.com)

\-- edit - looks like time to first byte is what really kills scores

~~~
dsp1234
There is a 301 redirect from
[http://news.ycombinator.com](http://news.ycombinator.com) to
[https://news.ycombinator.com](https://news.ycombinator.com).

On a fresh VM, I get a TTFB on
[http://news.ycombinator.com](http://news.ycombinator.com) of about 200ms,
then another 200ms to retrieve
[https://news.ycombinator.com](https://news.ycombinator.com). So maybe it's
counting the TTFB of the final document.

~~~
slantyyz
As the speed test is going down its list of tests while you wait, you do see
an "https" check - so I don't know if that 301 has any impact. I do notice
that reloading the test yields varying results. I got as high as 11/100.

The dumb thing with the "Share your results" link is that that it appears to
rerun the test instead of showing you a snapshot of the result from that test
(so I guess it's not really sharing __results __, is it?).

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

------
wink
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

~~~
davidandgoliath
Netlify's testing site is fraudulent — yeah, I said it, let me know if you
need my legal contact.

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.

------
mdekkers
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
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](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.

~~~
theandrewbailey
> 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.

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.

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

~~~
pavel_lishin
I think either you're misunderstanding what static site generators do, or I'm
misunderstanding your comment.

