Tot ce trebuie să știți despre paginile mobile accelerate ale Google

În mai 2015, Facebook și-a dezvăluit noua platformă de publicare în aplicație, Instant Articles. O lună mai târziu, Apple a declarat că vechea experiență Chioșc de ziare (în esență un folder elegant plin de aplicații de știri) va fi înlocuită în iOS 9 cu o nouă platformă de agregare și descoperire a știrilor numită Apple News.

Citiți suplimentare despre Smashing:

• Performanța percepută
• Preîncărcare: La ce este bun?
• Pregătirea pentru HTTP/2
• Îmbunătățire progresivă
• AMP-uri web progresive

Patru luni mai târziu, a venit rândul Google să-și anunțe propriul plan, oarecum întârziat, dar nu mai puțin ambițios, de a revoluționa consumul de știri pe mobil cu o soluție open-source bazată pe web numită Accelerated Mobile Pages sau AMP. În doar câteva luni, am văzut liniștea relativă a publicării digitale mobile izbucnind într-un nou război la scară largă a platformelor, deoarece Facebook, Apple și acum Google concurează atât pentru loialitatea editorilor, cât și pentru atenția cititorilor.

În timp ce Facebook și Apple au un avans semnificativ pe Google, există toate motivele să credem că AMP va ajunge rapid (și ar putea chiar depăși unul sau ambii concurenți). Dacă sunteți un dezvoltator sau un editor care trebuie să fie la curent cu de ce, ce și cum din Paginile Google Accelerated Mobile cât mai rapid și eficient posibil, vă aflați în locul potrivit.

Dar care este problema?

Înainte de a discuta soluții, merită să vă acordați un moment pentru a explora problema. Dacă citiți mult pe dispozitive mobile, sunt șanse destul de mari să fiți deja prea conștienți de faptul că interacțiunea cu conținutul web de pe un telefon sau tabletă variază de la abia acceptabil la îngrozitor. Paginile se încarcă adesea lent, sunt redate neregulat și se comportă imprevizibil din două motive principale:

• interferența terților . Anunțurile și tehnicile de urmărire aferente nu numai că adaugă solicitări în vrac și suplimentare la un dispozitiv deja limitat de lățime de bandă și CPU, dar paginile se comportă adesea ca și cum ar fi posedate în timp ce se convulsează în jurul mai multor apeluri document.write() . New York Times a efectuat recent un test care a arătat scăderi semnificative ale dimensiunilor paginilor și creșteri ale duratei de viață a bateriei după instalarea unui blocator de conținut iOS.
• daune colaterale cauzate de proiectarea receptivă . În timp ce cele mai multe site-uri web concepute cu receptivitate arată bine pe ecrane de toate dimensiunile, ele conțin adesea o mare parte din bagajul site-urilor web pentru desktop atunci când sunt vizualizate pe mobil. Când Paul Irish a efectuat un audit de performanță al Reddit, a descoperit că o mare parte din cheltuielile generale ar putea fi urmărită până la un activ numit SnooIcon, mascota Reddit redată în SVG, astfel încât să poată fi animată (de o bibliotecă terță parte, adică mai mult peste cap) la trecerea mouse-ului — nu o situație în care activele se găsesc frecvent pe dispozitive mobile.

Accesați Facebook Instant Articles, Apple News și Accelerated Mobile Pages — salvatorii noștri dintr-o lume în care, conform Facebook (PDF, 3,4 MB), timpul mediu de încărcare a unui articol pe dispozitivele mobile este de 8 secunde. În timp ce a numi 8 secunde o eternitate este în mod evident o hiperbolă, având în vedere că ai putea fi bine în al doilea videoclip Vine în acea perioadă de timp, probabil că este corect să spunem că, după standardele de astăzi, este cel puțin un eon.

O scurtă demonstrație a articolelor Facebook Instant, Apple News și Accelerated Mobile Pages. Rețineți că Facebook Instant Articles și Apple News sunt experiențe în aplicație, în timp ce AMP este în întregime bazat pe browser.

Cum este AMP diferit?

