-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a boolean enabling CDN for faster&cheaper hosting #120
Comments
i would :P |
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 :) 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/ I suggest you read them, and if you still feel we should add the option, we can discuss pros and cons :) |
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. 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. 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:
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). |
Thanks for the very comprehensive answer! The arguments are solid, so lets do this :) I want to propose one change though: if See here for how to do this: https://gist.github.com/kevinwake/6204538 Eagerly awaiting your PR ;) |
Will be happy to do so, if nothing else it will make it easier for people behind firewalls/developping locally. |
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. |
well there is webfont.js could use something like: typekit/webfontloader#172 |
@unbrice any updates on this? |
This would be a great feature! Any updates ? |
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! |
While having Bootstrap CSS&JS bundled with the theme eases local development, it is suboptimal for a variety of reasons:
In my case, these files represent most of the weight of what a client has to fetch.
I would like to add a boolean option that when set to True make ressources be fetched from well-established CDN:
One could then set this boolean to True in publishconf.py to decrease cost and improve performances on the production site.
Is it something you'd accept to merge?
The text was updated successfully, but these errors were encountered: