Assets performance, PSI and loadCSS

Hi everyone! I decided to open this topic since I have a though time with render blocking css, js and PageSpeed Insights results. Hope you can give me some advices on this.
There is another well discussed topic about performance, but since I’d like to focus only on assets and async-loading css I hope this may be useful for others too.

So here the situation.

  • There are some grav plugins that add render-blocking css and js, is there a way to avoid this or make them load async?
  • If I set a js file to be loaded in async or defer, when pipelined can it become render-blocking or does it mantain its loading setting?
  • And the most crucial for me, render-blocking css. I’m trying to load some css files async using loadCSS with no success. But let me describe what I’ve done so that you can tell me if I did something wrong.
  1. I created 4 assets collection for css in system.yaml:
Collection in system.yaml

collections:
materialize-css:
- 'https://cdnjs.cloudflare.com/ajax/libs/materialize/0.100.1/css/materialize.min.css
inline-css:
- ‘theme://css/font-awesome.min.css’
- ‘https://fonts.googleapis.com/css?family=Open+Sans:300,400,600,700|Roboto:300,400,500,700
- 'https://fonts.googleapis.com/icon?family=Material+Icons
async-css:
- ‘https://cdnjs.cloudflare.com/ajax/libs/OwlCarousel2/2.2.1/assets/owl.theme.default.min.css
- ‘https://cdnjs.cloudflare.com/ajax/libs/OwlCarousel2/2.2.1/assets/owl.carousel.min.css
- ‘https://cdnjs.cloudflare.com/ajax/libs/normalize/7.0.0/normalize.min.css
- ‘https://cdnjs.cloudflare.com/ajax/libs/animate.css/3.5.2/animate.min.css
- 'https://cdnjs.cloudflare.com/ajax/libs/magnific-popup.js/1.1.0/magnific-popup.min.css
style-css:
- ‘theme://compiled_css/style.min.css’

  1. I loaded css in base.html.twig following loadCSS Instructions and Asset Mnager instructions
Assets in base.html.twig
{% block stylesheets %}
    {% do assets.addCss('materialize-css', {'priority':110, 'group':'assets-style'}) %}
    {% do assets.addCss('async-css', {'group':'assets-style'}) %}
    {% do assets.addCss('inline-css', {'group':'inline-style'}) %}
    {% do assets.addCss('style-css') %}
{% endblock %}
{{ assets.css('assets-style', {'rel':'preload', 'as':'style', 'onload':"this.rel='stylesheet'"}) }}

{% block headjs %}
    <script>
    /*! loadCSS. [c]2017 Filament Group, Inc. MIT License */
    (function(){ ... }());
    /*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
    (function(){ ... }());
    </script>
{% endblock %}

{{ assets.css('inline-style', {'loading': 'inline'}) }}
{{ assets.css('head') }}

In conclusion:

  • I wanted to load fonts css inline, but they are still render-blocking, any suggestion?
  • Async css works fine without loadCSS scripts (from PSI results) and it’s awesome, but many browsers don’t recognise rel:preload so loadCSS scripts are necessary from what I’ve read. When I add those scripts as you can see above, PSI detects all the css files as render-blocking.

Do you have any past experience using loadCSS with grav? Have I done some mistakes?
Many thanks for your help!
Here the PSI RESULTS

1 Like

I am in the same boat as you right now just trying to configure the inline-css and critical css - have you made any headway with this?

This kind of nonsense is exactly why moving to HTTP2 makes sense.

Have you successfully implemented HTTP2 with how grav deals with assets? I have actually gotten the server running just fine with HTTP2 and Grav but having a few issues actually getting the assets to get served correctly

We use HTTP2 on getgrav.org. Just works, no special workarounds required.

If you want to use loadCSS to all of your css files.

{{ assets.css('head', {'rel':'preload', 'as':'style', 'onload':'this.rel="stylesheet"'}) }} 


 <noscript>{{ assets.css()|raw }}</noscript>

Please note that loadCSS only works when css_pipeline is enabled