Un anumit context pentru modul în care AMP este diferit de Facebook Instant Articles și Apple News va clarifica unele dintre deciziile luate de Google pentru noua sa inițiativă de publicare digitală.

Facebook Instant Articles și Apple News au câteva caracteristici comune:

• experiențe în aplicație . Cititorii accesează Facebook Instant Articles prin Facebook pe dispozitive mobile, iar Apple News este o aplicație autonomă care vine cu iOS 9. În prezent, nicio platformă nu permite utilizatorilor să vizualizeze articole în formatele lor specifice în afara aplicației respective. Gândiți-vă la ambele ca la o reîmprospătare specifică aplicației a RSS.
• condus de sindicate . În timp ce Facebook Instant Articles și Apple News folosesc formate de sindicare foarte diferite (Apple News Format este bazat pe JSON, iar Instant Article Markup este mai mult sau mai puțin HTML împachetat într-un flux RSS), ele se bazează pe principii similare: Conduceți-vă CMS-ul să genereze formatele de sindicare necesare, iar Facebook sau Apple News îl vor înghiți, îl vor analiza și îl vor face atât frumos, cât și rapid, prin randari personalizate și optimizate.
• orientat spre experiență . Deși Facebook Instant Articles și Apple News sunt ambele axate pe performanță, ele sunt la fel de preocupate să facă articolele să arate și să se simtă moderne. Ambele platforme au componente care permit interacțiunile elegante și fluide pe care le asociem de obicei cu experiențe de lectură personalizate, construite manual.

În contrast, paginile mobile accelerate au un accent distinct:

• experiență bazată pe web . Documentele AMP sunt concepute pentru a fi redate fie în browser, fie în WebViews.
• documente atomice . Deși documentele AMP sunt validate, analizate și parțial redate de AMP runtime (multe mai multe despre asta mai jos), ele sunt documente complete și independente care trăiesc pe propriul dvs. server web (și, opțional, într-un cache CDN), mai degrabă decât colecții de metadate care vor fi la un moment dat transformate în articole și redate în aplicații.
• orientat spre performanță . AMP îi pasă mult mai mult de performanța documentelor AMP decât de estetică sau modele de interacțiune. Asta nu înseamnă că documentele AMP sunt în mod inerent familiare (pot fi la fel de atractive ca articolele Facebook Instant sau Apple News cu stilul potrivit), dar timpul de execuție este mult mai preocupat de a face un articol să fie randat rapid decât de a oferi efecte vizuale fanteziste, cum ar fi lucruri mici și nebunești.

Ce este AMP exact?

Destul de filosofare și fluturare de mână la nivel înalt. Să intrăm în detalii. În timp ce înțelegerea articolelor Facebook Instant și Apple News este destul de ușoară (sunt, în esență, agregatoare de știri luxoase, cu randare personalizate construite pe baza formatelor de sindicare proprietare), AMP este situația anormală. Este puțin mai greu de înțeles, din două motive:

• Nu există un model simplu cu care să-l comparăm. Când RSS era nou, ne-am minunat cu toții de puterea sa, am scris nenumărate articole și postări pe blog despre potențialul său perturbator, am declarat pagina de pornire moartă (din nou) și apoi am uitat totul despre ea. Facebook Instant Articles și Apple News sunt, în esență, o repornire RSS, cu excepția faptului că eliberează toate inconvenientele standardelor și fiecare se întâmplă să funcționeze într-o singură aplicație.
• AMP nu este un client. . În timp ce Facebook Instant Articles, Apple News și AMP au mai multe elemente în comun, cum ar fi formatele de sindicare proprietare și randarele personalizate, AMP este singurul care nu are un client dedicat (altul decât browserul). Mai mult decât frații săi, AMP este un set de specificații, convenții și tehnologii care pot fi combinate într-o soluție, mai degrabă decât să fie o soluție end-to-end (de la editor la cititor) în sine.

Acum că știm să ne gândim la AMP ca la o colecție de ingrediente, mai degrabă decât la un tort copt complet, să ne uităm la care sunt acele componente individuale:

