Favicons par plateforme

Next.js résout les icônes à partir de fichiers plutôt que de balises link écrites à la main. Placez le bon nom de fichier dans le bon répertoire et le framework génère le balisage pour vous.

React ne touche jamais à l’en-tête du document. Vos liens d’icônes vont dans le squelette HTML, et le fichier concerné dépend de la façon dont le projet a été initialisé : avec Create React App ou avec Vite.

Un composant monofichier Vue ne peut pas rendre une balise link dans l’en-tête. Les icônes sont déclarées dans index.html, qui se trouve à la racine du projet avec Vite et dans public/ avec Vue CLI.

Angular ne copie les fichiers statiques que si la configuration de build le lui indique. Un fichier qui n’est pas capté par l’entrée assets dans angular.json n’atteint jamais dist/, où que vous le placiez dans le projet.

SvelteKit copie tout ce qui se trouve dans static/ à la racine du build, et le squelette du document est src/app.html plutôt qu’un composant. Les balises d’icône y appartiennent, afin d’être dans le HTML servi avant l’exécution de tout JavaScript.

Nuxt injecte par défaut un lien vers /favicon.ico dans chaque page, donc un nouveau projet consigne une 404 pour ce lien jusqu’à ce que vous déposiez un fichier dans public/. Les icônes restantes sont déclarées dans le bloc app.head de nuxt.config.

Vite est inhabituel en ce qu’il traite index.html comme du code source plutôt que comme une ressource statique : il se trouve à la racine du projet et est réécrit au moment du build. Tout ce qui se trouve dans public/ est copié tel quel à la racine de la sortie.

Astro traite et marque d’une empreinte les ressources importées depuis src/, et copie public/ vers la sortie du build exactement telle qu’il l’a trouvée. Les icônes ont besoin de noms de fichiers stables, elles vont donc dans public/ et sont liées depuis un layout.

Gatsby est la seule stack présentée ici qui génère le jeu d’icônes pour vous. gatsby-plugin-manifest prend une unique image source nommée dans gatsby-config.js et produit les tailles, le manifest d’application web et les balises link au moment du build.

Hugo copie static/ à la racine du site publié, mais le balisage de l’en-tête appartient au thème que vous avez installé. L’astuce consiste à surcharger le partial du thème depuis votre propre projet plutôt que de modifier les fichiers sous themes/.

WordPress ne veut pas d’un dossier de fichiers d’icônes. Vous envoyez une seule image carrée comme icône de site, et le cœur la recadre dans les tailles qu’il sert et imprime les balises link sur chaque page.

Sur Shopify, le favicon est un réglage de thème adossé au CDN d’images, pas un fichier que vous placez sur un serveur. Le thème décide quelles balises sont rendues, et la plupart des thèmes n’en rendent qu’une seule.

Squarespace appelle le favicon une icône de navigateur, et c’est une seule image carrée envoyée dans les réglages du site. Il n’y a pas de système de fichiers ni de template à modifier, donc cet unique envoi représente l’essentiel de ce que vous obtenez.

Wix lie le favicon personnalisé à une formule payante avec un domaine connecté. Un site encore sur un sous-domaine wix.com affiche l’icône de Wix quoi que vous envoyiez. Il n’y a pas de système de fichiers ni d’en-tête à modifier.