# Un bloc Cover plein écran comme hero d’accueil sans plomber le LCP

> Un hero impactant en page d'accueil ne doit pas coûter les deux premières secondes de chargement. Dégradé CSS, image responsive et priorité de chargement, expliqués.

- Auteur : Clément Hadrot
- Publié le : 2025-04-02
- Mis à jour le : 2025-04-02
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/bloc-cover-hero-plein-ecran-performant/

## L’essentiel

- Un dégradé CSS en overlay coûte zéro octet contre une image d'overlay
- fetchpriority=high sur l'image du hero réduit le LCP mesurable
- Le srcset natif de WordPress fait le plus gros du travail sans configuration

Un client dans le secteur du voyage voulait un hero d'accueil « impactant », une grande image plein écran avec un dégradé sombre en bas pour faire ressortir le titre et le bouton d'action. Le prototype initial, construit avec un bloc Cover classique et une image d'overlay semi-transparente superposée en PNG, affichait un Largest Contentful Paint de 3,1 secondes en test PageSpeed, un score franchement décevant pour une simple section d'accueil.

Trois ajustements successifs, tous réalisables sans plugin ni développement lourd, ont permis de ramener ce chiffre à 0,9 seconde, tout en conservant exactement le rendu visuel souhaité par le client.

## Premier ajustement : remplacer l'image d'overlay par un dégradé CSS

Le prototype initial utilisait une image PNG semi-transparente de 180 Ko posée par-dessus la photo de fond, pour obtenir l'effet d'assombrissement en bas du hero. Cette image supplémentaire n'apportait strictement rien que le réglage natif `dimRatio` du bloc Cover, combiné à un dégradé, ne pouvait produire nativement, sans le moindre octet supplémentaire à charger.

```
<!-- wp:cover {"url":"hero-voyage.jpg","dimRatio":40,"gradient":"black-gradient","minHeight":80,"minHeightUnit":"vh"} -->
<div class="wp-block-cover" style="min-height:80vh">
  <span aria-hidden="true" class="wp-block-cover__background has-black-gradient-background has-background-dim-40 has-background-dim"></span>
  <img class="wp-block-cover__image-background" alt="" src="hero-voyage.jpg" data-object-fit="cover"/>
  <div class="wp-block-cover__inner-container">
    <!-- wp:heading {"textColor":"white"} -->
    <h2 class="has-white-color has-text-color">Explorez sans compromis</h2>
    <!-- /wp:heading -->
  </div>
</div>
<!-- /wp:cover -->
```

Le dégradé `black-gradient` référencé ici est déclaré une fois pour toutes dans `theme.json`, réutilisable sur d'autres sections du site sans jamais générer de fichier image supplémentaire :

```
"gradients": [
  {
    "slug": "black-gradient",
    "gradient": "linear-gradient(180deg, rgba(0,0,0,0) 0%, rgba(0,0,0,0.75) 100%)",
    "name": "Dégradé noir bas"
  }
]
```

## Deuxième ajustement : prioriser le chargement de l'image du hero

> L'essentiel à retenir : Un dégradé CSS en overlay coûte zéro octet contre une image d'overlay ; fetchpriority=high sur l'image du hero réduit le LCP mesurable ; Le srcset natif de WordPress fait le plus gros du travail sans configuration

Par défaut, WordPress applique un chargement différé (`loading="lazy"`) à la majorité des images du contenu, ce qui est excellent pour les images sous la ligne de flottaison mais contre-productif pour l'image du hero, visible immédiatement au chargement. Depuis la version 6.3, le cœur détecte généralement la première image de la page et retire ce différé automatiquement, mais sur un bloc Cover en arrière-plan CSS plutôt qu'en balise `img` classique, cette détection automatique échoue parfois.

La correction a consisté à forcer explicitement l'attribut `fetchpriority="high"` sur l'image du hero via un filtre ciblé, en complément de la suppression du chargement différé :

```
add_filter( 'render_block_core/cover', function( $block_content, $block ) {
    if ( ! empty( $block['attrs']['className'] ) && str_contains( $block['attrs']['className'], 'hero-accueil' ) ) {
        $block_content = str_replace( 'loading="lazy"', 'fetchpriority="high"', $block_content );
    }
    return $block_content;
}, 10, 2 );
```

## Troisième ajustement : vérifier le srcset natif plutôt que réinventer une solution

Le bloc Cover, comme le bloc Image, génère automatiquement un attribut `srcset` avec plusieurs tailles d'image dès lors que le fichier a été importé dans la médiathèque et que le thème ne désactive pas ce mécanisme natif. Sur ce projet, un ancien réglage laissé par le prestataire précédent désactivait la génération de tailles intermédiaires via `add_filter( 'intermediate_image_sizes_advanced', '__return_empty_array' )`, ce qui forçait le navigateur à charger systématiquement l'image en pleine résolution, même sur un petit écran mobile.

La suppression pure et simple de ce filtre obsolète a suffi à réactiver le `srcset` natif, sans configuration supplémentaire, et a représenté à elle seule la moitié du gain de performance mesuré sur ce projet.

### Mesurer l'impact réel de chaque ajustement

| Étape | LCP mesuré (PageSpeed mobile) |
| --- | --- |
| Version initiale (image d'overlay + srcset désactivé) | 3,1 s |
| Après suppression de l'image d'overlay | 2,3 s |
| Après réactivation du srcset natif | 1,4 s |
| Après ajout de fetchpriority="high" | 0,9 s |

> Sur un hero plein écran, chaque octet économisé avant le premier rendu visible compte davantage que sur n'importe quelle autre section de la page : c'est littéralement ce que Google mesure comme premier ressenti de vitesse pour l'utilisateur.

## En résumé

Un hero impactant en bloc Cover ne demande ni image d'overlay supplémentaire ni développement complexe pour rester rapide : un dégradé CSS natif, un `srcset` non désactivé par erreur, et une priorité de chargement explicite sur l'image principale suffisent à obtenir un rendu visuel ambitieux sans en payer le prix en performance mesurée.