I am trying to optimize a small website, I am now looking into the CSS.
Let's take the example of index.php. I have first done it the standard way by adding <link rel="stylesheet" href="style.css"> in the <head> of my HTML output.
Google PageSpeeds then complains about the render-blocking files.
I then tried an alternative way and instead of the <link> tag above, I added this in the <head> :
<style>
<?php include 'style.css';?>
</style>
This effectively gives me an internal CSS while still having the convenience of having one file for all my pages. I do not have render blocking files anymore and PageSpeed seems happier.
Is there any significant drawback here? Should I be as happier as Google PageSpeed is?
Google's documentation for optimizing CSS delivery suggests only inlining small amounts of critical CSS. You'll find that caching techniques can reduce the parsing time required for including your CSS file. There will be a sweet spot where it's worth the maintenance cost.
You could look at installing the Page Speed module as well. Some more articles about PHP caching are below. You might also look at enabling compression for your static file transfers - that reduces the size for most text files significantly.
https://secure.php.net/manual/en/book.apc.php
https://medium.com/#dylanwenzlau/500x-faster-caching-than-redis-memcache-apc-in-php-hhvm-dcd26e8447ad
https://pantheon.io/docs/alternative-php-cache/
Related
Google Pagespeed test doesn't recognize preload when it is used together with stylesheet. I tried
<link rel="preload stylesheet" href="http://www.example.com/style.css" />
and it still shows "Consider using to prioritize fetching resources that are currently requested later in page load.". If I remove stylesheet from rel attribute, it recognizes the preload.
I was thinking to try this:
<link rel="preload" rel="stylesheet" href="http://www.example.com/style.css" />
but I am not sure if you can have 2 the same attributes for the same link tag. Would this work?
For loading CSS styles asynchronously, you should indicate it, as a preload stylesheet. Whenever you use rel="preload" alone, it won't transform to stylesheet on page load and it will remain as preload, so to indicate it as stylesheet you should use another attribute such as as which indicate the type of element and in your case, it should be style. Then you need to tell the browser whenever the loading process got finished you need to consider this as a stylesheet, so you have to define another attribute like onload and then define its real relation.
so you have to import it like this:
<link rel="preload" as="style" onload="this.rel='stylesheet'" href="http://www.example.com/style.css">
NOTE: You can read more about it here in google developers.
UPDATE
Since preload is not supported in firefox until now (according to this), the only way to do it, is to declare it twice in the one rel tag or two separate tags.
<link rel="preload" as="style" href="http://www.example.com/style.css">
<link rel="stylesheet" href="http://www.example.com/style.css">
Or
<link rel="stylesheet" rel="preload" as="style" href="http://www.example.com/style.css">
NOTE: As #JohnyFree tested the second one (one with a line through) in the Google page speed, it won't be recognized as valid preload style, whilst the format is valid according to W3.org.
preload https://web.dev/defer-non-critical-css/
<link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'" href="http://www.example.com/style.css"/>
fallback for not supported browsers https://www.filamentgroup.com/lab/load-css-simpler
<link rel="stylesheet" media="print" onload="this.media='all'" href="http://www.example.com/style.css"/>
If you feel you need to do this Javascript circus trick to save a few hundred milliseconds, I recommend the version below. Use it instead if you want cross-browser support:
<link media="print" onload="this.media='all'" rel="stylesheet" type="text/css" href="style.css" />
Why does this work? In nearly all browsers going back to the 1990's, support of linked "print" media type style sheet was universally supported. Linked print style sheets were only used when printing pages. Because browsers knew the "sheet" media type must always be downloaded before "print", they often delayed or downloaded sheets with "media=print" asynchronously. Nothing was needed by the page author. It has worked this way for many years in most browsers, naturally.
Recently, developers trying to follow Google's new ranking policies discovered this trick to stop some styles from blocking others or from downloading immediately. They then realized the "print" media type was the only built-in, cross-browser way to fool browsers into delaying downloading of style sheets.
Turning your style sheet into a "print" type using the trick above doesn't mean its "print", as the script later changes it back to "all". It is simply a "hack" or way to prevent modern browsers from downloading your CSS styles in parallel with other sheets.
Note: "all" is not supported in a wide range of older browsers including Internet Explorer versions 1-7, so a bad idea, anyway.
Stopping one or two style sheets from blocking another sheet from downloading would be the only reason to use this trick, and assumes you are using a HUGE style sheet that is 50+ kilobytes in size and use a server with slow connections.
RECOMMENDATIONS?
I recommend you do NOT ever "preload" CSS for the following reasons!
Just because Google flags this as an issue in Lightspeed, doesn't mean filling your webpages up with duplicate style links and elaborate JavaScript hacks to shave off a 100 milliseconds is a good idea. You should care more about the quality and integrity of your HTML pages above all other concerns, including speed or advertising-driven search engine demands!
There could be racing issues! What happens when your HTML downloads before your async "print" sheet resolves itself back to "all"? You may see a flash in some browsers where the HTML downloads first and rendering begins before the async styles are downloaded. Your user then sees your website layouts and fonts move or shift. Nasty!!
Async'ing CSS is kinda pointless compared to these poorly designed Javascript frameworks kids are downloading in 2021 that waste download times anyway. Most style sheets are 50 kilobytes or less in size compared to the MASSIVE 500-1500+ kilobytes most modern Javascript frameworks shove into the browser today (ie. React, Angular, Ember, etc.). These downloads often "embedd" the same CSS over and over into the browser's cache anyway, forcing a reload of the same CSS each site visit unlike CSS linked styles which can be cached for months! So preloading linked CSS makes no sense if its reloaded every visit. So what is the point?
Many browsers may crash and burn with this trick! The preload is not widely adopted anyway, so you run a huge risk in a percentage of your users
seeing an unstyled web site if you use this "hack". Imagine 5%-10% of your users seeing your website displayed in the default 'Times Roman' font and a white block-level, unstyled content page because you wanted to save 500 milliseconds of download time? Sorry, not worth the risk!
Most old browsers had only 2 open connections allowed when downloading files, so they were limited by open connections, not style sheet downloads. Many modern browsers have 6 maximum. So again, connections are the bottleneck here when combined with multiple open JavaScript calls, not style sheet downloads. So little is gained using this trick.
Slow Servers are Often the REAL Bottleneck: Server delays on opening connections on the server can be huge bottlenecks. Even if your host provider or web application like Wordpress is using cached images, pages, and proxies but your waiting hundreds of milliseconds for a connection to open up on the server, all that becomes meaningless. CDN's can also fail, be delayed, blocked, etc., too.
The number one factor delaying downloads, besides slow servers and giant JavaScript API libraries, is more often huge image files. Consider using new HTML5 'picture' elements with multiple image types like "WebP" that are highly compressed. If you page has "on-demand", non-streaming video, that also must be set to preload or download asynchronously. Adding "width" and height" values to force 'alt' attribute placeholders, as images download will create reserved dimensions in your page layouts so they don't shift waiting images to download. You will be amazed at the savings in download times and bottlenecks prevented when you focus on image and media issues, not CSS.
All that makes preloading CSS pretty worthless as far as website improvements. I would go look at the multiple Bootstrap, JavaScript modules, and JQuery file downloads stacked up in your browser grabbing limited, shared browser connections and focus on less scripts. 30 or so kilobytes of CSS will likely not be the issue.
Firefox has supposedly enabled "preload" in version 85, but it doesn't seem to work correctly. What I found that this code below works:
<link rel="preload stylesheet" as="style" href="style.css">
I imagine this has been asked time and time again, but i've not seen the answer I'm looking for.
Im doing some simple tests with a HTML file and CSS file trying to stop the page from render blocking the CSS, running the site through page insights ( google )
Now i've seen answers like this:
<link rel="stylesheet" href="style.20180530.css?ver=1.0" media="none" onload="if(media!='all')media='all'">
and I've seen answers like this:
<link href="https://fonts.googleapis.com/css?family=Roboto:300,700" rel="preload" onload="this.rel='stylesheet';this.removeAttribute('onload');" as="style">
Both of which I am fine with, for the google fonts! But not for the main styles of the page, I don't think its a good user experience to see a page with no styles and then all of a sudden they load in.
Obviously you can eliminate any blocking of CSS by sticking the whole lot as inline styles, but again I don't think this is good practice, you're outputting all styles to a HTML page and not loading them via a style sheet.
I've seen sites actually load the styles like so:
<link rel='stylesheet' id='main-css' href='./style.2018052108.css?ver=4.9' type='text/css' media='all' />
Heres a link to the page insight speed test on the. I know the site is running wordpress. If you view page source it uses the exact same as i've used above.
And they aren't Render Blocking at all... How?
Im on a https I'm using cloudflare and my style sheet is compressed and only around 24bytes and I'm still getting render blocking.
Why?
How to avoid it?
The CSS loaded as an external request is always render blocking, you can't avoid it. The recommendation on pagespeed insights is that you don't do any css request before the content is loaded, in order to avoid the unstyled effect they suggest that you inline the CSS needed to display the content before the fold.
The page on your example is doing exactly that, they inline some css content (check the source code and search for the style tag), then, when the content is loaded they add an external stylesheet with javascript.
All that said, this is a recommendation, you can ignore it if you are happy with the performance of your page, if you want to follow the recommendation you can apply some techniques to achieve this in an automation way.
As always, in css-tricks you have a great introduction post to these techniques: https://css-tricks.com/authoring-critical-fold-css/
The key to the Google PageSpeed insights is above-the-fold render blocking. If you check the site that you linked as your page speed test reference, there are no strictly inline styles - you are correct. However, they have a <style>...</style> block inside of their <head> that sets all of their most important styles for above-the-fold content. That means those styles render immediately, and all other supporting styles will load soon after - but your visitors (and Google PageSpeed) will not notice the difference.
I have a static only site which is hosted on Google App Engine. Infront of this sits Cloudflare CDN.
I have ran Googles Page insights to give me an idea how my website is performing, it is not performing well according to Google. I want Google to see it is performing well for SEO purposes.
This is the report I get from Google:
2 types of recommendations come:
1) Eliminate render-blocking JavaScript and CSS in above-the-fold content
Show how to fix
2) Leverage browser caching
For problem 1 I have tried many things I have read on Google. I have tried adding 'aync defer' to the link attribute. I have tried to make the media = print so that the browser would first render the html then apply the css later. I have tried moving the links to the stylesheets into different locations around the html document. Essentially I have tried to follow this: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery.
As of right now my html page (my website is just on static html page) structure looks like this:
<html>
<head>
<!-- all links/references to css files and javascript files -->
</head>
<body>
</body>
</html>
My second issue is browser caching which I do not understand why I am getting this error. Google App engine caches the files and then on top of that Cloudflare CDN sets the cache headers (and also gzip) on the documents so that the browser caches it (below is the Cloudflare caching components turned on).
I can see the browser is caching the static files and using those cached files in chrome tools when I run the page:
This is really the first time I have created a production static website so I may be misunderstanding many things, but I am looking how eliminate those 2 issues.
Cheers
I don't know if google is measuring this but it is often advised to load Bootstrap and Jquery from the following addresses as they are used by a lot of website and hence are already in browsers caches even if they never visited your website. (The same can certainly be found for font-awesome).
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/YOUR_BOOTSTRAP_VERSION/css/bootstrap.min.css">
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/YOUR_BOOTSTRAP_VERSION/js/bootstrap.min.js">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/YOUR_JQUERY_VERSION/jquery.min.js"></script>
I tested my wordpress website on Google Page Speed Insight and it scored a 95/100. It suggested that I should "Optimize CSS Delivery" of 1 css file:
<link rel="stylesheet" type="text/css" href="<?php echo get_stylesheet_uri(); ?>" />
Right now it's sitting in the footer along with all the javascript codes below it. I moved it back between the head tag and same results. How do I optimized the css delivery of the css file?
In the case of a large CSS file, you will need to identify and inline the CSS necessary for rendering the above-the-fold content and defer loading the remaining styles until after the above-the-fold content.
Taken from: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery
Its not best to actually put all the css together. You should call first the styling that is needed for the rendering and afterwards call that big stylesheet of yours.
And if you want to know how to defer stylesheets well this is how:
CSS delivery optimization: How to defer css loading?
Hope i got you covered :)
95/100 is a great score. You're at the point where more work to hit 100 is going to give you diminishing returns compared to the effort involved with getting there.
But if you're dead set on approaching 100/100 you'll need to remove the above the fold CSS from the file and include it in a <style> block within your theme. Then you can hold off on loading the CSS file until the rest of the page has loaded and it will no longer be render blocking.
Here's some info I wrote on handling above the fold CSS with the WordPress Autoptimize plugin including a JavaScript bookmarklet to get you started with finding your above the fold CSS.
Note: You should be using the wp_enqueue_style() function to include that script, rather than include it directly in the footer. Check out this article on my website to see how to enqueue scripts and styles properly.
So I am wondering whether it is better for me as far as page speed, to precompile my less style sheets instead of using less.js. After testing this via google page speed, I noticed I actually went down a couple points after precompiling. As far as i know it should be less demanding on the user. But I guess I am wrong? Is there something else I should take into account? Minifying the css is also an option, but I don't think that will make a considerable difference.
Thanks.
I think you should change the title of your question in something like "does precompiling Less generates a better page speed score?"
If probably depends of the size of your Less code. In general page speed wants that you first load something readable and load non critical CSS and JavaScript afterwards.
When you compile all your Less code in one big CSS file, page speed will complain that you should load the critical CSS first (preferred to do that in source (no extra http request) ).
When compiling client side with less.js the compiled CSS code is inserted in source, but require two http request (the compiler and the less file). Less code can be smaller than the compiled CSS. But you will have to load the compiler (possible from CDN).
But overall you should realize that the client side compiler have to compile your Less code again for every page request. Client side compiling will take time and so create a bad user experience in most situations.
Minifying the css is also an option, but I don't think that will make a considerable
difference.
Minifying reduce the number of bytes that have to be send and so always helps to make your website load faster.
some tests
When i load a simple page with:
<link href="css/bootstrap.min.css" rel="stylesheet">
I found a page speed score of 95/100 and have to fix:
Optimize CSS Delivery of the following:
http://example.com/css/bootstrap.min.css
When i load the same page with:
<link rel="stylesheet/less" type="text/css" href="less/bootstrap.less" />
<script src="//cdnjs.cloudflare.com/ajax/libs/less.js/2.0.0/less.min.js"></script>
I found a page speed score of 91/100 and have to fix:
Remove render-blocking JavaScript:
http://cdnjs.cloudflare.com/ajax/libs/less.js/2.0.0/less.min.js
Although the second situation has to do many http request (to load all the less code) and run the code client side the score is not so much lower (and still good enough).
When you don't optimize the CSS in the first situation, for instance minify the code and set proper caching headers and so on the page speed score will further go down.
So in summary, yes you should precompile your Less code and minify the CSS code for a better user experience and page speed is not always a good predictor for the user experience.