AMP (Accelerated Mobile Pages)

AMP (Accelerated Mobile Pages) è un framework web open-source creato originariamente da Google per offrire pagine a caricamento rapido sui dispositivi mobili. Le pagine AMP utilizzano una versione semplificata di HTML con rigorose restrizioni su JavaScript e CSS per dare priorità alla velocità di rendering. Il framework memorizza nella cache le pagine sulla CDN di Google e le pre-renderizza nei risultati di ricerca, facendo sembrare che le pagine AMP si caricassero quasi istantaneamente quando toccate da una ricerca Google. AMP è stato ampiamente adottato da editori di notizie e siti di contenuti tra il 2016 e il 2021, in particolare perché il carosello Top Stories di Google inizialmente richiedeva pagine AMP per l'inclusione. L'influenza del framework è diminuita significativamente dopo che Google ha rimosso il requisito AMP per Top Stories nel 2021 e ha spostato l'enfasi del ranking sui [Core Web Vitals](/glossary/core-web-vitals).

I lettori da mobile si aspettano che le pagine si carichino in meno di tre secondi. I contenuti lenti perdono lettori e danneggiano il posizionamento nelle ricerche. Per gli editori che hanno investito in AMP tra il 2016 e il 2021, il framework ha offerto miglioramenti misurabili nella velocità e nella visibilità di ricerca. Tuttavia, AMP ha raggiunto la sua velocità imponendo limitazioni severe — nessun JavaScript personalizzato, CSS limitato, capacità analitiche ridotte e nessun supporto per elementi interattivi come video incorporati, moduli o animazioni 3D. Con il miglioramento delle prestazioni dei browser e delle reti mobili, il divario tra pagine web standard ben ottimizzate e pagine AMP si è ridotto considerevolmente. Gli editori devono ora valutare se le restrizioni di AMP giustificano i benefici in diminuzione, soprattutto quando i framework moderni possono raggiungere tempi di caricamento comparabili senza sacrificare funzionalità.

**"AMP è necessario per un buon posizionamento mobile."** Questo era parzialmente vero fino al 2021, quando Google richiedeva AMP per il carosello Top Stories. Da allora, Google posiziona le pagine in base ai [Core Web Vitals](/glossary/core-web-vitals) (Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint) indipendentemente dall'uso di AMP. Una pagina standard ben ottimizzata si posiziona altrettanto bene di una pagina AMP. **"Le pagine AMP sono sempre più veloci delle pagine normali."** AMP raggiunge la velocità attraverso caching e restrizioni, ma una pagina web standard adeguatamente ottimizzata con formati immagine moderni, JavaScript minimo e caching edge può eguagliare o superare i tempi di caricamento di AMP. Il vantaggio percepito di velocità derivava in gran parte dal pre-rendering della CDN di Google, non dal sottoinsieme HTML di AMP. **"Abbandonare AMP danneggerà il traffico."** Molti editori che hanno migrato da AMP hanno riportato traffico stabile o addirittura migliorato, perché le loro pagine standard potevano ora includere contenuti più ricchi, analitiche migliori ed elementi interattivi che aumentavano l'engagement e il tempo sulla pagina.

AMP funziona applicando un insieme di regole a livello HTML: - **JavaScript**: AMP vieta tutto il JavaScript personalizzato. È consentita solo la libreria di componenti di AMP, che limita l'interattività a componenti precostruiti come caroselli di immagini e accordion. - **CSS**: Tutti gli stili devono essere inline e sotto i 75KB totali. I fogli di stile esterni sono bloccati. - **Risorse**: Immagini, video e iframe devono utilizzare tag specifici di AMP (`amp-img`, `amp-video`, `amp-iframe`) con dimensioni pre-dichiarate per prevenire spostamenti del layout. - **Caching**: Le pagine AMP vengono memorizzate nella AMP Cache CDN di Google, che le serve dai server di Google anziché dal server di origine dell'editore. - **Validazione**: Le pagine devono superare l'AMP Validator per essere riconosciute come pagine AMP valide e ricevere il badge AMP nei risultati di ricerca. Queste restrizioni significano che funzionalità come [moduli di lead capture](/glossary/lead-capture), script di [analytics](/glossary/analytics-dashboard) personalizzati, visualizzatori di [flipbook](/glossary/flipbook) incorporati e demo di prodotto interattive non possono funzionare all'interno di una pagina AMP.

FlipLink non utilizza AMP perché il suo visualizzatore di [flipbook](/glossary/flipbook) è già ottimizzato per le prestazioni mobili senza le restrizioni imposte da AMP. I flipbook vengono serviti come pagine leggere e responsive che si caricano rapidamente su qualsiasi dispositivo. L'esperienza di sfoglio pagine basata su [Three.js](/glossary/three-js) si adatta automaticamente alle dimensioni dello schermo, e i controlli del visualizzatore di FlipLink consentono ai lettori di zoomare, scorrere le pagine e navigare con gesti touch. Funzionalità come [pulsanti CTA](/glossary/call-to-action-cta), moduli di [lead capture](/glossary/lead-capture) e analytics in tempo reale funzionano completamente su mobile — nessuna di queste sarebbe possibile nel sottoinsieme HTML vincolato di AMP. Le pagine FlipLink raggiungono ottimi punteggi Core Web Vitals grazie al [lazy loading](/glossary/lazy-loading), alla distribuzione ottimizzata delle immagini e alle risorse minime che bloccano il rendering, rendendo AMP superfluo per le prestazioni di ricerca.

AMP ha risolto un problema reale — le pagine mobile lente — ma lo ha fatto attraverso restrizioni che lo sviluppo web moderno ha superato. Gli editori che valutano la loro strategia mobile dovrebbero concentrarsi sull'ottimizzazione dei Core Web Vitals piuttosto che sull'adozione di AMP, e piattaforme come FlipLink dimostrano che esperienze mobile ricche e interattive possono caricarsi altrettanto velocemente delle pagine AMP senza sacrificare funzionalità.