Smashing Magazine just got 10x faster(netlify.com)
netlify.com
Smashing Magazine just got 10x faster
https://www.netlify.com/blog/2017/03/16/smashing-magazine-just-got-10x-faster/
5 comments
The probability of hitting a slow asset and hitting the 1-percentile goes up as the product of the number of assets. With 30 independent requests, one has an 80 percent chance of hitting the 5% latency percentile. Ouch.
If your sites have lots of requests, you will have to use a CDN to get good TTVC (time to visually complete). Reduce request counts and pull in the 99.9 percentile latency numbers.
800ms is an engineering flaw used to make their statements more :bold: dramatic :bold:. I will probably downvote netlify posts from now on.
If your sites have lots of requests, you will have to use a CDN to get good TTVC (time to visually complete). Reduce request counts and pull in the 99.9 percentile latency numbers.
800ms is an engineering flaw used to make their statements more :bold: dramatic :bold:. I will probably downvote netlify posts from now on.
We do run our own CDN at Netlify, and that's what allow us to serve the actual HTML pages out of edge caches while handling atomic deploys and instant cache invalidation.
This matters less when you test from New York (where Smashing Magazine hosts their Wordpress version of the site).
Here's how the performance difference looks like for people in Melbourne:
https://tools.pingdom.com/#!/dbYpJA/https://www.smashingmaga... https://tools.pingdom.com/#!/exYLwO/https://next.smashingmag...
The most important part of this difference comes from Netlify delivering the complete initial HTML in less than 100ms compared to more than 2 seconds wait time for the initial HTML load on the Wordpress version.
I'm sure Smashing will see an noticeable uptick in engagement in many parts of the world due to this (it's an effect we've seen before).
(PS. Movable Type's approach was awesome, but the infrastructure around doing static deploys and full static builds was just not up to the task back then, and browsers were way more primitive, so you would end up needing a monolithic dynamic site for just about anything with some form of user interacion)
This matters less when you test from New York (where Smashing Magazine hosts their Wordpress version of the site).
Here's how the performance difference looks like for people in Melbourne:
https://tools.pingdom.com/#!/dbYpJA/https://www.smashingmaga... https://tools.pingdom.com/#!/exYLwO/https://next.smashingmag...
The most important part of this difference comes from Netlify delivering the complete initial HTML in less than 100ms compared to more than 2 seconds wait time for the initial HTML load on the Wordpress version.
I'm sure Smashing will see an noticeable uptick in engagement in many parts of the world due to this (it's an effect we've seen before).
(PS. Movable Type's approach was awesome, but the infrastructure around doing static deploys and full static builds was just not up to the task back then, and browsers were way more primitive, so you would end up needing a monolithic dynamic site for just about anything with some form of user interacion)
[deleted]
To repeat a comment I made too late to be seen in the CMS announcement thread yesterday:
I wish people would actually use open protocols instead of private APIs, at least in cases where both seem to be available.
As far as I can see, the only feature this needs that only github provides is pull requests – omitting those would still leave you with a useful CMS, and the information could also be communicated in, for example, branch names. That way, you could conceivably use any client you want to work on the repo. So instead of implementing Gitlab next, why not make it work with git?
This situation reminds me of email clients and libraries, many of whom now use private APIs of a bunch of providers instead of SMTL and IMAP.
I wish people would actually use open protocols instead of private APIs, at least in cases where both seem to be available.
As far as I can see, the only feature this needs that only github provides is pull requests – omitting those would still leave you with a useful CMS, and the information could also be communicated in, for example, branch names. That way, you could conceivably use any client you want to work on the repo. So instead of implementing Gitlab next, why not make it work with git?
This situation reminds me of email clients and libraries, many of whom now use private APIs of a bunch of providers instead of SMTL and IMAP.
Hi,
Netlify CTO here.
You're right, everything that the CMS does currently could also be done with raw Git messages. The CMS is designed to have pluggable backends. We had an early version working with Git directly. We decided to focus in one backend at a time rather than having several half integrated because the core features were evolving too fast to support several backends initially.
We plan on support raw Git in the future again. It's a matter of making sure it's useful for more people other than developers that already know how to use Git.
Netlify CTO here.
You're right, everything that the CMS does currently could also be done with raw Git messages. The CMS is designed to have pluggable backends. We had an early version working with Git directly. We decided to focus in one backend at a time rather than having several half integrated because the core features were evolving too fast to support several backends initially.
We plan on support raw Git in the future again. It's a matter of making sure it's useful for more people other than developers that already know how to use Git.
Awesome work dude, I am really impressed!
You need some kind of API layer to talk efficiently to Git with authentication, etc, from the browser, and GitHub has currently done the best job of building that.
We do have an open-source project for a REST API you can put in front of any git repository and would be happy to take contributions:
https://github.com/netlify/netlify-git-api
We do have an open-source project for a REST API you can put in front of any git repository and would be happy to take contributions:
https://github.com/netlify/netlify-git-api
A few days ago Smashing Magazine published this post on their transition: https://next.smashingmagazine.com/2017/03/a-little-surprise-...
Edit: The article points out that this is not just about switching to a CDN, but also about streamlining their publishing process:
In the past, we were using WordPress as a CMS, our job board was running on Ruby, and at one point we switched to Shopify from Magento for our online shop. Not only was maintenance of four separate platforms incredibly complicated, but designing a consistent, smashing experience the way we envisioned it proved to be nearly impossible due to technical restrictions or requirements imposed by these platforms.
Edit: The article points out that this is not just about switching to a CDN, but also about streamlining their publishing process:
In the past, we were using WordPress as a CMS, our job board was running on Ruby, and at one point we switched to Shopify from Magento for our online shop. Not only was maintenance of four separate platforms incredibly complicated, but designing a consistent, smashing experience the way we envisioned it proved to be nearly impossible due to technical restrictions or requirements imposed by these platforms.
Why is it newsworthy? Smashing Magazine is a static website. Putting it on a CDN is the most obvious, most efficient, and the cheapest optimization.
The whole thing reads like a Netlify ad.
The whole thing reads like a Netlify ad.
I agree that it feels like an ad campaign, especially since the CMS was on the front page recently.
The speed improvements could have been achieved without switching from WordPress, by installing a caching plugin with a CDN option.
The speed improvements could have been achieved without switching from WordPress, by installing a caching plugin with a CDN option.
If you read the article, you'll find that Smashing tried many different caching plugins for WordPress, and they all had problems.
It's also worth noting that Smashing Magazine is not just articles (and comments), but also a full E-commerce, job board, event page, ticket checkout and introduced a new membership section with subscriptions.
Obviously all of that can still be done with a static front-end today (and with one front-end instead of 4 different ones), but that's actually what's newsworthy and it's hardly what anyone would traditionally think of as a "static website" :)
Obviously all of that can still be done with a static front-end today (and with one front-end instead of 4 different ones), but that's actually what's newsworthy and it's hardly what anyone would traditionally think of as a "static website" :)
Show HN
It's a mistake to equivocate TTFB with being 10x faster for the user. It's clickbait. The vast majority of that speedup is not from using static files, but from putting the data on a global CDN (Amazon's Cloudfront in this case - Netlify didn't build their own.)
Put it this way: if you have caching, and a page on your site gets hit 1000 times, 999 times it's going to be as fast for the user no matter what the backend technology used is because it's not going to the backend. So if the first hit takes 800 msec against Wordpress, then the other 999 requests take 80 msec, then using the static file instead of Wordpress only makes it 1% faster, not 10x faster.
For the record, the new Smashing Magazine design is visually complete in about 4.5 seconds: https://www.webpagetest.org/result/170318_MY_PJ5/1/details/#...
The old one is visually complete in about 5.8 seconds: https://www.webpagetest.org/result/170318_T8_Q2D/1/details/#...
So, in both cases, time to first byte is a small fraction of how much time it takes for the page to look done to the user, and by no reasonable criterion should it be considered 10x faster now.
By putting their stuff on a decent CDN instead of whatever the heck "auslieferung.commindo-media-ressourcen.de" is, they made their page 25% faster. That's great! But it's bizarre to see something that is pretty much how Movable Type worked in 2002 as a breakthrough in web performance or technology.
The secret sauce here is using a global CDN, not being buzzword compliant. Setting up Varnish is not particularly hard. Setting up Cloudfront or another CDN is not particularly hard. You could do that and still use Wordpress, if that's what you like.