• HTML AMP,
• timpul de rulare AMP,
• memoria cache AMP.

HTML AMP

Documentele AMP sunt scrise în HTML, dar nu în orice HTML. Unele etichete sunt interzise, ​​în timp ce sunt introduse câteva etichete noi (parțial pentru a le înlocui pe cele interzise și parțial pentru a încapsula funcționalitatea interactivă). Vă puteți gândi la AMP HTML ca la felul în care ar arăta HTML dacă ar fi fost conceput doar cu performanța mobilă în minte (spre deosebire de a fi introdus cu 14 ani înainte de introducerea iPhone-ului).

Deoarece AMP HTML este conceput pentru performanțe optime, pentru a înțelege și a aprecia valoarea acestuia, trebuie să înțelegem problemele pe care le rezolvă. Iată cele mai mari trei lucruri care afectează încărcarea și redarea paginilor web pe dispozitivele mobile:

• dimensiunea sarcinii utile . Designul web responsive ne-a servit bine, deoarece ne permite să construim un singur site web pentru fiecare dispozitiv și ecran. Dar, uneori, asta înseamnă și livrarea de încărcături utile de dimensiunea desktopului (HTML, JavaScript, CSS și active) pe dispozitive mobile extrem de limitate de lățime de bandă și CPU. (Cei care consideră că telefoanele lor sunt niște mici computere desktop acordă hardware-ului mobil mult prea mult credit. iPhone-ul tău 6s are 2 GB de RAM, în timp ce laptopul tău are probabil 8 sau 16.)
• încărcarea resurselor . Resursele nu sunt încărcate întotdeauna în ordinea optimă, ceea ce înseamnă că lățimea de bandă, CPU și RAM sunt adesea dedicate activelor pe care utilizatorii nu le vor vedea niciodată. În plus, resursele nu își declară frecvent lățimile și înălțimile (mai ales atunci când sunt difuzate prin rețele publicitare sau injectate prin apeluri document.write() ), ceea ce nu numai că face ca pagina să se redimensioneze pe măsură ce dimensiunile resurselor sunt determinate leneș, dar și declanșează inutil. și recalculări costisitoare de aspect. Acesta este ceea ce face ca paginile web să sară ca niște pisoi care urmăresc laserul, pe măsură ce se manifestă mereu atât de leneș.
• Execuția JavaScript . Nu sunt pe cale să abordez aici subiectul performanței JavaScript, dar site-urile web moderne o adună adesea cu megaocteți și, deși s-ar putea executa fără nicio latență vizibilă pe computerele desktop, mobilul este încă un mediu foarte diferit, în care, cred putem fi cu toții de acord, JavaScript este cel mai bine menținut la minimum.

Având în vedere aceste trei bariere în calea experiențelor web fluide pe dispozitivele mobile, HTML AMP există în principal pentru trei scopuri:

• încurajează concizia . Documentele AMP nu sunt versiuni responsive ale site-urilor web desktop. În timp ce documentele AMP pot fi (și de obicei sunt) receptive, ele sunt receptive într-un context mobil. Cu alte cuvinte, mai degrabă decât o singură pagină care funcționează absolut peste tot (desktop și mobil), documentele AMP sunt concepute special pentru a funcționa bine pe dispozitivele mobile.
• controlează încărcarea resurselor externe . Runtime-ul AMP controlează încărcarea resurselor externe pentru a se asigura că procesul este extrem de eficient, rezultând conținut care apare pe ecranele utilizatorilor cât mai rapid și inteligent posibil.
• încapsulează funcționalitatea interactivă . Deși documentele AMP tind să ajungă direct la afacerea de a prezenta cititorilor experiențe de lectură simple, asta nu înseamnă că nu pot fi moderne și interactive. Timpul de execuție AMP oferă funcționalitate încapsulată prin JavaScript extrem de optimizat, astfel încât dezvoltatorii să nu riscă să împiedice performanța scriind propria lor.

Etichete HTML AMP

Mai jos este o listă de etichete care sunt complet interzise în HTML AMP:

