Matt Mower posted a gist explaining how to self-host AMP framework.
One of the benefits he counts is:
serve AMP pages and the framework from the same host, potentially improving content delivery times.
Before reading this, i thought there isn't a difference in performance, because HTML is served once from my server, then async calls transfer the AMP framework files from official CDN. If self-hosted, AMP framework files will still be served almost the same way, but from my server. So how is self-host AMP framework perform better?
Keep in mind that, while the AMP libraries are loaded asynchronously, the AMP runtime (v0.js) is still render-blocking for your pages (this is done on purpose using the AMP CSS boilerplate which hides the page content until the runtime loads).
Assuming your server supports HTTP/2, hosting the runtime alongside your website allows you take advantage of request multiplexing and avoids connecting to a different server (the AMP CDN) which normally adds DNS lookup and connection overhead.
However, there are disadvantages to self-hosting the framework:
Your pages become invalid AMP (this will change in the future).
AMP's CDN is globally distributed and very performant - if you don't use a similar quality CDN yourself, CDN performance may outweigh the advantages introduced from hosting the runtime on the same server as your website.
Browsers may have cached the AMP runtime served from the AMP CDN if you previously visited another AMP website (this doesn't apply to browsers with a double-keyed cache like Chrome).
Bottom line is, if you're aiming for higher performance on AMP pages, it's best to start with the tips outlined in How to make AMP even faster and implement server-side rendering. Self-hosting the framework may yield additional performance benefits, but for most websites this is likely negligible.
Related
We have a large SPA in backbone and Angular that calls out to a set of Java APIs for a financial system with a large number of users.
One person said:
Switching on http/2.0 will have a massive different for our users in terms of page load time due to the nature of the protocol.
Another person said:
Browsers like Chrome are actually pretty good even without http/2.0. Switching it on won't make a noticeable different to the end user.
We made the change, and measured static page load times before and after the change. We didn't see a difference over 48 hours of data each before and after the change. (By both browser tests, and getting logging data on page load times forwarded to the application from the browser in our logs.)
My question is: Is the improvement from switching on http/2.0 in Cloudfront for an SPA noticeable for the average user of a large site during bootstrap?
Way too vague a question to answer I’m afraid.
Some of the things to consider:
Is your site super optimised with HTTP/1 performance issue workarounds (e.g.
concatenation, spriting, sharding) that HTTP/2 (which looks to remove the need for those) provides no real noticeable performance benefits?
Is your site so full of crappy JavaScript that HTTP downloads (which HTTP/2 looks to make more efficient) are a tiny and almost unnoticeable part of the performance problem in the grand scale of things?
Is your site bandwidth bound (e.g. full of print quality images) so that bandwidth rather than HTTP queuing is the problem?
Is your backend and/or web server so sucky that it takes a long time to generate your pages so again the HTTP transfer part is a tiny, almost unnoticeable part of the problem?
Is your site a really small site with just one HTML page and one JavaScript load?
Could your site be more optimised for HTTP/2 (e.g. hosting everything on a single domain, potentially using HTTP/2 Push...etc.) to allow you to get more performance than you could out of HTTP/2?
All of these things could impact whether switching to HTTP/2 makes a noticeable difference or not. Google found that a sample of sites get a 27%-60% performance improvement for SPDY (that HTTP/2 is based upon), but it really does depend on the site in question.
Ultimately HTTP/2 aims to make downloading many assets more efficient as this is inefficient under HTTP/1 - and particularly on low latency conditions. If you don’t have many assets, or downloading those is not a problem then HTTP/2 then you may not notice much difference.
I’ve a blog post to help show the problems in HTTP/1 that HTTP/2 looks to address (including analysing a real world example - Amazon.com) which may help you look at your site for the same potential issues (full disclosure it’s part of a book I’m writing on the subject).
We're currently doing optimizations to our web project when our lead told us to push the use of CDNs for external libraries as opposed to including them into a compile+compress process and shipping them off a cache-enabled nginx setup.
His assumption is that if the user has visits example.com which uses a CDN'ed version of jQuery, the jQuery is cached that time. If the user happens to visit example2.com and happen to use the same CDN'ed jQuery, the jQuery will be loaded from cache instead of over the network.
So my question is: Do domains actually share their cache?
I argued that even if it is possible the browser does share cache, the problem is that we are running on the assumption that the previous sites use the same exact CDN'ed file from the same exact CDN. What are the chances of running into a user browsing through a site using the same CDN'ed file? He said to use the largest CDN to increase chances.
So the follow-up question would be: If the browser does share cache, is it worth the hassle to optimize based on his assumption?
I have looked up topics about CDNs and I have found nothing about this "shared domain cache" or CDNs being used this way.
Well your lead is right this is basic HTTP.
All you are doing is indicating to the client where it can find the file.
The client then handles sending a request to the CDN in compliance with their caching rules.
But you shouldn't over-use CDNs for libraries either, keep in mind that if you need a specific version of the library, especially older ones, you won't be likely to get much cache hits because of version fragmentation.
For widely used and heavy libraries like jQuery you want the latest version of it is recommended.
If you can take them all from the same CDN all the better (ie: Google's) especially as http2 is coming.
Additionally they save you bandwidth, which can amount to a lot when you have high loads of traffic, and can reduce the load time for users far from your server (Google's is great for this).
I've just added a CDN distribution using Amazon Cloudfront to my Rails application on Heroku, it's working OK.
My homepage serves around 11 static assets, I've made some tests using http://www.webpagetest.org/ and there are no differences (in terms of performance, optimizing load times) between using the CDN or not.
Is there any particular reason why this could be happening?
My region is Latin America btw, so it's using the All locations edge option.
Thanks.
The main benefits of using CDN from Amazon or others is that they are hosted on fast and reliable servers and offload the traffic served directly from your server, which in case that you have a dedicated fast server you won't see a considerable boost.
But another benefit is that they are potentially cached by user's browser (due to visiting other websites which have used the same CDN) so the visitor will have a better experience first time they visit your site.
A couple of suggestinos.
If the site CSS is one of the static assets that you have moved to CloudFront then I would try moving it back to your main server.
Since page display can't start until the site CSS is downloaded, you want to serve this as fast as possible. If it's coming from a CDN then it requires a second HTTP request.
Also, use the waterfall display from webpagetest.org to pinpoint where the bottlenecks are.
Good luck!
I was studying about browser performance when loading static files and this doubt has come.
Some people say that use CDN static files (i.e. Google Code, jQuery
latest, AJAX CDN,...) is better for performance, because it requests
from another domain than the whole web page.
Other manner to improve the performance is to set the Expires header
equal to some months later, forcing the browser to cache the static
files and cutting down the requests.
I'm wondering which manner is the best, thinking about performance and
if I may combine both.
Ultimately it is better to employ both techniques if you are doing web performance optimization (WPO) of a site, also known as front-end optimization (FEO). They can work amazingly hand in hand. Although if I had to pick one over the other I'd definitely pick caching any day. In fact I'd say it's imperative that you setup proper resource caching for all web projects even if you are going to use a CDN.
Caching
Setting Expires headers and caching of resources is a must and should be done 100% of the time for your resources. There really is no excuse for not doing caching. On Apache this is super easy to config after enabling mod_expires.c and mod_headers.c. The HTML5 Boilerplate project has good implementation example in the .htaccess file and if your server is something else like nginx, lighttpd or IIS check out these other server configs.
Here's a good read if anyone is interested in learning about caching: Mark Nottingham's Caching Tutorial
Content Delivery Network
You mentioned Google Code, jQuery latest, AJAX CDN and I want to just touch on CDN in general including those you pay for and host your own resources on but the same applies if you are simply using the jquery hosted files cdn or loading something from http://cdnjs.com/ for example.
I would say a CDN is less important than setting server side header caching but a CDN can provide significant performance gains but your content delivery network performance will vary depending on the provider.
This is especially true if your traffic is a worldwide audience and the CDN provider has many worldwide edge/peer locations. It will also reduce your webhosting bandwidth significantly and cpu usage (a bit) since you're offloading some of the work to the CDN to deliver resources.
A CDN can, in some rarer cases, cause a negative impact on performance if the latency of the CDN ends up being slower then your server. Also if you over optimize and employ too much parallelization of resources (using multi subdomains like cdn1, cdn2, cdn3, etc) it is possible to end up slowing down the user experience and cause overhead with extra DNS lookups. A good balance is needed here.
One other negative impact that can happen is if the CDN is down. It has happened, and will happen again. This is more true with free CDN. If the CDN goes down for whatever reason, so does your site. It is yet another potential single point of failure (SPOF). For javascript resources you can get clever and load the resource from the CDN and should it fail, for whatever the case, then detect and load a local copy. Here's an example of loading jQuery from ajax.googleapis.com with a fallback (taken from the HTML5 Boilerplate):
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.8.2.min.js"><\/script>')</script>
Besides obvious free API resources out there (jquery, google api, etc) if you're using a CDN you may have to pay a fee for usage so it is going to add to hosting costs. Of course for some CDN you have to even pay extra to get access to certain locations, for example Asian nodes might be additional cost then North America.
For public applications, go for CDN.
Caching helps for repeated requests, but not for the first request.
To ensure fast load on first page visit use a CDN, chances are pretty good that the file is already cached by another site already.
As other have mentioned already CDN results are of course heavily cached too.
However if you have an intranet website you might want to host the files yourself as they typically load faster from an internal source than from a CDN.
You then also have the option to combine several files into one to reduce the number of requests.
A CDN has the benefit of providing multiple servers and automatically routing your traffic to the closest location to your client. This can result in faster delivery, optimized by location.
Also, static content doesn't require special application servers (like dynamic content) so for you to be able to offload it to a CDN means you completely reduce that traffic. A streaming video clip may be too big to cache or should not be cached. But you don't neccessarily want to support that bandwidth. A CDN will take on that traffic for you.
It is not always about the cache. A small application web server may just want to provide the dynamic content but needs a solution for the heavy hitting media that rarely changes. CDNs handle the scaling issue for you.
Agree with #Anthony_Hatzopoulos (+1)
CDN complements Caching; also in some cases, it will help optimize Caching directives.
For example, a company I work for has integrated behavior-learning algorithms into its CDN, to identify and dynamically cache generated objects.
Ordinarily, these objects would be un-Cachable (i.e. [Cache-Control: max-age=0] Http header). But in this case, the system is able to identify Caching possibilities and override original HTTP Header directions. (For example: a dynamically generated popular product that should be Cached, or popular Search result page that, while being generated dynamically, is still presented time over time in the same form to thousands of users).
And yes, before you ask, the system can also identify personalized data and very freshness, to prevent false positives... :)
Implementing such an algorithm was only possible due to a reverse-proxy CDN technology. This is an example of how CDN and Caching can complement each other, to create better and smarter acceleration solutions.
Above those experts quotes, the explanation are perfect to understand CDN tech and also cache
I would just provide my personal experience, I had worked on the joomla virtuemart site and unfortunately it will not allow update new joomla and virtuemart version cause it was too much customised fields in product pages, so once the visitor up to 900/DAY and lots user could not put their items in their basket because each time to called lots js and ajax called for order items takes too much time
After optimise the site, we decide to use CDN, then the performance is really getting good, along by record from gtmetrix, the first YSlow Score was 50% then after optimise + CDN it goes to 74%
https://gtmetrix.com/reports/www.florihana.com/jWlY35im
and from dashboard of CDN you could see which datacenter cost most and data charged most to get your improvement of marketing:
But yes to configure CDN it has to be careful of purge time and be balancing numbers of resource CDN cause if it down some problem you need to figure out which resource CDN cause
Hope this does help
My scenario:
There's a blog that runs on Blogger, and that's also where it's hosted. Afaik, "external" (js) files cannot be hosted on Google's servers.
When it comes to including popular JS frameworks (e.g., jQuery), there are several CDN options at our disposal.
Looking for a jQuery-based Lightbox replacement for a blog, I've stumbled upon ColorBox; no plans to have a CDN for it though.
So far, when it comes to including/hosting the files under the given constraints, I've noticed the following suggestions/solutions:
Including the minified version of the code inline in the Blogger template -- 9KB worth of JS code in a <script> element.
Linking directly to the github raw version -- e.g., v1.3.16. (unreliable availability?)
Considering load speeds and availability what is the best practice for this scenario?
Based on what you describe, I don't see much benefit to not including the code in the Blogger template. It's arguably small enough that anyone not sucking their internet through a straw will not notice the increased time to download the page source, and it will certainly be faster overall than loading from a remote server, so it looks like the only likely performance hit is that you might have decreased responsiveness (time until the user can interact with the page), but it should only be noticeable if the user happens to have an especially narrow connection.
So, you'll have to consider your users, but unless an extraordinary number of them have narrow connections, just include the code inline.