Framework web détecté - Docs MetricSpot

Ce que vérifie ce contrôle

Identifie le framework JavaScript qui rend la page à partir d’un jeu d’empreintes en couches. Le premier signal fiable l’emporte, et le résultat est purement informationnel — cette règle ne fait jamais échouer un audit.

Framework	Empreintes principales
Next.js	`<script id="__NEXT_DATA__">`, `/_next/static/`, runtime `__next_f`, `x-powered-by: Next.js`
Nuxt	`window.__NUXT__`, `/_nuxt/`, `<div id="__nuxt">`, `<script id="__NUXT_DATA__">`
Astro	élément personnalisé `astro-island`, attributs `data-astro-cid-*`, commentaire `<!-- generated by Astro -->`, balises de style `View-Transitions`
SvelteKit	`<script data-sveltekit-hydrate>`, `/_app/immutable/`, globals `__sveltekit_*`
Remix / React Router 7	`window.__remixContext`, `/build/_assets/`, `<link rel="modulepreload" href="/build/`, URL `_data` à la Remix
Gatsby	`/page-data/`, `window.___gatsby`, `<div id="___gatsby">`
Create React App	`/static/js/main..js`, `/static/css/main..css`, `<div id="root">` sans balisage SSR
Vite + React/Vue	`/assets/index-*.js`, `<script type="module">` avec entrée hachée, pas de globals spécifiques à un framework
Vue (standalone)	`<div id="app">`, `window.Vue`, attributs scopés `data-v-*`
Angular	`<app-root>`, attribut `ng-version` sur l’élément racine

Quand MetricSpot ne peut pas classer la page avec confiance (builds lourdement personnalisés, HTML rendu côté serveur avec toutes les signatures de framework strippées), il rapporte « aucun framework détecté » et traite l’audit comme un site HTML rendu côté serveur.

Pourquoi c’est important

Comme pour le contrôle CMS — c’est du contexte qui permet au reste de l’audit de choisir la bonne recette.

Une balise canonical manquante sur Next.js se corrige via l’export metadata dans App Router ; sur Astro elle va dans votre <Layout> ; sur CRA il n’y a pas de vrai correctif sans serveur.
Un Largest Contentful Paint en échec sur Gatsby signifie généralement une mauvaise configuration du plugin d’images ; sur Next.js il pointe vers des hints de priorité de next/image ou la limite de streaming ; sur un SPA Vite, ça veut généralement dire un rendu côté client du contenu au-dessus de la ligne de flottaison (le vrai correctif est le SSR).
Un Interaction to Next Paint en échec sur Remix ou Next.js App Router pointe vers des client components surdimensionnés ; sur Astro vers des islands qui devraient être client:visible au lieu de client:load.
Un sitemap XML est @astrojs/sitemap sur Astro, next-sitemap sur Next.js Pages Router, ou sitemap.ts sur l’App Router — l’étiquette de correctif change à chaque fois.

Le framework prédit aussi les plafonds. Les sites Astro ou Next.js générés statiquement obtiennent couramment 95+ sur le score Lighthouse performance ; les SPA CRA ou Vue vanille rendus côté client cassent rarement la barre des 70 sans code-splitting agressif. Savoir où vous êtes vous dit ce qui vaut la peine d’être optimisé et ce qui vaut la peine d’être migré.

Comment corriger

Il n’y a rien à corriger — cette règle est informationnelle. L’action consiste à lire le reste de votre audit à travers le prisme des conventions de votre framework.

Next.js (App Router) — presque chaque correctif de metadata est l’export metadata dans layout.tsx ou page.tsx. Les en-têtes de sécurité vont dans next.config.js sous async headers(). Les images utilisent next/image avec priority pour le LCP.

Next.js (Pages Router) — <Head> dans pages/_app.tsx pour les balises sitewide, <Head> par page pour les surcharges. next-sitemap pour les sitemaps. En-têtes toujours dans next.config.js.

Astro — tout ce qui est au niveau page va dans votre composant <Layout> ou dans un bloc de frontmatter par page. @astrojs/sitemap pour les sitemaps, import.meta.env natif pour les données au build. Le modèle « zéro JS par défaut » d’Astro fait que la plupart des audits de performance passent sans intervention.

Nuxt 3 — composable useHead() ou definePageMeta() pour la metadata. nuxt.config.ts pour les réglages sitewide. @nuxtjs/sitemap pour les sitemaps.

SvelteKit — <svelte:head> dans +layout.svelte pour les balises sitewide ; <svelte:head> par route pour les surcharges. En-têtes via le hook handle dans src/hooks.server.ts.

Remix — exports meta et headers par route. Export links pour les preloads et feuilles de style.

Create React App / Vite SPA — la plupart des constats d’audit rendus côté serveur (en-têtes de sécurité, URL canoniques, balises OG) ne peuvent pas être pleinement corrigés sans rendu côté serveur ou étape de build d’injection de meta. Envisagez de migrer vers Vite + SSR (avec un framework comme Astro ou Remix) avant de combattre les règles individuelles.

Vue (standalone) — utilisez vue-meta (Vue 2) ou @unhead/vue (Vue 3) pour des balises head dynamiques. Pour du SEO SSR-grade, utilisez Nuxt.

Aucun framework détecté — vous êtes sur du HTML simple ou un template côté serveur (PHP, Rails, Django, templates Go). Chaque correctif est une édition directe du template source ; vous avez le plus de contrôle et le moins de magie.

Cachez les empreintes de framework si nécessaire. Vous pouvez retirer les en-têtes x-powered-by et stripper les commentaires , mais les signatures runtime (IDs de nœuds de mount, chemins d’assets hachés, globals d’hydratation) sont cuites dans le framework et les stripper casse le framework. Cela ne vaut pas l’effort.

Questions fréquentes

MetricSpot a détecté mon framework à tort. Pourquoi ?

Le cas le plus courant est détecter un framework wrapper plutôt que le méta-framework. Un site Next.js est aussi un site React — MetricSpot rapporte Next.js parce que c’est plus spécifique. Un site Nuxt est aussi un site Vue ; nous rapportons Nuxt. Si vous voyez « React » alors que vous êtes sur Next.js, votre build strippe probablement le script __NEXT_DATA__ — inhabituel mais possible dans des modes de sortie personnalisés.

Le framework affecte-t-il mon score d’audit ?

Non, cette règle est informationnelle seulement. Elle change cependant quelles recettes vous voyez — les échecs ailleurs dans l’audit recommanderont un correctif approprié à votre stack détectée.

Et si j’utilise plusieurs frameworks (micro-frontends) ?

MetricSpot rapporte le framework qui rend le shell de la page. Si votre shell est Next.js mais qu’une section est un micro-frontend Vue, nous rapporterons Next.js. Les configurations de micro-frontends à page unique sont rares sur les surfaces marketing — si vous en avez une, vous savez probablement déjà quel framework possède quelle route et pouvez interpréter l’audit en conséquence.