Hi @nils50122 !
Thanks for the detailed report, and for including the workaround you’re already using — that helps a lot.
You’re right that the Joinchat button isn’t part of the critical above-the-fold content, so the CSS doesn’t need to block rendering. We’ve noted this to consider for a future version.
In fact, we already released a version that loaded styles exactly like that, but some optimizers removed all stylesheets with media="print", so we had to revert it. The media="print" onload="this.media='all'" technique with a <noscript> fallback is valid, but for that reason (and a possible FOUC of the button when it appears) we’re looking into inlining the few critical styles as a more robust alternative.
In the meantime, your style_loader_tag filter is exactly the recommended approach. For anyone else who finds this thread, here’s an example:
add_filter( 'style_loader_tag', function ( $tag, $handle ) {
if ( 'joinchat' === $handle ) {
$tag = str_replace(
"media='all'",
"media='print' onload=\"this.media='all'\"",
$tag
);
}
return $tag;
}, 10, 2 );
We already released a version that loaded styles exactly like that, but some optimizers removed all stylesheets with media="print", so we had to revert it.
Thanks again for the suggestion. Best regards!
Hi, @nils50122
Joinchat uses delayed style loading to avoid render blocking, but WordPress 6.9 introduced a feature that, with classic themes, moves styles to the header to prevent FOUC issues. This eliminated delayed loading, but in some cases, it failed to load Joinchat styles correctly (and those of other themes or plugins).
Therefore, if the site had WordPress 6.9+ with classic themes (not block-based), we disabled delayed style loading. We also tried using media="print", but it caused other problems with some optimizers.
Now we’ve found another way to maintain delayed loading of styles. Try version 6.3.1, and you won’t need any snippets 🎉