• script Acesta este, evident, unul mare. Voi oferi mai multe detalii despre poziția AMP pe JavaScript mai jos; deocamdată, presupuneți doar că singurele etichete de script pe care le veți avea în documentele dvs. AMP sunt cele care încarcă timpul de execuție AMP și, opțional, o etichetă pentru datele conectate bazate pe JSON.
• base Eticheta base pare să fie interzisă din abundență de precauție și ar putea ajunge pe lista albă dacă comunitatea se plânge. (Bănuiala mea este că nimănui nu-i pasă cu adevărat într-un fel sau altul.)
• frame și frameset de cadru Oricum, nu este o utilizare bună a proprietății mobile mobile, așa că o eliberare bună.
• object , param , applet and embed Din păcate, documentele dvs. AMP nu vor conține niciun applet Flash sau Java. (A fost sarcasm, în caz că nu era complet evident.)
• elemente de form și de input (cu excepția etichetei button ) Suportul de formular va fi probabil implementat în cele din urmă ca componente încapsulate, deoarece sunt de utilizare limitată fără scripting.

Acum, iată o listă de etichete care înlocuiesc omologii lor HTML pentru a optimiza încărcarea resurselor și pentru a aplica cele mai bune practici de securitate:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Înlocuiește eticheta img și optimizează încărcarea resurselor ținând cont de factori precum poziția ferestrei de vizualizare, resursele sistemului și conectivitatea.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Înlocuiește eticheta video HTML5, astfel încât conținutul video poate fi încărcat leneș (ținând cont de fereastra de vizualizare).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Înlocuiește eticheta audio HTML5, astfel încât conținutul audio să poată fi încărcat leneș (ținând cont de fereastra de vizualizare).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) Eticheta amp-iframe impune cele mai bune practici de securitate făcând lucruri precum sandboxingul de conținut în mod implicit și plasând restricții asupra unde iframe-urile pot apărea pentru a se asigura că nu domină un document AMP.

În cele din urmă, iată toate etichetele pe care AMP HTML le introduce pentru a adăuga funcționalitate sau interactivitate documentelor dvs., fără a fi necesar să scrieți JavaScript:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) Eticheta amp-ad permite rulării AMP să gestioneze încărcarea anunțurilor la fel ca toate celelalte resurse încărcate extern (în prezent , anunțurile sunt încărcate ultimele) și se asigură că JavaScript din rețelele publicitare nu se poate executa în documentul AMP părinte sau nu poate declanșa calcule de aspect inutile. (La revedere, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Acest cadru miniatural împachetează date de analiză și le trimite furnizorilor terți. Începând de astăzi, suportul AMP vine de la Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen și Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Acesta este folosit pentru încorporarea web beacon-urilor și acceptă token-uri pentru trimiterea mai multor variabile client către server.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Această componentă optimizată afișează imagini copil într-o orientare interactivă, orizontală.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Acest lucru permite cititorilor să deschidă imagini într-o vizualizare „lightbox” pe ecran complet. Acceptă specificarea atât a imaginilor în miniatură, cât și a imaginilor la dimensiune completă.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) Acesta încarcă GIF-uri animate și oferă funcționalitatea de substituent foarte necesară.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Setați un timeout de încărcare pentru fonturile personalizate și specificați fonturi de rezervă dacă fonturile dvs. personalizate nu se încarcă în timpul alocat .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) Textului dintr-o etichetă amp-fit-text i se va atribui automat o dimensiune de font optimizată pentru spatiul disponibil. Gândiți-vă la asta ca la o mică capacitate de răspuns preambalată.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) Cu eticheta amp-list , puteți încărca date JSON dinamice, repetate și apoi le puteți reda folosind un HTML șablon. (Vezi mai jos eticheta amp-mustache .)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Aceasta acceptă redarea șabloanelor HTML Mustache.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Dacă alegeți să nu utilizați un cache AMP (mai multe despre stocarea în cache mai jos), Eticheta amp-install-serviceworker încarcă și instalează un service worker pentru pagina curentă. Lucrătorii de la service sunt șmecheri, dar în opinia mea este puțin prea devreme să mă bazez pe ei.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) În mod previzibil, aceasta încorporează videoclipul YouTube cu ID-ul video specificat.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Încorporați tweet-uri (carduri Twitter opționale).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Încorporați imagini Instagram.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Această componentă încarcă și afișează videoclipuri (și un player video) de la Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) Încorporați un widget Pinterest sau butonul „Pin it”, în documentul dvs. AMP.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Încorporați videoclipul Vine specificat în documentul dvs. AMP.

