A place to gather resources, issues, and solutions to optimize website speed

Develop, Build & Integrate CMS Development
,
8

Nice one @theAndreyK !

Love the idea.

So gonna share how I started to implement fragmented CSS for a theme (based on boilerplate).

  1. Go to templates/layouts/base.html
  2. Look for the inject of the main.css file (at the time, line 8):
    {{ require_css(get_asset_url('../../css/main.css')) }} and replace it with

{% if load_css %} {{ require_css(get_asset_url(load_css)) }}{% else %} {{ require_css(get_asset_url('../../css/main.css')) }}{% endif %}

  1. Go to the templates folder.
  2. In all your templates you want to define the load_css variable before the call of the base.html, so for example for the blog template it will be something like this:

{% set load_css = "../../css/blog.css" %}{% extends "./layouts/base.html" %}

Repeat for each template file.

  1. Create the {template-name}.css files that will call just the needed CSS files based on the template/page. I would also suggest to have a “general” one that will contain the across website element that you will also need such _reset, _normalize.css _typograghy.css etc. So it’s easier to keep it right and simpler.
    Example of my blog.css file:
    {% include './general.css' %}{% include './_blog.css' %} My version is based on an outdated boilerplate version so double check your needs here*. Ideally you will get rid of the theme-overrides.css and integrate where applies.
    Notice the load_css is calling the new blog.css file (not _blog.css) because it not a fragmented one (it contains the calls to those fragmented files that would be used).
    Repeat for all you want to split, for example blog.css, lp.css, page.css and system.css.

Explanation:

The variable load_css will load a css file, for example blog.css. It will contains a similar structure to the current main.css file, but instead calling all the fragmented css files will call just based on the template you are visting and it needs.
The only “issue” is that on the website side, you can’t really fragment that much because you don’t know if it will include a module, a form a table etc. But it definetly worth it for the blog side.
More to come!
@jmclaren

Regarding the new dnd I am very concern about how HS manages background images for the sections (as background-image CSS properties). It would be much more worth it to have them as image elements so you can lazyload them too (that is what we used to do, and I could do a CM for it, but I would like to use as much HS tools this time instead “hacking” ways that will increase dificulty for the marketers). Other option is make them CSS class dependent so will only load after you scroll until that point, but not as good as the previous suggestion -unnecesary JS handle-.