Mon site
[site address] sur mon serveur Opus Growth (serveur
[server name], clé de site
[site key] s'il s'agit d'un site supplémentaire) a été construit avec le kit de site et il est lent sur mobile. Le kit charge Tailwind via le Play CDN qui compile dans le navigateur, les polices depuis Fontshare et les bibliothèques d'animation depuis jsDelivr, et génère le menu avec JavaScript. Sans changer l'apparence du site, transforme tout cela en fichiers compilés hébergés sur mon propre serveur. L'objectif : pendant le chargement d'une page, le site n'envoie aucune requête en dehors de son propre domaine.
1. Mesure de départ. Note la version actuelle avec site_versions. Lance core_web_vitals pour la page d'accueil et
[heaviest page] sur mobile et desktop avec resources=true. Mets dans un tableau le score de performance, le LCP, le CLS, le nombre total de requêtes, le poids total et les requêtes qui sortent de ton propre domaine. Liste les fichiers HTML avec site_list_files et extrais toutes les balises `<script>` et `<link>` de chaque page.
2. Montre-moi le plan et attends mon accord. Liste chaque fichier qui sera modifié ou ajouté.
3. Compile Tailwind. Déplace le réglage `tailwind.config` en ligne des pages vers `_src/tailwind.config.js` ; définis content sur `
["./*.html", "./**/*.html"]` et ajoute tout fichier JavaScript qui génère encore des classes. Crée `_src/input.css` à partir des lignes `@tailwind base; @tailwind components; @tailwind utilities;` suivies du contenu de assets/app.css. Exécute `npx --yes tailwindcss@3 -c _src/tailwind.config.js -i _src/input.css -o assets/site.css --minify` avec site_run_command. Donne au fichier un nom dérivé d'un hash de son contenu, par exemple `assets/site.3f9a1c2b.css`, mets à jour le lien sur chaque page et supprime le script du Play CDN ainsi que le réglage en ligne. Relance la compilation après chaque modification du HTML qui change des classes, sinon les nouvelles classes manquent dans le CSS.
4. Héberge les polices toi-même. Récupère le CSS de Fontshare avec une requête SÉPARÉE pour chaque famille et chaque graisse, par exemple `https://api.fontshare.com/v2/css?f[]=satoshi@400&display=swap` ; nous avons constaté que d'autres familles revenaient quand plusieurs familles ou graisses étaient demandées en même temps, donc vérifie à chaque fois le nom font-family renvoyé. Télécharge les fichiers woff2 dans `assets/fonts/`, écris les règles `@font-face` avec `font-display: swap` en haut de assets/app.css (design-check y cherche une typographie distinctive) et précharge la police du texte et celle du grand titre du premier écran avec `<link rel="preload" as="font" type="font/woff2" crossorigin>`. Supprime les liens `preconnect` et feuille de style de Fontshare. Vérifie que la licence de la police autorise l'auto-hébergement.
5. Régénère les images. Déplace les fichiers source JPG et PNG dans `_src/img/`. Installe sharp en dehors du dossier du site : lance `mkdir -p /data/_build && cd /data/_build && npm init -y && npm i sharp` avec site_run_command et background=true, puis enchaine avec site_command_status ; si ce dossier n'est pas accessible en écriture, explique-moi pourquoi. Avec un script node, produis du WebP (qualité 72) et de l'AVIF (qualité 50) en 480, 800, 1200 et 1600 pixels de large pour chaque image. Dans le HTML, enveloppe chaque image dans `<picture>` : un `<source type="image/avif" srcset sizes>` pour l'AVIF, un `<img>` WebP en repli avec son propre srcset et sizes, ainsi que la largeur et la hauteur réelles de l'image source. L'image principale du premier écran reçoit `fetchpriority="high"` et n'est pas en lazy ; toutes les autres reçoivent `loading="lazy" decoding="async"`. Écris sizes de façon à correspondre à la largeur réellement occupée par l'image.
6. Nettoie les scripts. Si le site n'a aucune animation, ou seulement des accroches décoratives comme `data-reveal`, supprime complètement GSAP, ScrollTrigger, SplitText, Lenis, Swiper, motion.js et le script en ligne qui ajoute la classe `anim`, et supprime les règles Lenis et anim de app.css. Si les animations sont vraiment nécessaires, copie la bibliothèque dans `assets/vendor/`, charge-la avec `defer` uniquement sur les pages qui l'utilisent et vérifie que le contenu reste visible avec `prefers-reduced-motion`. Transforme le menu et le pied de page en HTML statique avec un script `chrome-stamp.mjs` : il lit site.config.js, écrit entre les marqueurs `<!-- chrome:nav:start -->`, `<!-- chrome:nav:end -->` et chrome:footer, construit le menu mobile avec `<details>`, garde des liens d'au moins 44 pixels de haut et utilise des paragraphes, et non des h4, pour les titres de colonnes du pied de page. Retire ensuite chrome.js et la balise script de site.config.js des pages ; site.config.js ne reste que comme fichier de données lu par les scripts.
7. Ramène les requêtes tierces à zéro. Avec site_run_command, cherche dans le HTML et le CSS les valeurs src et href qui commencent par `https://` ; rapatrie sur le site ou supprime toute ressource en dehors de ton propre domaine, des liens tel:, mailto: et wa.me. Place le favicon dans `assets/img/` et lie-le sur chaque page, sinon le navigateur demande /favicon.ico et inscrit une erreur 404 dans la console.
8. En-têtes de cache. Lance site_headers avec mode="list". Si aucun fichier sous assets ne sera jamais remplacé sous le même nom (le nom du CSS porte un hash, les images reçoivent un nouveau nom quand elles changent), prévisualise la ligne `/assets/* Cache-Control: public, max-age=31536000, immutable` avec confirm=false et applique-la avec confirm=true après mon accord. Ne demande pas de Cache-Control pour le HTML ; la plateforme sert déjà le HTML en no-cache.
9. Contrôles et nouvelle mesure. Exécute `node seo-stamp.mjs`, `node chrome-stamp.mjs`, la compilation du CSS, `node seo-check.mjs`, `node design-check.mjs` et `npx --yes html-validate "**/*.html"` dans cet ordre et amène-les tous à zéro erreur. Vérifie chaque page avec site_preview en 360, 390, 768 et 1440 pixels de large. Refais la mesure core_web_vitals de l'étape 1 sur les mêmes pages et lance aussi seo_audit avec runs=2 pour la page d'accueil. Si la performance mobile est inférieure à 95, trouve la cause dans les listes resources=true et corrige-la ; la cause la plus fréquente est un décalage de mise en page du à une police de titre non préchargée.
Résultat attendu : un tableau avant et après (page, appareil, performance, LCP, CLS, nombre de requêtes, Ko totaux, nombre de requêtes tierces), la liste des fichiers ajoutés et supprimés, les lignes site_headers actives et une courte note indiquant quelles commandes relancer, et dans quel ordre, après la prochaine modification. Si une étape casse le site, reviens à la version notée avec site_restore et préviens-moi.