Rețineți că, deși etichetele cu prefix amp- nu sunt tocmai HTML standard, ele nu sunt nici proprietare. Mai degrabă, sunt elemente personalizate legitime cu implementări JavaScript care fac lucruri precum aplicarea celor mai bune practici de securitate și prioritizează încărcarea resurselor de la distanță (mai multe despre asta în secțiunea „AMP Runtime” de mai jos). Cu alte cuvinte, în timp ce HTML AMP ar putea arăta în mod suspect ca strategia de îmbrățișare, extindere și stingere, este într-adevăr doar o aplicare inteligentă a standardelor web și nu atât de diferită de atributele personalizate de data- .

Stilizarea HTML AMP

Stilizarea documentelor AMP se face cu CSS standard și nu diferă mult de modul în care stilați deja conținutul. Cu toate acestea, rețineți câteva lucruri:

• Toate stilurile trebuie realizate cu o foaie de stil inline - fără foi de stil legate extern și fără stiluri inline la nivel de element. (O foaie de stil conectată extern ar necesita descărcarea unui document suplimentar înainte ca aspectul să poată fi calculat, iar stilurile la nivel de element în linie ar putea umfla documentul.)
• Stilurile sunt limitate la 50 KB. Filosofia Google este că 50 KB este suficient pentru un document sau articol frumos, dar nu suficient pentru un site web frumos.
• Foaia de stil inline trebuie să aibă atributul amp-custom (adică <style amp-custom> ).
• Regulile @ — @font-face (mai multe despre fonturi de mai jos), @keyframes și @media — sunt permise.
• Unele selectoare au limitări despre care se știe că provoacă performanța, cum ar fi selectorul universal ( * ) și selectorul :not() .
• Calificatorul !important este interzis pentru a se asigura că runtime-ul AMP are ultimul cuvânt despre dimensionarea elementelor.
• Stilizarea componentelor AMP personalizate, cum ar fi amp-carousel se realizează prin suprascrierea claselor implicite, cum ar fi .amp-carousel-button-prev , sau prin utilizarea unui set predefinit de proprietăți personalizate CSS, cum ar fi --arrow-color .
• Toate resursele încărcate extern trebuie să aibă proprietăți de lățime, înălțime și aspect specificate (mai multe despre aspectul de mai jos) pentru a minimiza recalculările costisitoare ale aspectului DOM.
• Sunt permise tranzițiile și animațiile care pot fi accelerate de GPU (și care nu declanșează recalculări). În prezent, opacity și transform sunt incluse pe lista albă.

Pentru detalii suplimentare despre documentele de stil, consultați specificația HTML AMP.

Fonturi

AMP acceptă cu plăcere fonturi personalizate, cu câteva calificări:

• Fonturile trebuie să fie încărcate cu o etichetă de link sau cu o regulă CSS @font-face . Cu alte cuvinte, nu puteți încărca fonturi folosind JavaScript.
• Toate fonturile trebuie să fie difuzate prin HTTPS.
• Furnizorii de fonturi trebuie să fie incluși pe lista albă. În prezent, singurii furnizori incluși în lista albă sunt fonts.googleapis.com și fast.fonts.net . Dar, având în vedere cât de repede editorii, agenții de publicitate și furnizorii de analize adaugă suport pentru AMP, bănuiesc că vor urma mai multe în curând.

Aspect

Abordarea AMP a aspectului a fost concepută în jurul a două obiective principale:

