> > I will have to disagree on public CDNs being more reliable that private > ones. It's just mathematically wrong. > Public CDNs like cdnjs for instance will give an unstable bandwidth, > depending on the load they get, which you can't measure beforehand. > Owning your own high-end CDN guarantees you will have a constant bandwidth. >
Let's distinguish between three types of CDNs: (1) public CDN hosting existing open source projects, such as https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js, (2) public CDN hosting your own custom assets (e.g., your own Cloudflare account), (3) private CDN (i.e., build your own POP infrastructure, or use a service like Fastly <https://www.fastly.com/services/private-cdn>). When you refer to "private" and "owning your own," are you talking about #2 or #3? For #3, even though there is potential for better performance (depending on how "high-end" you go), there is also obviously going to be greater cost as well, so you have to consider the tradeoffs. Furthermore, even #3 may be slower than #1 for highly popular open source libraries such as jQuery, as in the case of #1, the resource is likely to be in the user's browser cache already due to a previous visit to some other website using the same public CDN. If you were comparing #1 to #2, it's not clear which would be faster (do you have some data?). For example, cdnjs is hosted by Cloudflare, so not sure hosting your own version of the asset on Cloudflare would necessarily beat cdnjs. > In terms of load speed, it's usually better to have one optimised bundle > than having to load multiple resources. > In terms of project management, it's also easier to manage one bundle than > handling vendors & private code separately. > I think niphlod agrees, but depending on your site and infrastructure, it may still be better to use public versions of a few highly popular libraries, such as jQuery and Boostrap (due to the likelihood of pre-existing copies already being in the browser cache, as mentioned above). > If you don't want to take my word for it, just have a look at big websites > around : they all resort to bundling. > Keep in mind that the most popular websites likely have their own private CDNs (which is cost effective for them, but probably not for your web2py site), and they may be popular enough that they would benefit little from pre-existing cached copies of libraries in the user's browser (because their own copy of the resource is just as likely to be in the browser cache as well). > > >> - dynamic assets: again, minification and bundling to a CDN are not >> really web2py's job but at most for a script. Use whatever you'd like >> > > Minification & bundling are not web2py's job, but versioning & caching > should be. > Well, generally it is likely to be faster to have the web server (e.g., nginx) serve the static assets directly, as web2py will add additional overhead. As long as web2py isn't handling the static requests, though, it can't handle caching, and it isn't clear it should be involved in versioning either. > - cache headers: use @cache.action: it's specifically coded for it >> > > Yes & no. > In Python, we tend to think explicit > implicit. > > @cache.action is a sweet helper, but it does everything implicitly so you > don't really understand or control what you're doing. > If "does everything implicitly" means you can't see everything the function does merely by looking at the function call, then this is true of virtually any function, and the notion that "explicit > implicit" becomes meaningless. Using any function requires some understanding of what it does and doesn't do (via reading the docs, inspection of the code, or observation of the output). > Practically speaking, I had to stray from it because it's lacking the > "Access-Control-Allow-Origin" header, which is mandatory for CORS > management. > @cache.action sets headers specfically relevant to browser caching, so Access-Control-Allow-Origin is out of scope. However, if you are using @cache.action, nothing prevents you from setting other response headers by the usual means -- you have just as much control over the headers with or without that decorator. I think it would be sweet if web2py could adapt to existing bundling > systems out there. > Here's how I managed using a manifest-based system in web2py : > I'm not sure this belongs in the core, as we don't want to have to worry about supporting any possible manifest format, but could be a useful contrib package. Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
