I am using google's audit and its tells me to remove unused CSS. I don't know if that css is for just that page or the whole site. The CSS might be there but not needed on that page but another page. Can someone tell me how this works?
It is telling you to remove unneeded CSS for that page.
However you have rightly pointed out the flaw in this suggestion as it only takes into account the current page (in it's initial state, obviously if you have a pop-out menu it won't gather the CSS for that).
Think of it more as a guideline of making sure you don't send the whole of Bootstrap just for the grid and column layouts for example.
Overall this is very difficult to fix, just use the coverage section on the performance tab in Developer tools to make sure you don't have any massively bloated CSS files and you will be fine.
Obviously reduce your unused CSS if it is easy to do so.
The only other thing that this point covers (in it's description, not as part of it's monitoring) is deferring non-essential CSS.
You should defer any Style Sheets that are not required for rendering 'above the fold' content (and inline your 'above the fold' CSS).
This point is also covered in 'Eliminate Render Blocking Resources' so I never quite get why they add the suggestion under this part as well but I have added it for completeness.
I find this rule was good at guiding me when designing a theme from the ground up as it made me seperate global CSS and page CSS more effectively.
Unless your site is scoring 98 / 100 (or you have hundreds of kilobytes of CSS) and you want to squeeze that last little bit of performance out of the site, simply minify and combine your CSS files and ignore this point.
Google's audit tool compares the entire stylesheet against the current URL and then tells you how much of it is actually not used by the browser.
The browser however still needs to download the entire file and then match all CSS selectors that apply to the current URL.
There are many ways to deal with this, but I find it the easiest to use an external API tool like Splitcss that does this for you on URL basis.
If you have only a few URL patterns in your web application, you can use some CLI tools like purgecss or uncss.
Related
I am working hard to imporove page speed. I am using Critical Path CSS Generator tool to identify above-the-fold CSS. Then I inline critical CSS as suggested, and load the full css asynchronously.
But I end up with a lot of duplicate CSS that way, which is not so optimal. So my question is:
How to remove critical CSS from the main.css file?
Thanks in advance.
While it may seem like an anti-pattern, all above-the-fold CSS you inline into your document SHOULD be duplicated in your external CSS document. That way, you can make a single site-wide bundle that can be fetched once for your entire site, but that initial page load will be accelerated. While this does result in extra "wasted" KBs upfront, the advantage is that you have a small subset of the necessary CSS available to you as soon as the HTML is sent to the client, reducing the time it takes to render the client's initial view.
Also, to be clear, if you're following this practice correctly, every page on the site will have a different set of above-the-fold css, because every page has different content/tags above-the-fold which would make it impossible to remove the above-the-fold CSS from the full external file (assuming you're concatenating all CSS into one file).
You can read more about the practice of above-the-fold css here.
If you're really concerned about code duplication (though you shouldn't be in this case), you can use cookies to keep track of whether or not a user has visited the site before. If the user has not been before, then you can inline the above-the-fold CSS. If the user has been before, you can assume that the user already has the full CSS file and that the CSS file will be pulled from the browsers cache.
There are a bunch of articles on how unreliable the browser cache is, so my recommendation is that you simply do what you're already doing to satisfy client requirements.
Another thing that should be mentioned is that this practice will largely go away once HTTP/2 becomes more prevalent as subsequent HTTP requests won't be nearly as expensive as they are today. Considering the intensive tooling/effort this practice requires (especially when future proofing against HTTP/2), it may be better (I think it is) to just avoid it completely.
did you run an audit in browser before going to pageSpeed insights
there you can see suggestions to remove unused css rules and inline performance.
be sure to write whole style at the starting of page and avoid these tags in between the page which affects perfomance
and importantly, inline should be for thumbnails but not for styling the page
example:
<p style="padding:2px">something to have some padding</p>
Would it be possible to optimize for the critical rendering path (similar to what Google and Facebook are doing) if I am using Bootsrap 3?
Facebook just inlined the styles that are related to the header and sidebars.
Google inlined all the styles because they do not have much styles for the homepage.
The issue here is that let's say I want to inline styles related to my header, it would consist of over 10 classses used from bootstrap (container-fluid, row, col-lg-10, col-lg-offset-2, etc..).
And inlining bootstrap is a bad idea because it is over 100kbs
I want to load above the fold content, really quick.
Is there a smart way of doing it? Do you have any recommendations?
This technique is independent of your framework, Bootstrap in this case.
You have to come up with a way to figure out your critical CSS which you can extract and inline into your HTML file.
There are many ways to do so:
Custom critical CSS file (created manually)
Type annotations in your CSS file, which could be extracted on compile/build time: https://css-tricks.com/annotating-critical-css/
Automated using headless browser like Puppeteer
This topic is way too big to answer in a short thread so feel free to read up on the topics listed above:
https://web.dev/extract-critical-css/
Tools:
Critical
criticalCSS
Penthouse
I wouldn't start doing in-line styles just yet, there are many optimisations that can be done before you'd ever need to go down that route. Plus there is a massive trade off, performance of the duplicated styles in the HTTP request (could be a double edged sword) and a maintenance nightmare.
Load CSS in head.
Load JS at end of body.
Customize bootstrap to only include the minimum required styles.
http://getbootstrap.com/customize/
Bundle & minimize your header related files in a separate bundle, think about segregating bootstrap components. Bundling gives caching and minification.
Single paged application, be smart about your initial load page and use modules/web components to ajax in templates of html.
Use CDN's as there are maximum http connections per host.
More can be found at https://developer.yahoo.com/performance/rules.html
Short answer is that you shouldn't have to add extra inline code for performance reasons. Your best bet to minimize loading time would be (as suggested above) to use the bootstrap customiser to remove whatever classes you won't be needing and also minify and gzip (if possible) before sending. Most of the times you'll need a lot less than the 100kbs bootstrap css.
However, rendering the elements in the browser is more costly than applying classes to them. You can only minimize load times up to a point.
You haven't told us what kind of performance you expect; but if it was a life-or-death kind of situation to super extra fast load the header, yes you should use inline code.
We all know that we're supposed to combine our CSS into one file, but per site or per page? I've found pro's and cons to both.
Here's the scenario:
Large site
CSS files broken out into one file for global styles and many for modules
Solution A: Combine ALL the CSS files for the whole site into one file:
Best part is that the one file would be cached on every page after the initial hit! The downside is that naming convention for your selectors (classes and id's) becomes more important as the chance for a namespace collision increases. You also need a system for styling the same module differently on separate pages. This leads to extra selectors in your CSS which is more work for the browser. This can cause problems on mobile devices like the iPad that don't have as much memory and processing power. If you're using media queries for responsive design, you're troubles compound even further as you add in the extra styles.
Solution B: Combine one CSS file per page template:
(By page template I mean one layout, but many different pages, like an article page)
In this scenario, you lose most of the issues with selecting described above, but you also lose some of the cache advantages. The worst part of this technique is that if you have the same styles on 2 different page templates then they'll be download twice, once for each page! For instance, this would happen with all your global files. :(
Summary:
So, as is common in programming, neither solution is perfect, but if anyone has run into this and found an answer I'd love to hear it! Especially, if you know of any techniques that help with the selector issue of Solution A.
Of course, combine and minify all the global styles, like your site template, typography, forms, etc. I would also consider combining the most important and most frequently used module styles into the global stylesheet, certainly the ones that you plan to use on the home page or entry point.
Solution B isn't a good one: the user ends up downloading the same content for each unique layout/page when you could have just loaded parts of it from the last page's cache. There is no advantage whatsoever to this method.
For the rest, I would leave them separate (and minified) and just load them individually as needed. You can use any of the preloading techniques described on the Yahoo! Developer network's "Best Practices for Speeding Up Your Web Site" guide to load the user's cache beforehand:
Preload Components
By preloading components you can take advantage
of the time the browser is idle and request components (like images,
styles and scripts) you'll need in the future. This way when the user
visits the next page, you could have most of the components already in
the cache and your page will load much faster for the user. There are actually several types of preloading:
Unconditional preload - as soon as onload fires, you go ahead and fetch some extra components. Check google.com for an example of how a
sprite image is requested onload. This sprite image is not needed on
the google.com homepage, but it is needed on the consecutive search
result page.
Conditional preload - based on a user action you make an educated guess where the user is headed next and preload accordingly. On
search.yahoo.com you can see how some extra components are requested
after you start typing in the input box.
As far as the conflicting selectors go: combining all the files and doing it any other way should not make a difference, this is a problem with your design. If possible, have all modules "namespaced" somehow, perhaps by using a common prefix for classes specific to the module, like blog-header or storefront-title. There is a concept called "Object-oriented CSS" that might reduce the need for lots of redundant CSS and module-specific class names, but this is normally done during the design phase, not something you can "tack on" to an existing project.
Less HTTP requests is better, but you have to take file size into consideration as well as user behavior and activity. The initial download time of the entry page is the most important thing, so you don't want to bog it down with stuff you won't use until later. If you really want to crunch the numbers, try a few different things and profile your site with Firebug or Chrome's developer tools.
i think you can make global.css that store style that need every template.
And you could make css in each template.
Or simply use css framework like lescss
After working with many CMSes and cutting up many HTML designs, when I saw SilverStripe's use of CSS, I was converted.
Essentially, that it would be a waste to change IDs in <div> tags depending upon the page you were on, and that changing the <body> tag's classes and ID would be an easier way of changing specific pages.
Such convictions were brought into question by a coworker during the following problem:
On a specific website, we have a variety of pages that are similar in structure. Some may include a special form, and some may not. All special forms should have a different background image depending upon the sub-section we are in.
Due to a claim that "additional lines of CSS slow down body.onLoads," my argument to code all background expectations in the CSS was rejected.
Can anybody cite evidence between a variety of cases? Cases including: Badly-coded CSS, and CSS well-coded, but having a variety of unused CSS on each page?
(And specifically speaking on my problem, can anybody explain my unease? I feel uncomfortable assuming images will be there and auto-generating Inline CSS (or header-section-based style tags) based upon a variable from a database.)
It's not going to matter (noticeably) unless your website is Gmail or YouTube (or is similarly CSS heavy).
Google has some recommendations in their Page Speed guide:
http://code.google.com/speed/page-speed/docs/payload.html#RemoveUnusedCSS
Removing or deferring style rules that
are not used by a document avoid
downloads unnecessary bytes and allow
the browser to start rendering sooner.
Before a browser can begin to render a
web page, it must download and parse
any stylesheets that are required to
lay out the page. Even if a stylesheet
is in an external file that is cached,
rendering is blocked until the browser
loads the stylesheet from disk. In
addition, once the stylesheet is
loaded, the browser's CSS engine has
to evaluate every rule contained in
the file to see if the rule applies to
the current page. Often, many web
sites reuse the same external CSS file
for all of their pages, even if many
of the rules defined in it don't apply
to the current page.
The best way to
minimize the latency caused by
stylesheet loading and rendering time
is to cut down on the CSS footprint;
an obvious way to do this is to remove
or defer CSS rules that aren't
actually used by the current page.
Concerning this:
Due to a claim that "additional lines
of CSS slow down body.onLoads," my
argument to code all background
expectations in the CSS was rejected.
The extra time is in the order of a few milliseconds. Do what is easier and maintainable, not what is more "efficient".
I'm building a site with a lot of similar css between pages. I've decided that a good approach would be to have the css generated as strings by php functions (with parameters) and outputed as an internal stylesheet in every page that i serve. The benefits:
this way if i make a change it will reflect throughout the entire site without having to maintain duplicates
i can send only the necessary css for a certain page
it's better than having small css files and sending a lot of css headers at inclusion
the possibility that the content might be displayed before the stylesheet is loaded is gone
i can calculate dimensions by using parameters
i can create a layer that will minify the result received from these functions or serve cached minified css
I haven't seen this done anywhere else unfortunately so i'm thinking that this might be because of SEO. The generated internal stylesheet will be at around 15kb max (before minifying the stylesheet).
I need your opinion on this approach and your thoughts about the impact a long internal stylesheet will have on SEO.
Many thanks.
Not an answer to your question (which is interesting enough!), but most of your arguments for inline CSS are wrong. An external style sheet is always the better and faster solution.
The first point you can handle by adding a version number to the style sheet's file name
The second point is moot because an external file gets cached, so no additional requests
The third point is moot for the same reason
The fourth point won't really matter once the style sheet is cached
The fifth point can be sorted using inline CSS for only the properties that need to be
updated dynamically - usually a tiny fraction of the whole CSS code base
The sixth point I don't get.
Go for an external style sheet. Just make sure it gets served with the correct caching headers!
Like long blocks of inline JavaScript, they are ignored.
Bots look at the content, not the layout. If you want a better representation of what they see, try the Lynx browser.
Unfortunately they will not be cached on the user's browser either, as external CSS and JS are, making each page load slower. It is actually more efficient to have a large external stylesheet than server up related "css snippets" with each page.
Assuming by 'internal stylesheet' you mean inline CSS included using the <style> tag, I'd recommend against this. If you use an external stylesheet, visitors download it once on the first request, and it will then be cached. By including all of your CSS inline, you're adding page weight to every single HTML request.
Although it might seem more efficient to just serve CSS for the current page, or split your CSS into lots of different page-specific stylesheets; in practice it's usually better just to have one stylesheet. Serving this compressed and with appropriate expires headers will almost always be faster than the alternatives.
Regarding SEO, robots ignore CSS, so this won't have any affect. If you had so much CSS that it substantially slowed down loading of your page, in theory you might start having issues, but you would need an inhuman amount of inline CSS before this could even potentially be an issue.
To the extent of my knowledge, your CSS sheet plays a minimal role in SEO, what is more important is your HTML markup and execution.
Following the order of '< h1 > - < h5 >' for your heading tags, with accompanying '< p >' tags instead of '< font >' or similar approaches is what will effect a web crawlers ability to recognise and prioritise the content in your page.
While you can use CSS to hide paragraph that you only want to appear in search engines and similar techniques it has little importance compared to the HTML structure.
All benefits you said apply. Search engines doesn't care too much about CSS and javascript (of course, if your page takes too long to wrap and send, this will affect, but I don't think it is the case).
I've seen this kind of solution before, but people tend to avoid use scripting to serve, once you can use media queries instead, writing just only one external stylesheet. I think you should take a look on this.
However, I see you are trying to optimize the CSS sent. This is good, but talking about 80k for all sheets, makes me think if you are not over complicating the rules.
Well, as last opinion, you can cache many different responses and make use of "canonical" thing on page head.