Have been working on a site and have used Boostrap via MAX CDN by putting
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css">
in the head section.
Google Pagespeed is showing:
Your page has 1 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.
Optimize CSS Delivery of the following:
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css
Is there anyway of fixing this?
Thanks
The other answer is too incorrect, so I am writing this if anyone still needs help on this.
CDNs speed up your production websites too, not only your local development environment. Hosting a static file locally on your own host does not solve the Render Blocking issue that pagespeed tool suggests here. A static file hosted locally is still render blocking.
The solution here is inlining the render blocking CSS files completely. However, I would recommend to not inline the resources for several reasons:
Resources delivered over CDN are delivered faster. If you inline them, the entire payload is expected to deliver at slow pace.
Resources delivered separately are cached by browser, while if you inline CSS resources browser will not be able to reuse them across requests.
Resources inlined are compressed on every request along with the other dynamic contents of the file. You cannot take advantage of pre-compression that comes with CDN.
Bigger HTML document due to inlined CSS files is expected to slow when it comes to parsing.
What should one do to resolve this issue? You might think differently, but I would suggest you to do nothing.
Its not that bad if the browser has to wait a little for resources to download. If you are using CDN, chances are visitors will not perceive the download as most of the CDNs now a days have less than 50ms average global latency.
Resources are cached by browser. While pagespeed tool loads fresh resources on every request, please note that browser may be loading some of the resources from cache, completely eliminating the CDN request.
Resources are shared across websites. If you are using Bootstrap from a public CDN, chances are that the same bootstrap file is already available in browser cache of the visitor, that is downloaded when the user visited another website that used bootstrap. This gives 0ms latency and 100% bandwidth saving for that particular resource for even your first time visitors that have no other resources of your site in their browser cache. Browser can now spend the saved bandwidth elsewhere to speed other things up.
Manually inlining external libraries make it little more difficult to keep traces of all inlined copies of the library and makes the edits and updates hard.
Dynamic inlining adds few more disk seeks per request. This just adds to the server load. These IOs can be saved if the files are served separately. Your OS may just cache the files if they are hot enough. Using CDN will completely eliminate this load.
Although not exactly a solution that will remove this pagespeed warning, its possible to reduce the impact of render blocking resources for real visitors (not performance measurement tools):
Serve resources with aggressive compression to reduce the payload size.
Serve resources with immutable cache-control header to tell the browser to confidently store this file for longer period as this is not going to change in the future. If you use bootstrap cdn by pagecdn, these two optimizations are enabled by default.
If you know a file is going to be loaded immediately after a page load, you can use HTTP/2 Server Push to deliver the file before even the browser asks for it. However, if you do this, you will need to make sure that the same files are not aggressively been pushed on every request (that is not a good option as the files should load from browser cache on second request onwards).
Either change the CDN (which will most likely do nothing for you) or, simply store the file locally. This will up your Google Page Speed rate.
Download a copy of the bootstrap file you are using and store it like so root/css/bootstrap.min.css
Where root is your project folder.
CDN's are used mainly for test purposes (instant access to files) or in larger-scale projects which have multiple requirements that can't always be met locally.
Read this thread to better understand.
While the error that Google gives you might not be a serious issue for your project, it is always a good practice to use your resources locally, so that your website may load by itself, without referencing external sources that resemble in a separate query.
Static files = better load times = happy Google.
Related
I trying to load a css library from github (not uploading to my server due limited bandwidth)
It keeps saying strict mime checking stuff is theres any workaround that i can get this working, without using any bandwidth from my server?
What you are asking for is CDN, github in it self is not a cdn and by design responds with plain text mime type which is why you getting errors etc. On top of that if you get frequent plain text request hits on repository then github takes it as something other then intended is going on and begins flagging things.
some cdn netwroks will allow you to turn github repo into cdn, they fetch and store code base on their server behind the scene.
Example (which I often use):
https://cdn.jsdelivr.net/gh/{username}/{repo}/
It will save your server bandwidth and also turn any github repo into cdn with adjusted mime type. Do keep on mind though since it would cached at CDN if you are making frequent changes to library they might not be updated in real time time lag could be anywhere from 5 minutes to 48 hours. You dont have control over this.
Secondly, now days if you use your headers right resources are vigorously cached by browsers (you have to work in it though) hence why we use hard refresh to purge/update cache.
I have single page web-app that currently consists of four files:
index.html
main.js
style.css
sprites.png
This means that every user who loads the site has to request index.html, parse it for the other three files, and then make three more http requests (serially, I believe) to fetch the remaining files.
It seems to me that it might be (a tiny bit) faster to embed the javascript, css and sprite image (base64 encoded) directly in the index.html file.
The main reasons I can think not to do this, along with my reasons why I don't think they apply in this case, are as follows:
Would prevent any of these additional files from being cached separately. This is not an issue for me because they will never be loaded from another page (since there is only one html page)
If the files were on different CDN servers, they could be downloaded in parallel. (Currently this project is not large enough to merit multiple servers)
I should disclose that this site is a small pet project that is no-where near large enough to merit this kind of meticulous performance tuning, but I like using pet projects as an avenue to explore problems (and their solutions) that I may face in my day job.
This isn't usually done because you increase the size of the entire HTML page. You'll save a couple requests on the first visit, but you'll force the client to reload everything every time they fetch the HTML file.
It would improve performance for users who visit your site once, and only once. For any kind of long-term strategy, it's unsuitable.
When your page is reloaded js, images, and CSS are cached on the client and doesnt need to reload. Also, base64 requires your clients to activate JavaScript to see your page. Lastly, it may very well take a weak client longer to decode your base64 than downloading the files.
So in short, dont overthink some things.
I assume that if you put some Javascript code in an external source (and use the src="") that it's a little slower b/c the page has to then download another portion, but I'm wondering whether that's inconsequential.
From testing I've done online (with webpagetest.org) seems quite small (< 5% of the total page time loading).
But just wondering about what's happening "under the hood" and whether the browser (I assume) is spinning up another process to download that bit separately rather than coming across from the server with the rest of the page is actually just as fast (b/c it's happening in parallel).
Not slow enough to matter.
I think the speed difference question is a red herring. Generally, you should keep your script separate from your html:
Separation of concerns: the html is the structure of the site, whereas the script is its behavior. It mixes concerns to mingle them together, and it's best practice to keep your script in a separate file.
It might seem counter-intuitive that script served separately from html could be just as fast or even faster, but things like caching proxy servers, content delivery networks, and even new web protocols like SPDY can make the speed question completely moot.
If you test in Firebug in Firefox you'll see that Firefox is downloading multiple files at the same time (the number of concurrent files is different for each browser). But the main reason why you should put js code in external files is that it can be minified and compressed on the server side, and also cached by the browsers. Loading it from an external file has also the benefits of being able to load it from a static domain (cookie less) and use a CDN to speed up the delivery. So to reply to your question it'll be slower to put it in the page as the browser will need to download it every time it loads the page.
I am a little slow to the HTML5 caching, I have just some simple questions though.
1) How long is data in a caching manifest cached?
2) If I update the data, how can I make sure the client checks for a newer version when it is available, or is this already done?
3) Also, is this completely useless for a non-0mobile environment or can it speed up load times on a desktop?
<html lang="en" manifest="offline.manifest">
offline.manifest
CACHE MANIFEST
index.html
style.css
image.jpg
image-med.jpg
image-small.jpg
notre-dame.jpg
1) As long as the user cares to cache it. The only way to completely get rid of the cache is to go into the browser settings and explicitly remove it.
2) If you update the manifest file, the client will download new versions of all the files. This download is still governed by 'old' HTTP caching rules, so set headers appropriately, also make sure you send a 'no-cache' header on the manifest file itself. The rules from HTML5 Boilerplate are probably a good place to start.
3) Remember desktops can lose connectivity too. Also, having files in application cache means they are always served locally so, providing you're sensible about what you put in it, the application cache can reduce bandwidth and latency. What I mean by sensible is: if most visitors only see a couple of pages of your site and you update the manifest of your entire site every week, then they could end up using more bandwidth if you're forcing them to cache a load of static files for pages they never look at.
To really cut down on bandwidth and latency in your HTML5 website of the future: use the application cache for all your assets and a static framework; use something like mustache to render all your content from JSON; send that JSON over Web Sockets instead of HTTP, saving you ~800 bytes and a two way network handshake per request; cache data with Local Storage to save you fetching it again, and manage navigation with the History API.
1) How long is data in a caching manifest cached?
Once an application is cached, it remains cached until one of the following happens:
The user clears the browser's cache
The manifest file is modified
The application cache is programatically updated
2) If I update the data, how can I make sure the client checks for a newer version when it is available, or is this already done?
you can specify witch files not to cache (NETWORK:)
If you want to update your cached files, you should modify something in the manifest file, the best way is to put comment in the file and change it when you want the browser to update the cache
3) Also, is this completely useless for a non-mobile environment or can it speed up load times on a desktop?
Yes it is useful, cause the internet can cut on all devices
I am making a web app that is database driven and am having a hard time trying to figure out a way to cache article pages.
I've thought of just doing a cfquery to loop through all the article IDs to give me a page path (e.g. /?page=article&article_id=#id#) but from what I know of html5 caching is that if anything changes in the manifest file it will download everything all over again.
If updateready keeps getting triggered does it slow down the page significantly?
It shouldn't slow things down too much, because all that should be happening in the background, but it's not really the best approach. The app cache isn't intended for storing dynamic data, it's much better for static content. I would recommend caching a container page and then load the content into it with AJAX/JavaScript. Use local storage to keep your data for offline use on the client side.