Simplia Templates

Appearance

Performance Optimization ​

Images ​

All template images (PNG/JPG/GIF) are optimized. Unnecessary data (EXIF, etc.) is removed and lossless compression is applied.

This optimization happens only after publishing.

Images in CSS ​

Images used in CSS (background, etc.) can be replaced with data-URIs. This eliminates waiting for them to load, as they are embedded directly in the CSS. For an image to be converted to a data-URI, it must meet these conditions:

  • the image must not be larger than 1 KB (after optimization)
  • the image appears only once in the CSS

CSS Minification ​

All CSS files (including plugins) are merged into one file and then minified. Property declarations are simplified (for example, margin-left, margin-right, margin-top are merged into a single margin) and identical rules are combined.

css
/* original CSS */
.product .price {
    display: none;
}
.hidden {
    display: none;
}

/* minified output */
.product .price,.hidden{display:none}

JavaScript Minification ​

All JS files are merged into one (including plugins) and minified. Whitespace is removed, dead code is eliminated, and variables inside functions are replaced with shorter names.

You can help the minifier by wrapping logical units in an anonymous function. This results in smaller minified code and also isolates the code from the rest of the template. Wrapping only makes sense for larger units such as delivery JavaScript — there is no benefit in wrapping a single banner definition.

javascript
(function(){
    // long code block
}());

JavaScript ​

JavaScript is loaded at the end of the page. This way, page rendering does not wait for it to load. Visitors can use the page before JavaScript loads, so the page should work without it.

All plugins are initialized last, so this needs to be accounted for in CSS. For example, all tabs except the first one must be hidden via CSS — do not rely on JavaScript to hide them.

There is no need to use $(document).ready in JavaScript — because scripts load at the end of the page, this function is unnecessary and actually slows down execution.

Lazy-load ​

When using banners, always use lazy-load. The first banner is rendered normally in the page, and the rest are loaded only when needed. This significantly speeds up page loading.

twig
<div class="owl-carousel">
    {%for banner in zdroj_bannery_index%}
        <a href="{{banner.odkaz}}" title="{{banner.popis?banner.popis:banner.nazev}}" class="item">
            {%if loop.first%}
                <img src="banner.link" alt="{{banner.alt}}">
            {%else%}
                <img data-src="{{banner.link}}" class="owl-lazy" alt="{{banner.alt}}">
            {%endif%}
        </a>
    {%endfor%}
</div>
javascript
var $owlCarousel = $('.owl-carousel');
if ($owlCarousel.size()) {
    $owlCarousel.owlCarousel({
        loop: true,
        items: 1,
        autoplay: true,
        autoplayTimeout: 8000,
        autoplayHoverPause: true,
        autoplaySpeed: 1000,
        lazyLoad: true
    });
}

WebFonts ​

Google Fonts are loaded from CDN using preload so they are available as early as possible, with font-display:swap set. The site first renders with a fallback font and then flashes to the final font once it loads. To minimize the visual shift after font loading, you can use the wf-active class, which is applied to the HTML tag after all fonts have loaded.

In addition to the fallback font, you also need to match letter-spacing etc., so the text is as similar as possible. The quickest way to find the right settings is FontStyleMatcher. You can test how the site looks without web fonts by appending ?_disableWebFonts to the URL.

Example:

css
h1 {
    font-family: Verdana, sans-serif;
    letter-spacing: 0.4px;
}
.wf-active h1 {
    font-family: 'Open Sans', Verdana, sans-serif;
    letter-spacing: 0;
}

Critical CSS ​

When changes are deployed to production, critical CSS is generated. The result is the set of styles needed for an approximate rendering of the page. When these are used, the page does not wait for all stylesheets to load before displaying — it renders immediately.

The page likely will not look 100% correct, but it will appear faster. After the full stylesheets load, the appearance is corrected. The delay between critical and complete styles is typically less than 1 second, but it has a major impact on the perceived loading speed.

Critical CSS can be verified in the production version by pressing CTRL+F5 (the critical styles flash briefly and then the normal styles load) or by appending the ?_forceCritical parameter to the URL (only when logged in). When testing, keep in mind that in a real deployment the user does not have images cached, etc. The most realistic preview is obtained via Google PageSpeed.

Automatic critical CSS generation runs on the main page types (index, product, category, subcategory, page), and for each type a random URL is selected (for example, a random product). However, some products may have a different layout. In config.json you can therefore define which CSS selectors should always be included, regardless of whether they were visible on the page. See the criticalCss config reference for all options including viewport overrides.

config.json:

json
{
    "webfonts":[
        "Open Sans:400,600,700"
    ],
    "criticalCss": {
        "global": {
            "forceInclude": [".header-info-bar"],
            "forceExclude": [".promo-dialog"]
        },
        "index": {
            "forceInclude": [".main-banner"],
            "forceExclude": [".video-player"]
        },
        "product": {
            "forceInclude": [".image-gallery"]
        },
        "category": {
            "forceInclude": [".image-gallery"]
        },
        "subcategory": {
            "forceInclude": [".image-gallery"]
        },
        "page": {
            "forceInclude": [".image-gallery"]
        }
    }
}