Fast Blocks (Lazy Load Blocks, Mobile Page Speed)

Half of your mobile page is thrown away before anyone sees it

Open your storefront on a phone and look at the page source. The blocks you switched off for phones in the layout editor are still there: they ran their database queries, they were rendered, they travelled over the mobile connection, and then CSS hid them. The visitor paid for every byte of that.

Fast Blocks stops it happening.

Two things, both measured

1. Blocks are built per device. The visibility checkboxes you already use in the layout editor stop being a display rule and start being a build rule. A block switched off for phones is not built for phones: no queries, no HTML, no cache entry. Nothing new to configure.

2. Heavy blocks load on scroll. Mark the product scrollers, brand strips and banners that live below the first screen. They leave the first response entirely and arrive when the visitor gets close to them, behind a skeleton that holds their place.

What that gives, in numbers

Eleven blocks below the first screen were marked as lazy, three more were hidden on phones. On a second storefront the visibility checkboxes alone took the phone response from 371 KB to 275 KB, with nothing else changed.

Less HTML means less to download, less to parse and less to keep in memory on a cheap phone. That is the part of Core Web Vitals a theme cannot fix on its own.

The skeleton repeats the shape of the block

One grey rectangle is not a placeholder, it is a second layout shift waiting to happen. Here the skeleton knows what is loading: cards for a product row, a strip for brand logos, a wide band for a banner, lines for text. It reads the block’s own column setting too, so a row of six skeleton cards is replaced by a row of six real ones. Reserve a height per block and the page does not jump at all. The animation switches itself off for visitors who asked for less motion.

It refuses to break your pages

Main content, product filters, breadcrumbs, the cart and every checkout step are never deferred: they carry the state of the page the visitor is on. The add-on keeps them out of the lazy list for you, so a wrong click cannot break a category listing or a checkout step.

The device is part of the block cache key, so the first visitor never warms the cache for everyone else. Without that, serving different HTML to different devices would do more harm than good. And when the feature is on, the storefront sends Vary: User-Agent, so a cache in front of the store keeps the phone and the desktop versions apart.

Honest limitations

• A block hidden on phones is absent from the page Google sees, because Google indexes mobile-first. Hide decorative blocks, not the ones you want found. The add-on says so right in the settings.
• If you run Varnish or Cloudflare, the cache key needs the device in it. Vary: User-Agent is sent, but those two ignore it for HTML by default. One setting on their side, and the documentation explains it.

Requirements

CS-Cart and Multi-Vendor 4.11.1 and above. Developed and tested on 4.20. No template edits, no theme changes, nothing to compile.