Add a boolean enabling CDN for faster&cheaper hosting about pelican-bootstrap3

[ingwinlu]

i would :P

[DonDebonair]

Let me start by arguing (as I always do) that I want to keep pelican-bootstrap3 as simple as possible. It already has a gazillion options, so I really think hard before merging yet another option :)
So when I look at this proposal, I try to see the value of it and try to determine if it's valuable enough to warrant yet another option added to the list of a gazillion options.

The problem with CDNs is that the likelihood of hitting the browser cache because of CDN usage, is greatly exaggerated most of the time. Because there are so many versions of (for instance) jQuery being used, and floating around, chances are small that the user actually has the exact same version of jQuery in its browser cache, as we require. I once read a blog article that actually measured the cache hits using a CDN for serving jQuery, and the chance was painfully small (somewhere around 5% or so). I can't actually find that article anymore (I have googled extensively, but no luck). I found two other articles that talk about CDN usage, and both raise some pretty valid points:

http://daemon.co.za/2014/03/from-trenches-js-cdn-point-of-failure/
https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/

I suggest you read them, and if you still feel we should add the option, we can discuss pros and cons :)

[unbrice]

Hi :-)

Thanks for this very interesting articles and this well though follow up.

To the first I have little to object: it is the case that setting the variable to true is adding another point of failure. As a side note I am very sensitive to the issue, being a Site Reliability Engineer.
On the paper it is a risk/benefit tradeoff, similar to the decision of relying on external services to generate the list of Github projects, or to handle comments (Disquss); (although it degrades less gracefully). A person having high availability requirements may want to set USE_CDN to false.
In practice I doubt it though: most people are hosting their website on non-redundant loosely connected webservers. If you already serve your website through a redundant set of geographically distributed servers the argument holds, otherwise you are order of magnitudes less reliable than the CDN already and the additional risk is negligible.

The second article is very interesting as well, it argues that SSL handshake will typically exceed transfer time especially since the CDN they tried did not support SPDY.
However most people are not serving their sites over SPDY using a patched Nginx. But anyway the recmmended CDN, MaxCDN (the one from the article actually!) added SPDY support since. This makes it best of both worlds.

You are right that cache hit likelihood is very low. I could not find that article that got 5% but I found this that reach even lower figures

So pro and cons of CDN seem to be:

• Minus: You cannot reuse the HTTP pipeline to the main server to fetch ressources, adding the delay of one more TCP handshake to load the files
• Minus: You add a point of failure wich might not be negligible if your are serving your blog from a high-availability system.
• Plus: Files are more likely to be close to the user reducing handshake times
• Plus: the CDNs support SPDY making reducing the number of handshake in comparison to most webservers
• Plus: More files can be fetched in parallel (6/server)
• Plus: Saves bandwidth on self-hosted/busy servers
• Plus: Certain popular hosting options (eg Amazon S3) don't compress files making the site slow on mobile

I am personally hosting my site using S3 so the Gzip support makes the tail latency better from a CDN for me (files go from 100k to 30k, making it much faster on mobile devices). Maybe I am biased but it does seem to me that the pro would outweight the cons as this papers over many "worst cases" situations, making the theme easier and cheaper to host (although probably not faster that served from a properly configured webserver using its owned CDN).
From this discussion, I would like to however amend my initial proposal: both jQuery and Bootswatch should come from the same CDN (in this case MaxCDN from code.jquery.com) to make the most of pipelining and add only one point of failure.

[DonDebonair]

Thanks for the very comprehensive answer! The arguments are solid, so lets do this :) I want to propose one change though: if USE_CDN is set to true (which, considering your arguments should be the default IMHO), it should load Bootstrap & jQuery from CDN (and any other resources that pelican-bootstrap3 uses, that can be loaded from the same CDN), but it should also test if they are properly loaded and fallback to local copies if the CDN failed.

See here for how to do this: https://gist.github.com/kevinwake/6204538

Eagerly awaiting your PR ;)

[unbrice]

Will be happy to do so, if nothing else it will make it easier for people behind firewalls/developping locally.
The fallback logic will handle the CDN being unavailable from the client but won't be hable to detect if it becomes unavailable while the page loads or is partially available (eg WOFF files fail to load)

[DonDebonair]

Yeah, it might be hard to test for success with loading FontAwesome from a CDN. The gist I mentioned, does provide a way to test for both jQuery and Bootstrap though.
It is less of a problem though, when FA fails to load from the CDN. The site will function, without the icons.

[ingwinlu]

well there is webfont.js

could use something like: typekit/webfontloader#172

[DonDebonair]

Good solution @ingwinlu! @unbrice are you still working on this?

[DonDebonair]

@unbrice any updates on this?

[dmsimard]

This would be a great feature! Any updates ?

[DonDebonair]

Hi!

First of all, thanks for your interest in this theme! It's with heavy heart that I have decided that I can no longer maintain this theme due to lack of time and changing interests. To makes sure the theme lives on however and not goes to waste, I've donated it to the Pelican community. It can now be found in the official pelican-themes repository. I'd suggest you re-submit your issue there.

Sorry for the inconvenience!