# Un flux oEmbed qui ralentit une page Elementor sans qu’on le voie venir > Une vidéo intégrée via une simple URL peut déclencher un appel externe à chaque affichage si le cache d'embed n'est pas exploité. - Auteur : WordPress Développement - Publié le : 2023-03-18 - Mis à jour le : 2023-03-18 - Catégorie : Elementor - URL : https://www.wpmoderne.fr/elementor/flux-oembed-ralentit-page-elementor/ ## L’essentiel - Le symptôme se limite souvent à un temps de réponse serveur irrégulier - Le diagnostic passe par le journal des requêtes sortantes - Le correctif utilise le cache oEmbed déjà présent dans WordPress Le temps de réponse d'une page varie d'une visite à l'autre sans qu'aucun changement n'ait été apporté au contenu : ce symptôme, sur une page Elementor contenant un widget lié à une URL externe collée directement, pointe presque toujours vers le même coupable, le mécanisme oEmbed de WordPress. ## Symptôme : un temps de réponse serveur qui varie sans raison visible Sur un projet suivi en 2023, une page d'accueil affichait un temps de réponse serveur oscillant entre 200 millisecondes et plus de deux secondes selon les visites, sans corrélation avec la charge du serveur ni avec un pic de trafic. Le contenu de la page n'avait pourtant pas changé depuis plusieurs semaines. Le widget en cause : un lien vers une vidéo Vimeo collé directement dans un widget texte, plutôt qu'ajouté via le widget vidéo natif d'Elementor. ## Diagnostic : ce que fait réellement oEmbed > L'essentiel à retenir : Le symptôme se limite souvent à un temps de réponse serveur irrégulier ; Le diagnostic passe par le journal des requêtes sortantes ; Le correctif utilise le cache oEmbed déjà présent dans WordPress Quand une URL reconnue comme provenant d'un fournisseur oEmbed est collée dans un contenu WordPress, la fonction `wp_oembed_get()` déclenche une requête HTTP sortante vers le fournisseur pour récupérer le code d'intégration correspondant. WordPress met normalement ce résultat en cache dans une métadonnée d'article pendant 24 heures, ce qui évite de refaire l'appel à chaque affichage. Le problème identifié sur ce projet : le contenu contenant l'URL n'était pas un article ou une page classique, mais un modèle Theme Builder affiché dynamiquement, sans identifiant d'article stable auquel accrocher le cache oEmbed. Résultat, l'appel sortant vers Vimeo se répétait à chaque chargement de page, avec un temps de réponse dépendant entièrement de la disponibilité du service tiers au moment précis de la requête. ## Correctif : forcer un embed statique La solution retenue a consisté à remplacer le lien brut par le widget vidéo natif d'Elementor, qui charge le lecteur côté client via une iframe, sans passer par un appel serveur à chaque affichage : ``` https://vimeo.com/123456789 Type de vidéo : Vimeo URL : https://vimeo.com/123456789 ``` Sur les cas où le lien brut reste nécessaire, par exemple dans un contenu géré par un rédacteur qui colle directement une URL dans un widget texte, une alternative consiste à s'assurer que le contenu concerné dispose bien d'un identifiant d'article stable, pour que le cache WordPress natif de 24 heures s'applique normalement. ## Prévention : identifier les contenus à risque Trois situations exposent particulièrement un projet Elementor à ce comportement : - un lien collé dans un gabarit Theme Builder dynamique plutôt que dans un article classique ; - un widget texte contenant une URL brute au lieu du widget dédié au type de média concerné ; - un cache de page configuré pour exclure certains gabarits dynamiques, ce qui empêche le résultat mis en cache d'être servi malgré la présence de la métadonnée. Une revue rapide des widgets texte du site, à la recherche d'URL brutes provenant de fournisseurs oEmbed connus (YouTube, Vimeo, X, SoundCloud), permet de repérer ces cas avant qu'ils ne deviennent un problème de performance visible. > Sur un projet qui affiche un temps de réponse serveur instable, on regarde toujours le journal des requêtes sortantes du serveur avant de suspecter la base de données : un appel externe non maîtrisé se cache plus souvent qu'on ne le pense derrière ce genre de symptôme. ## Étendre la vérification aux autres intégrations tierces Le même raisonnement s'applique à toute intégration qui déclenche un appel réseau côté serveur au moment de l'affichage d'une page : un flux RSS externe affiché via un widget, un appel à une API météo, ou une intégration de type carrousel d'avis clients récupérés dynamiquement depuis un service tiers. Chacune de ces intégrations mérite la même question : le résultat est-il mis en cache correctement, et pour combien de temps, avant qu'une nouvelle requête ne soit déclenchée à chaque visiteur ? Un contrôle simple consiste à observer le journal des requêtes sortantes du serveur sur une fenêtre de quelques minutes, en comparant le nombre d'appels effectués au nombre de visiteurs réels sur la même période. Un écart important entre les deux signale presque toujours un cache manquant ou mal configuré, qu'il s'agisse d'oEmbed ou d'une autre intégration du même type. ## En résumé Un flux oEmbed non mis en cache correctement transforme un simple lien collé en dépendance réseau silencieuse à chaque affichage de page. Le widget vidéo natif d'Elementor évite ce piège en s'appuyant sur une iframe côté client plutôt que sur un appel serveur systématique. Sur les contenus dynamiques comme les gabarits Theme Builder, une vérification du cache oEmbed s'impose dès qu'un temps de réponse irrégulier est constaté sans explication évidente.