Framework web rilevato - Docs di MetricSpot

Cosa verifica questo controllo

Identifica il framework JavaScript che renderizza la pagina da un set stratificato di firme. La prima firma affidabile vince, e il risultato è puramente informativo — questa regola non fa mai fallire un audit.

Framework	Firme primarie
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	elemento custom `astro-island`, attributi `data-astro-cid-*`, commento `<!-- generated by Astro -->`, tag style `View-Transitions`
SvelteKit	`<script data-sveltekit-hydrate>`, `/_app/immutable/`, globali `__sveltekit_*`
Remix / React Router 7	`window.__remixContext`, `/build/_assets/`, `<link rel="modulepreload" href="/build/`, URL `_data` stile Remix
Gatsby	`/page-data/`, `window.___gatsby`, `<div id="___gatsby">`
Create React App	`/static/js/main..js`, `/static/css/main..css`, `<div id="root">` senza markup SSR
Vite + React/Vue	`/assets/index-*.js`, `<script type="module">` con entry hashed, nessun globale specifico del framework
Vue (standalone)	`<div id="app">`, `window.Vue`, attributi scoped `data-v-*`
Angular	`<app-root>`, attributo `ng-version` sull’elemento root

Quando MetricSpot non riesce a classificare la pagina con sicurezza (build pesantemente personalizzate, HTML server-renderizzato con tutte le firme del framework spogliate), riporta “no framework detected” e tratta l’audit come un sito HTML server-renderizzato.

Perché è importante

Come per il controllo CMS — questo è contesto che permette al resto dell’audit di scegliere la ricetta giusta.

Un tag canonical mancante su Next.js si sistema tramite l’export metadata in App Router; su Astro va nel tuo <Layout>; su CRA non c’è un fix reale senza un server.
Un Largest Contentful Paint fallito su Gatsby di solito significa misconfigurazione del plugin immagini; su Next.js punta a hint di priorità di next/image o al boundary di streaming; su uno SPA Vite di solito significa rendering client-side del contenuto above-the-fold (il fix vero è SSR).
Un Interaction to Next Paint fallito su Remix o Next.js App Router punta a client component sovradimensionati; su Astro punta a island che dovrebbero essere client:visible invece di client:load.
Una Sitemap XML è @astrojs/sitemap su Astro, next-sitemap su Next.js Pages Router, o sitemap.ts su App Router — l’etichetta del fix è diversa ogni volta.

Il framework predice anche i soffitti. I siti Astro o Next.js generati staticamente segnano routinemente 95+ su Punteggio prestazioni Lighthouse; CRA client-renderizzati o SPA Vue vaniglia raramente superano 70 senza aggressivo code-splitting. Sapere dove sei ti dice cosa vale la pena ottimizzare e cosa vale la pena migrare.

Come sistemarlo

Non c’è niente da sistemare — questa regola è informativa. L’azione è leggere il resto del tuo audit attraverso la lente delle convenzioni del tuo framework.

Next.js (App Router) — quasi ogni fix di metadati è l’export metadata in layout.tsx o page.tsx. Gli header di sicurezza vanno in next.config.js sotto async headers(). Le immagini usano next/image con priority per LCP.

Next.js (Pages Router) — <Head> in pages/_app.tsx per tag sitewide, <Head> per-pagina per gli override. next-sitemap per le sitemap. Header ancora in next.config.js.

Astro — tutto a livello pagina va nel tuo componente <Layout> o in un blocco frontmatter per-pagina. @astrojs/sitemap per le sitemap, import.meta.env nativo per i dati build-time. Il modello “zero JS by default” di Astro significa che la maggior parte degli audit di performance passa senza interventi.

Nuxt 3 — composable useHead() o definePageMeta() per i metadati. nuxt.config.ts per impostazioni sitewide. @nuxtjs/sitemap per le sitemap.

SvelteKit — <svelte:head> in +layout.svelte per tag sitewide; <svelte:head> per-route per gli override. Header tramite hook handle in src/hooks.server.ts.

Remix — export meta e headers per route. Export links per preload e fogli di stile.

Create React App / Vite SPA — la maggior parte dei findings server-renderizzati dell’audit (header di sicurezza, URL canonici, tag OG) non può essere sistemata del tutto senza server-side rendering o uno step di build che inietti meta. Considera di migrare a Vite + SSR (con un framework come Astro o Remix) prima di combattere singole regole.

Vue (standalone) — usa vue-meta (Vue 2) o @unhead/vue (Vue 3) per head tag dinamici. Per SEO di livello SSR, usa Nuxt.

Nessun framework rilevato — sei su HTML semplice o su un template server-side (PHP, Rails, Django, template Go). Ogni fix è una modifica diretta al template sorgente; hai il massimo controllo e la minima magia.

Nascondi le firme del framework se devi. Puoi rimuovere gli header x-powered-by e spogliare i commenti , ma le firme runtime (ID dei mount node, path degli asset hashed, globali di idratazione) sono cotte nel framework e spogliarle rompe il framework. Non vale lo sforzo.

Domande frequenti

MetricSpot ha rilevato il framework sbagliato. Perché?

Il caso più comune è rilevare un framework wrapper invece del meta-framework. Un sito Next.js è anche un sito React — MetricSpot riporta Next.js perché è più specifico. Un sito Nuxt è anche un sito Vue; riportiamo Nuxt. Se vedi “React” ma sei su Next.js, la tua build probabilmente sta spogliando lo script __NEXT_DATA__ — insolito ma possibile in modalità output personalizzate.

Il framework influisce sul mio punteggio audit?

No, questa regola è solo informativa. Cambia quali ricette vedi — i fallimenti altrove nell’audit raccomanderanno un fix appropriato al tuo stack rilevato.

E se sto usando più framework (micro-frontend)?

MetricSpot riporta il framework che renderizza la shell della pagina. Se la tua shell è Next.js ma una sezione è un micro-frontend Vue, riporteremo Next.js. I setup micro-frontend a pagina singola sono rari su superfici marketing — se ne hai uno, probabilmente sai già quale framework possiede quale route e puoi interpretare l’audit di conseguenza.