AMP è un argomento sulla cresta dell’onda. Tra operatori del settore e non sembra che non si parli d’altro, ma le pagine accelerate di Google sono veramente la soluzione a tutti i problemi del web?

P

er chi non le conoscesse, le Accelerated Mobile Pages (AMP) nascono da un progetto open source di Google per rendere la navigazione mobile più veloce, quasi istantanea. Esistono già da un po’, ma il grosso della comunità di sviluppatori e web designer sembra scoprirle solo ora e sul web praticamente non si parla d’altro.

Tuttavia Patrick Stox di Searchengineland.com prova a mettere in discussione la validità di AMP. Fondamentalmente si domanda: “Se sai che il tuo sito web ha dei problemi che lo rendono lento, perché non risolvi i problemi invece di investire risorse nel passare a AMP?“. E come dargli torto?

La cosa però che fa la differenza è un’altra. Cominciamo con elencare i principi su cui si basano le pagine AMP:

• Esecuzione asincrona dei Javascript AMP
• Le risorse vengono dimensionate staticamente
• Le estensioni non bloccano il rendering
• Tutti i Javascript di terze parti vengono caricati dopo le risorse primarie
• I CSS devono essere inline
• Massima efficienza del font triggering
• Minimizzare il ricalcolo degli stili
• Le animazioni vengono tutte calcolate dalla GPU
• Priorizzare il caricamento delle risorse
• Caricare le pagine in un istante

Si capisce come vengano messe in atto tutta una serie di tecniche per rendere il caricamento istantaneo. Ma a Stox questo non basta e testando una buona quantità di siti si rende conto che in realtà il nocciolo della questione non è realmente la velocità, ma quella percepita, frutto in gran parte del pre-rendering. Ovvero: i siti fatti con AMP non sempre sono più veloci delle corrispettive pagine non fatte con AMP, ma la velocità percepita tende sicuramente a favorire queste ultime.

Il pre-rendering, da questo punto di vista, è fondamentale, mostrando quasi istantaneamente la pagina e dando una gradevole sensazione di velocità. Fondamentale in questo senso è un brano tratto dal sito per sviluppatori Apple, dove si dice:

Take Advantage of Perceived Performance
The perception of performance is just as effective as actual performance in many cases. Many program tasks can be performed in the background, using a dispatch queue, or at idle time. Doing this keeps the application’s main thread free to handle user interactions and makes the program interface feel more responsive to the user. As you design your program, think about which tasks can be moved to the background effectively. For example, if your program needs to scan a number of files or perform lengthy calculations, do so using a dispatch queue.

Another way to improve perceived performance is to make sure your application launches quickly. At launch time, defer any tasks that do not contribute to the immediate presentation of your application interface. For example, defer the creation of large data structures until after your application has finished launching and displayed its main window. If you use your main window to display some data that must be calculated or retrieved at launch time, show the window first along with a progress indicator or other status message indicating that the data is being loaded. For applications that use plug-ins, avoid loading plug-ins until their code is actually needed.

Quindi la domanda che si pone Stox è: AMP è un’enorme bugia? Diciamo più una mezza verità, ma il risultato è che gli utenti percepiscono realmente una maggiore velocità e dunque il risultato viene raggiunto. A cosa servirebbe la velocità se non ad andare incontro ai desideri dell’utente?

Ascolta questo articolo nel podcast WebMarketing a colazione

FONTE: Searchengineland.com