-
psrios
Hello guys,
I have been testing for speed and I noticed that I am receiving this message on light house. Also, images inside generateblok is not being lazyloaded. Can you please help with this? Thank you!
Render-blocking requests
Requests are blocking the page’s initial render, which may delay LCP. Deferring or inlining can move these network requests out of the critical path.LCPFCPUnscored
URL
Transfer Size
Duration
1.1 KiB 160 ms
…generateblocks/style-global.css?ver=178… -
George
Hi there,
1. The render-blocking
style-global.cssThat’s GenerateBlocks’ global stylesheet, loaded in the head as a normal stylesheet — which is why Lighthouse flags it as render-blocking. At 1.1 KiB the real-world impact on LCP is very small, so I wouldn’t worry too much about it from a performance standpoint.
If you’d like to clear the flag anyway, the place to handle it is your optimization plugin. You already have Perfmatters running on the site, and it has options to defer or inline CSS and move it out of the critical render path. That’s the right tool for this rather than anything on the GenerateBlocks side.
2. Images inside GenerateBlocks not lazy-loading
Looking at your page, the GenerateBlocks images actually are being lazy-loaded — but by EWWW Image Optimizer, not the browser’s native lazy-loading. You can see it in the markup: the images carry EWWW’s lazy-load classes and load via
data-srcswapping.So the lazy-loading is working; it’s just being handled by EWWW. When an image optimizer like EWWW is active, it takes over lazy-loading, so if certain images aren’t behaving the way you expect, the settings to check are inside EWWW (and Perfmatters, which also has a lazy-load option). Running both at once can sometimes cause conflicts, so it’s worth making sure lazy-loading is only enabled in one of them.
Both of these come down to your optimization plugins rather than GeneratePress or GenerateBlocks, so those are the settings to dig into.
- You must be logged in to reply to this topic.