• Timpul de execuție trebuie să poată deduce dimensiunea tuturor resurselor încărcate extern înainte de a fi încărcate efectiv, astfel încât un aspect final să poată fi calculat cât mai repede posibil. Odată calculată aspectul, articolul poate fi redat și cititorii pot începe să interacționeze cu acesta, chiar dacă reclamele, imaginile, audio și video nu s-au finalizat încă de încărcare. (Și, pe măsură ce aceste resurse se încarcă, ele vor reda perfect, fără a perturba experiența de citire prin actualizarea aspectului documentului.)
• Articolele AMP ar trebui să fie adaptabile. După cum sugerează numele „Accelerated Mobile Pages”, documentele AMP sunt destinate în mod special dispozitivelor mobile; deci, în acest context, „responsive” nu include rezoluțiile desktop. Mai degrabă, documentele AMP ar trebui să arate bine pe toate dispozitivele mobile, de la acele relicve vechi iPhone 4 pe care oamenii încă le folosesc până la iPad Pros relativ gigante.

Primul obiectiv este atins în primul rând prin cerința ca toate resursele încărcate extern să aibă atribute de width și height (și este impus în continuare prin limitarea scripturilor, ceea ce asigură că noile resurse nu pot fi introduse). Acesta din urmă este realizat prin interogări media standard, atributul media , atributul sizes și atributul layout specific AMP.

Mai jos este o prezentare generală a aspectelor pe care AMP le acceptă în prezent:

• nodisplay Elementul nu este afișat inițial, dar afișarea poate fi declanșată de o acțiune a utilizatorului. (Acest lucru este utilizat împreună cu componente precum amp-lightbox .)
• fixed Elementul are o lățime și o înălțime fixe, ceea ce înseamnă că timpul de execuție nu poate aplica niciun comportament receptiv.
• responsive După părerea mea, aceasta este cea mai utilă și mai magică dintre opțiunile de aspect ale AMP. Elementul folosește orice spațiu alocat, păstrând în același timp raportul de aspect. (Practic, „Fă ca acest lucru să arate bine la orice rezoluție, te rog și mulțumesc.”)
• fixed-height Elementul folosește spațiul alocat, dar menține o înălțime fixă ​​(scalare pe orizontală).
• fill Elementul umple containerul în care se află, indiferent de raportul de aspect. (Gândiți-vă la width: 100% și height: 100% ).
• container Elementul este un container și, prin urmare, îi permite copiilor săi (spre deosebire de părintele) să-și definească dimensiunea, exact ca un element div standard.

Realizarea unui aspect funcțional și simplu de document folosind sistemul de aspect al AMP este relativ ușoară, dar când luați în considerare tot ceea ce acceptă și modul în care valorile se aplică diferitelor tipuri de elemente, există o cantitate destul de mare de nuanță. Pentru o defalcare mult mai detaliată, consultați specificația aspectului AMP.

Dar SVG?

Sprijinit! SVG de bază se bucură de suport complet atât în ​​browserele desktop, cât și în cele mobile, iar grafica nu devine mult mai receptivă decât vectorii, așa că AMP și SVG formează o echipă foarte bună. Cea mai mare limitare este că, din cauza restricțiilor de scriptare, nu veți putea să vă animați vectorii cu JavaScript - ceea ce, dacă suntem sinceri, probabil că oricum nu ar trebui să faceți pe mobil. Cu toate acestea, dacă într-adevăr trebuie să dai puțină viață SVG-ului tău, poți în continuare să faci asta folosind animații CSS, conform acelorași constrângeri prezentate în secțiunea de stil de mai sus. Amintiți-vă că SVG este o parte a DOM, așa că poate fi stilat - și animat - la fel de ușor ca orice alt element.

Filosofia AMP despre JavaScript

Vești bune și vești proaste aici. Vestea proastă este că nu veți scrie în curând niciun JavaScript pentru documentele dvs. AMP. Dar, într-un fel, aceasta este și vestea bună. Rețineți că AMP nu este un cadru pentru aplicații mobile. Mai degrabă, este un cadru mobil pentru articole și, deoarece articolele ar trebui optimizate pentru experiențe de lectură fluide și fluide, nu există într-adevăr o mulțime de cazuri bune de utilizare pentru scripturi grele pe partea clientului.

