Velo by Wix pour la performance : preload hero image, defer scripts et headers HTTP custom

Précharger l’image hero, différer les scripts tiers, personnaliser les headers HTTP : trois leviers de performance classiques, que beaucoup de tutoriels promettent d’implémenter « via Velo » sur Wix. En vérifiant la documentation officielle de l’API, un seul des trois fonctionne vraiment comme annoncé. Voici ce qui est réellement actionnable, et par quel mécanisme.

Ce que Velo peut faire pour la performance, et ce qu’il ne fait pas

Soyons précis dès le départ, parce que la confusion coûte du temps à quiconque essaie : « Velo » désigne le SDK de développement de Wix (JavaScript côté client et côté serveur, modules comme wix-seo-frontend ou wix-http-functions). Le panneau « Code personnalisé » (Custom Code), qui permet d’injecter du HTML brut dans le head ou le body du site, est une fonctionnalité distincte, accessible sans écrire une ligne de Velo. Beaucoup de guides mélangent les deux sous l’étiquette « Velo », ce qui explique une partie des tutoriels qui ne fonctionnent pas tels quels une fois testés.

Précharger l’image hero : ce que l’API SEO de Velo ne couvre pas

Le module wix-seo-frontend expose une fonction setLinks() qui permet d’ajouter des balises <link> dans le head de la page. Sur le papier, c’est la fonction qu’on utiliserait pour poser un <link rel="preload"> vers l’image hero. En pratique, la documentation officielle de cette fonction est explicite : elle sert à poser des liens « SEO-related » (canonical, alternate, author), et précise noir sur blanc qu’on ne peut pas l’utiliser pour ajouter un lien de feuille de style. Rien n’indique qu’elle prenne en charge rel="preload", et aucun exemple officiel ne le montre : ce n’est pas le cas d’usage pour lequel elle a été conçue.

Le levier qui fonctionne réellement pour précharger une ressource passe par le panneau Code personnalisé, en emplacement « Head », avec la balise préchargement classique posée en HTML brut. Ce n’est pas du Velo au sens strict, c’est de l’injection de code statique, mais c’est le seul mécanisme documenté qui produit l’effet recherché sur une page Wix classique. Nous avions déjà détaillé, dans notre analyse du LCP sur Wix, la distinction entre préchargement et priorité de chargement (fetchpriority) : cette distinction technique reste valable, mais elle suppose d’abord de savoir par quel canal la balise peut effectivement être posée, ce qu’aucune documentation Wix ne précise clairement.

Différer les scripts tiers : ça marche, mais ce n’est pas Velo

Bonne nouvelle sur ce deuxième point : Wix documente officiellement l’usage de l’attribut defer pour le code tiers, avec la recommandation de placer les scripts non critiques en fin de body plutôt qu’en tête de page, pour éviter qu’ils ne bloquent l’affichage du contenu principal. Ce réglage se fait, là encore, via le panneau Code personnalisé (emplacement « Body – end »), pas via une fonction Velo dédiée : il n’existe pas d’API wix-seo-frontend ou équivalente qui gère le differé de scripts par programmation.

C’est un point de recoupement direct avec ce que nous avions montré sur le chargement fantôme des applications du Wix App Market et l’INP : une partie des scripts tiers qui dégradent l’interactivité viennent d’applications installées, pas seulement de code personnalisé collé manuellement. Différer le code que vous contrôlez ne résout que la moitié du problème si des applications non désinstallées continuent de charger leur propre script d’initialisation en parallèle.

Headers HTTP personnalisés : la frontière nette entre vos pages et vos endpoints

C’est le point le plus mal compris des trois, et celui où la confusion est la plus coûteuse en temps perdu. Velo expose bien un objet headers permettant de définir des en-têtes HTTP personnalisés (content-type, cache-control, etc.), documenté dans le module wix-http-functions. Mais cette API s’applique exclusivement aux fonctions HTTP personnalisées que vous créez vous-même dans http-functions.js, c’est-à-dire des points d’entrée d’API que vous construisez pour exposer vos propres données (par exemple https://votresite.com/_functions/maFonction). Elle ne s’applique jamais à la réponse HTML des pages normales de votre site, celles que visitent réellement vos clients : ces pages sont servies par l’infrastructure de Wix, sans point d’accroche Velo pour en modifier les en-têtes.

Concrètement, si votre objectif est d’ajouter un Cache-Control agressif sur les pages vitrines de votre site pour améliorer un score de performance, Velo ne vous donne pas ce levier : la mise en cache de vos pages classiques est gérée nativement par Wix, sans réglage exposé au niveau développeur.

Éditeur classique, Wix Studio, Velo : où se situe vraiment la limite

Nous avions déjà posé cette distinction pour le CLS : ce qui se règle nativement dans l’éditeur classique (dimensions d’image, taille de texte fixe) diffère de ce qui exige Wix Studio ou du code personnalisé, cf. notre article sur la réduction du CLS sans casser le design. Pour les trois techniques de cette page, le tableau se résume ainsi :

Le fil conducteur : Velo (le SDK) excelle pour construire de la logique applicative (formulaires dynamiques, bases de données, API personnalisées), mais n’a pas vocation à remplacer les réglages de livraison de page que d’autres CMS auto-hébergés exposent nativement. Le panneau Code personnalisé, plus modeste, reste le seul point d’entrée pour toucher au head et au body des pages elles-mêmes.

La checklist des trois optimisations, correctement scopées

1. Preload de l’image hero

   Récupérez l’URL de l’image telle que servie par le CDN Wix (compression automatique déjà appliquée), posez la balise <link rel="preload" as="image" href="..."> via Code personnalisé en emplacement Head, sur la ou les pages concernées uniquement, pas sur tout le site.

2. Defer des scripts tiers

   Auditez d’abord les scripts déjà chargés par vos applications installées avant d’ajouter du code manuel : différer un script que vous collez vous-même ne compense pas un script identique chargé en parallèle par une app. Placez le code tiers réellement nécessaire en Body – end, avec l’attribut defer posé explicitement.

3. Headers HTTP

   Abandonnez l’idée de personnaliser les headers de vos pages vitrines : ce n’est pas exposé. Si votre besoin concerne une API que vous construisez vous-même (formulaire, intégration), utilisez wix-http-functions en connaissance de cause, pas comme solution de performance pour vos pages de contenu.

Questions fréquentes

En résumé

Sur les trois techniques promises par ce type de recherche, une seule (differer les scripts tiers) dispose d’un chemin officiellement documenté par Wix, via le panneau Code personnalisé. Le preload d’image passe par le même panneau mais sans confirmation officielle d’usage prévu. Les headers HTTP personnalisés, eux, ne s’appliquent qu’aux endpoints que vous créez vous-même avec Velo, jamais aux pages de contenu classiques. Le distinguo entre le SDK Velo et le panneau Code personnalisé est ce qui sépare un tutoriel qui fonctionne d’un tutoriel qui échoue silencieusement en production.