Acestea fiind spuse, interzicerea tuturor JavaScript pentru totdeauna este atât nerealistă, cât și puțin draconiană. Realitatea este că web-ul se bazează de ceva timp pe JavaScript - chiar și în contextul unor experiențe de lectură simple și relativ blânde - pentru lucruri precum publicitate, analiză și funcții interactive. În plus, unul dintre cele mai bune lucruri despre web este deschiderea și capacitatea sa aparent infinită de experimentare, expresivitate și creativitate - dintre care o mare parte este alimentată de JavaScript.

Recunoscând atât povara pe care JavaScript arbitrar, scris de utilizator o pune pe garanțiile de performanță, cât și omniprezența și inevitabilitatea JavaScript într-un mediu web modern, echipa AMP a venit cu următoarele principii de scripting:

• Niciun JavaScript scris de utilizator nu este acceptat sau permis în acest moment. Este posibil să aveți doar două tipuri de etichete de script în documentele dvs. AMP: etichete de date legate (al căror tip este application/ld+json ) și etichete pentru includerea atât a componentelor de rulare AMP, cât și a componentelor AMP extinse.
• Autorii proiectului AMP au anticipat majoritatea nevoilor de JavaScript în contextul consumului de articole mobile, așa că AMP fie acceptă alternative ( amp-pixel , inclusiv fonturi personalizate cu etichete de link sau reguli @font-face etc.) sau furnizează implementări care sunt compatibile cu runtime-ul AMP și care, prin urmare, garantează atât securitatea, cât și performanța ( amp-ad , amp-analytics , amp-carousel , etc.).
• Dacă într-adevăr trebuie să utilizați JavaScript pentru ceva ca o caracteristică interactivă, puteți crea caracteristica independent și apoi o puteți include cu un [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) etichetă [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . Conținutul inclus într-un amp-iframe este permis chiar și o comunicare limitată cu documentul părinte pentru lucruri precum solicitările de redimensionare.
• Componentele AMP sunt open source (Apache 2) și deschise contribuțiilor, astfel încât noi componente vor apărea în timp (de fapt, mai multe componente noi au apărut pe parcursul scrierii și editării acestui articol, așa că am actualizat deja de câteva ori). În timp ce echipa AMP va acorda prioritate componentelor generalizate față de funcționalitatea specifică serviciului (un widget special pentru startup-ul tău social, de exemplu), se angajează, de asemenea, să ofere suficientă diversitate pentru a găzdui cea mai largă gamă de conținut posibil.
• În cele din urmă, toate aceste politici pot fi modificate. Pe măsură ce funcțiile browserului, cum ar fi lucrătorii web, elementele personalizate și DOM-ul umbră devin mai larg acceptate, opțiunile pentru suportul JavaScript scris de utilizator și componentele personalizate - garantând în același timp securitatea și performanța - se vor extinde dramatic.

Pentru mai multe informații despre viitorul componentelor AMP, consultați secțiunea „Componente extinse” din specificația „Componente HTML AMP”.

Anatomia unui document AMP

Acum că aveți o înțelegere destul de solidă a HTML-ului AMP, să dezvăluim un boilerplate.

Desigur, veți începe documentele AMP cu o declarație doctype :

 <!doctype html>

Apoi, desemnați documentul dvs. HTML ca HTML AMP, ceea ce, credeți sau nu, îl faceți folosind emoji-ul de înaltă tensiune ca atribut în eticheta html :

 <html >

Sau, dacă sunteți un nebun de modă veche și vă simțiți la ideea de a vă împodobi codul cu emoji-uri adorabile, puteți utiliza în schimb atributul amp mult mai conservator:

 <html amp> <!-- A good sign that you're boring! -->

În eticheta head , nu uitați de instrucțiunile de codificare a caracterelor utf-8 :

 <meta charset="utf-8">

Și trimiteți la versiunea non-AMP a documentului dvs. (marcat ca canonical , astfel încât să nu apară ca conținut duplicat):

 <link rel="canonical" href="my-non-amp-index.html">

În schimb, versiunea dvs. non-AMP ar trebui să conțină o referință la documentul AMPlified:

 <link rel="amphtml" href="my-amp-index.html">

Deoarece paginile AMP sunt destinate dispozitivelor mobile (și doriți și rasterizarea GPU), asigurați-vă că includeți o etichetă meta viewport :

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

Următoarea linie de cod va părea puțin ciudată și asta pentru că este. Știți cum veți vedea uneori o pagină web redată pentru scurt timp de text înainte ca fonturile să fi fost încărcate și aplicate, apoi veți pâlpâi și redați din nou arătând așa cum a intenționat designerul? Eticheta de mai jos menține opacitatea paginii la 0 (invizibilă) până când este stilată corect.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Problema acestei abordări este că, în cazul în care timpul de execuție AMP nu se încarcă, este posibil din punct de vedere tehnic ca opacitatea paginii să nu treacă niciodată de la 0 la 1 . Pentru a compensa astfel de situații neprevăzute, codul de mai sus va fi probabil modificat în ceva mai apropiat de acesta:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

Următorul lucru de făcut este să includeți timpul de execuție JavaScript AMP:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

Și includeți implementările JavaScript pentru componentele extinse de care aveți nevoie:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Rețineți utilizarea atributului async . Aceasta nu este opțională - cu cât se blochează mai puțin, cu atât mai bine.)

Opțional, puteți presăra câteva date legate, astfel:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Acum să adăugăm câteva fonturi, folosind fie etichete de link , fie reguli @font-face în CSS:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

Și apoi vom avea câteva stiluri (nu mai mult de 50 KB), cu atributul amp-custom necesar:

 <style amp-custom>

Acum sunteți gata să creați un document HTML mai mult sau mai puțin standard folosind tot ce tocmai ați învățat despre HTML AMP.

Timpul de rulare AMP

Nu voi petrece atât de mult timp pe runtime AMP pentru că, la fel ca toate runtime, este un pic o cutie neagră. Asta nu înseamnă că runtime-ul AMP este inaccesibil (este open source, ca și restul proiectului). Mai degrabă, la fel ca toate runtimele bune, dezvoltatorii nu trebuie să știe exact cum funcționează pentru a profita de el, atâta timp cât înțeleg în general ce face.

Timpul de rulare AMP este implementat în întregime în JavaScript și este inițiat prin includerea acestuia în documentul AMP, așa cum ați proceda pentru orice fișier JavaScript extern:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

De acolo, runtime-ul AMP face în primul rând trei lucruri:

• gestionează încărcarea resurselor și prioritizarea,
• implementează componente AMP,
• opțional, include un validator de rulare pentru HTML AMP.

Validatorul este esențial pentru a crea documente conforme cu AMP. Poate fi activat pur și simplu adăugând #development=1 la adresa URL a documentului. Apoi, tot ce trebuie să faci este să deschizi consola pentru a vedea buletinul.

Erorile arată astfel:

Un document AMP frumos, curat și compatibil arată cam așa:

Cache-ul AMP (opțional).

Documentele AMP pot fi difuzate de pe un server web ca orice alt document HTML, dar pot fi servite și dintr-un cache AMP special. Cache-ul opțional folosește mai multe tehnici pentru a optimiza și mai mult un document AMP:

• Referințele de imagine pot fi înlocuite cu imagini dimensionate special pentru fereastra de vizualizare a vizualizatorului.
• Imaginile de deasupra pliului pot fi aliniate pentru a salva solicitări HTTP suplimentare.
• Variabilele CSS pot fi integrate pentru a reduce costul general al clientului.
• Implementările extinse ale componentelor AMP pot fi preîncărcate.
• HTML și CSS pot fi reduse pentru a reduce numărul de octeți trimiși prin cablu (sau, în acest caz, undele).

Oricine își poate rula propriul cache AMP pe propriul CDN, sau editorii pot folosi gratuit Google. Având în vedere că Google pare să știe ceva despre scalabilitate, bănuiesc că majoritatea utilizatorilor AMP vor fi bucuroși să accepte această ofertă. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Resurse aditionale

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11