Wat is AMP?
• AMP staat voor Accelerated Mobile Pages Project (AMP)
• AMP is een open source-project dat momenteel wordt geleid door Google om snellere mobiele pagina’s te maken
Amp optimalisaties
In plaats van het AMP-project zelf te beschrijven, gaat dit artikel in op de belangrijkste optimalisaties die AMP gebruikt om snellere pagina’s te maken. In dit artikel wordt uitgebreid uitgelegd waarom en hoe pagina’s zo snel worden geladen met AMP. De meeste van deze optimalisaties kunnen worden gebruikt, zelfs als u niet van plan bent AMP te implementeren, en kunnen worden beschouwd als een strengere dan normale reeks optimalisaties voor paginasnelheid. Als u overweegt AMP te gebruiken, kunnen deze beschrijvingen u helpen de principes te begrijpen die ervoor zorgen dat AMP werkt, zodat u beter kunt begrijpen hoe u deze kunt bereiken.
We zullen de volgende principes van AMP bespreken:
- Sta alleen asynchrone scripts toe
- Maak een statische grootte van alle bronnen
- Laat extensiemechanismen de weergave niet blokkeren
- Houd alle JavaScript van derden buiten het kritieke pad
- Alle CSS moeten inline en formaatgebonden zijn
- Het triggeren van lettertypen moet efficiënt zijn
- Minimaliseer herberekeningen van stijlen
- Voer alleen GPU-versnelde animaties uit
- Geef prioriteit aan het laden van bronnen
- Laad pagina’s in een oogwenk
- Sta alleen asynchrone scripts toe
Dit verwijst naar het javascript dat door uw HTML wordt gebruikt of aangeroepen.
Als javascript niet wordt uitgesteld of asynchroon wordt gemaakt, zal het vertragen dat de webpagina op tijd wordt bekeken. Javascript dat niet wordt uitgesteld of asynchroon wordt genoemd, wordt JavaScript-blokkering van het renderen genoemd en is een van de meest voorkomende problemen met paginasnelheid waarmee het internet tegenwoordig te maken heeft.
Wat is asynchroon javascript?
Wanneer een javascript als async wordt gedeclareerd, vertelt het de browser dat de uitvoering van dit javascript niet belangrijk is voor de paginaweergave. De browser begrijpt dan dat hij niet hoeft te wachten tot dit javascript de pagina opbouwt. Terwijl de pagina wordt geladen, kan het javascript worden gestart, maar het blokkeert de weergave van de pagina niet. Om ervoor te zorgen dat geen javascript wordt geblokkeerd, staat AMP geen javascript toe dat niet asynchroon is. Zelfs als u AMP niet gebruikt of niet van plan bent, is dit een zeer wenselijk doel. Hoe javascript asynchroon te maken?
In de meeste gevallen zullen er oproepen zijn naar externe javascripts die er ongeveer zo uitzien.
Om dat externe javascript asynchroon te maken, zouden we als volgt “async” aan de oproep toevoegen.
Dat lijkt makkelijk, toch?
Helaas werken veel aspecten van een webpagina mogelijk niet correct wanneer het javascript asynchroon wordt aangeroepen. Webpagina’s moeten met dit in gedachten worden gebouwd, een bekend voorbeeld hiervan kan een bibliotheek zoals jQuery zijn.
Als er javascripts zijn die afhankelijk zijn van jQuery, betekent dit dat jQuery moet worden geladen voorafgaand aan de javascripts die erop vertrouwen. In dat geval zal het gebruik van async op alle javascripts ertoe leiden dat dingen kapot gaan of niet of niet correct worden weergegeven op de webpagina wanneer deze wordt geladen.
Of je AMP nu gebruikt of niet.
• Een goed gemaakte, performante pagina zou hopelijk nooit vertrouwen op het blokkeren van javascript
• Als u javascript van een derde partij heeft “gekopieerd en geplakt” op uw website (zoals een SEO-tool of analytische tool), moet u ervoor zorgen dat het asynchroon kan werken en als dit niet het geval is, moet u een klacht indienen bij de derde partij om het te maken zo.
• Als u javascript van derden verstrekt zodat mensen deze in hun websites kunnen “kopiëren en plakken”, dan zou het asynchroon moeten kunnen werken, anders wordt uw tool of service niet meer gebruikt door degenen die zich bezighouden met paginasnelheid en web prestaties (wat zo ongeveer iedereen is).
Maak een statische weergave qua grootte, van alle bronnen
De Amp-documentatie beschrijft dit door te zeggen.
“Externe bronnen, zoals afbeeldingen, advertenties of iframes, moeten hun grootte in de HTML vermelden, zodat AMP de grootte en positie van elk element kan bepalen voordat bronnen worden gedownload. AMP laadt de lay-out van de pagina zonder te wachten tot bronnen zijn gedownload.”
Dit kan tot enige verwarring leiden omdat de meeste mensen die dat lezen zouden denken dat een afbeelding een expliciete grootte moet vermelden, zoals (breedte = 100 hoogte = 200) of iets dergelijks.
De waarheid is echter dat dit niet precies is wat ze bedoelen.
Hoe werken formaten in AMP?
In Amp zijn er speciale gevallen die worden gebruikt voor advertenties, afbeeldingen, video’s en iframes (dingen die de grootte van een lay-out kunnen verknoeien). In de meeste gevallen zijn er expliciete maten opgegeven voor deze dingen, maar die maten worden gebruikt om de beeldverhouding van het item te krijgen, zodat ze responsief kunnen worden weergegeven.
Om dit probleem beter te illustreren, zou het goed zijn om te kijken naar het probleem dat ze proberen op te lossen.
Wanneer een webpagina wordt weergegeven, zijn er vaak veel herberekeningen van stijlen bij betrokken. Dit betekent dat er veel werk wordt verzet dat niet zou hoeven gebeuren als de browser de grootte van iets begreep voordat het werd gedownload.
Wanneer een afbeelding wordt opgeroepen vanaf een webpagina zonder informatie over de grootte, moet de browser de afbeelding downloaden om te weten hoe groot de afbeelding is.
Nadat de afbeelding is gedownload, moet de browser de pagina aanpassen om de afbeelding weer te geven.
• Browser bevat pagina
• Afbeelding wordt opgeroepen zonder maatinformatie
• Afbeelding is gedownload
• Browser krijgt afbeeldingsgrootte
• De browser berekent alles op de pagina opnieuw zodat de afbeelding kan worden gezien
Als de browser de grootte van de afbeelding zou kennen, zou de bovenstaande reeks stappen worden teruggebracht tot.
• Pagina met browserlay-outs
• Afbeelding is gedownload en correct weergegeven op een vooraf berekende plaats
Door deze stappen te verminderen, kan de pagina aanzienlijk sneller worden geladen (vooral voor pagina’s met veel afbeeldingen, advertenties, enz.).
Hoe doet AMP dit?
Door speciale tags zoals te hebben, kan AMP begrijpen dat een opgegeven grootte van een afbeelding als richtlijn moet worden gebruikt in plaats van een absoluut strikte en expliciete grootte waarin de afbeelding moet worden weergegeven.
Hoe kan dit zonder AMP worden gedaan?
Dit kan worden bereikt door een geplande responsieve beeldoplossing te hebben. Het gebruik van srcset wordt steeds meer ondersteund door browsers.
Welke techniek u ook gebruikt, vergeet deze zeer eenvoudige en onderbenutte no brainer niet:
Als een afbeelding kleiner is dan 50 pixels of zo, is het waarschijnlijk prima om deze expliciet te vergroten door middel van breedte en hoogte.
Dit zal voor een verrassend aantal van uw afbeeldingen werken. Als we de pagina die u nu leest als voorbeeld gebruiken, worden de foto’s van mijn auteurs expliciet op maat gemaakt met behulp van hoogte en breedte in de afbeeldingstag. Dit komt omdat ze zo klein zijn dat ze niet echt worden verkleind door een browser.
Als afbeeldingen niet onder een bepaalde breedte worden weergegeven, kunt u hier waarschijnlijk ook explicietere afbeeldingsformaten aangeven.
Laten we zeggen dat we een zijbalk hebben die alleen wordt weergegeven als een pagina breder is dan 1000 pixels. Als de afbeeldingen in die zijbalk zo zijn gepland dat ze altijd dezelfde grootte hebben, ongeacht hoeveel breder het scherm wordt, dan is er geen reden om er geen ouderwetse breedte en hoogte aan toe te voegen.
Laat extensiemechanismen de weergave niet blokkeren
Dit is een ander voorbeeld van het terugkerende thema van het optimaliseren van het kritieke weergavepad.
Wat zijn uitbreidingsmechanismen?
In de AMP-documentatie worden als voorbeelden gebruikt: lichtbakken, instagram-insluitingen en tweets. Extensiemechanismen gebruiken een deel van een lay-out om onbekende dingen erin weer te geven waarvoor aanvullende HTTP-verzoeken nodig zijn. Dit soort dingen veroorzaken vaak dezelfde problemen als afbeeldingen als het gaat om de grootte waarin ze worden weergegeven, en in tegenstelling tot een afbeelding zullen er waarschijnlijk veel gecompliceerdere dingen aan de hand zijn wat de lay-out betreft. Idealiter zouden de http-verzoeken voor de lay-out en inhoud die in dergelijke dingen worden gevonden, de weergave van de pagina niet moeten blokkeren. Met andere woorden, de webpagina zelf moet als eerste worden weergegeven en pas daarna moeten deze andere dingen zich zorgen maken. Een voorbeeld is een webpagina met een advertentie. De webpagina moet eerst worden geladen, daarna de advertentie. De webpagina-weergave zou niet moeten wachten op de ingesloten dingen.
Hoe wordt dit afgehandeld in AMP?
In AMP wordt dit probleem opgelost door een script aan te roepen dat weet dat een speciale tag die in de HTML wordt gevonden, wordt opgenomen.
Een voorbeeld zou zijn dat als een webpagina een iframe bevat, het amp-iframe-script in de head wordt aangeroepen, wat zich ervan bewust zal zijn dat er een amp-iframe-tag in de HTML zal staan, zodat het de iframe-box kan maken voordat het is zich zelfs bewust van wat het zal bevatten.
Hoe pak je dit aan zonder AMP?
Goede planning en uitstel.
Ditzelfde type optimalisatie kan worden bereikt door dergelijke zaken uit te stellen bij het laden van de eerste pagina.
Met uitstel bedoel ik niet het toevoegen van een “uitstel” aan uw javascript.
Ik bedoel het uitstellen van alles wat niet nodig is voor de aanvankelijk zichtbare inhoud buiten het laden van de pagina zelf. Ik doe dit op de pagina die je aan het lezen bent en elke pagina op websiteseocheck.nl gebruikt deze techniek.
• Zijn afbeeldingen aanvankelijk zichtbaar? Zo ja, bel ze. Zo nee – stel ze uit.
• Is de twitter-widget in uw voettekst in eerste instantie zichtbaar voor een gebruiker? Nee (omdat het in uw voettekst staat) – Stel het uit.
• Is uw lightbox in eerste instantie zichtbaar voor een gebruiker? Zo niet, stel het dan uit.
Wat is dit uitstel?
Dingen uitstellen is de handeling van dingen laten wachten tot de onload-gebeurtenis.
Dit betekent in feite, laat de pagina laden, en dan (en pas dan) andere dingen laten gebeuren.
Ik heb uitgebreid over uitsteltechnieken geschreven.
• Hoe javascript uit te stellen
• Hoe afbeeldingen uitstellen
• Hoe video’s uitstellen
• Hoe u meerdere javascripts kunt uitstellen
Alles wat met de bovenstaande technieken wordt uitgesteld, blokkeert de weergave helemaal niet.
Houd alle javascript van derden uit het kritieke renderpad
Nogmaals, nog een optimalisatie van het kritieke weergavepad (wat echt het belangrijkste concept is in paginasnelheid). Javascripts van derden zijn meestal het resultaat van kopieer- en plakoplossingen voor zaken als sociale knoppen, analyses, SEO-tools, marketingtools, advertenties, enzovoort.
Javascripts van derden hebben de neiging niet erg gericht te zijn op de eindgebruiker. Door alle javascript van derden te blokkeren, maakt AMP een webpagina vrij om te laden zonder op iets anders te wachten, behalve dan op wat absoluut vereist is om het zichtbare deel van de pagina weer te geven. De reden om speciale aandacht te besteden aan derden is omdat de webmaster geen controle heeft over wat het script doet. Vaak gebruikt het script synchrone aanroepen of document.write, die beide de weergave aanzienlijk blokkeren. De AMP-documentatie beschrijft een illustratief voorbeeld:
Als je vijf advertenties hebt en elk drie keer wordt gesynchroniseerd, met een latentieverbinding van 1 seconde, heb je 18 seconden laadtijd alleen voor het laden van JS.
Het is dus duidelijk dat javascripts van derden moeten worden gecontroleerd.
Kan JavaScript van derden worden gebruikt in AMP? Ja.
Aangepaste javascripts / javascripts van derden kunnen alleen in sandbox-iframes worden uitgevoerd.
Wat is het probleem dat AMP probeert op te lossen met deze optimalisatie?
Javascript van derden en aangepast javascript veroorzaken vaak problemen die de laadtijd van pagina’s aanzienlijk beïnvloeden.
Hoe gaat AMP om met dit probleem?
AMP beperkt de manier waarop dergelijke javascripts zich kunnen gedragen door ze alleen toe te staan in iframes die in een sandbox zijn geplaatst (zodat ze de pagina zelf niet verstoren).
Dit betekent dat ze geen invloed hebben op het kritieke weergavepad en het laden van de eerste pagina.
Het betekent ook dat, aangezien de iframe-omgeving veel kleiner is dan de hele pagina, de herberekeningen van de stijl ook veel kleiner zullen zijn.
Hoe om te gaan met dit probleem zonder AMP te gebruiken?
Het belangrijkste dat u kunt doen, is ervoor zorgen dat elke javascript van een derde partij die uw pagina aanroept, daadwerkelijk wordt gebruikt. Vaak blijft er een stukje code achter dat niets doet. Misschien was jij of iemand anders een tool aan het testen, besloot je het niet te gebruiken, maar liet je het codefragment per ongeluk achter.
Maak een inventaris van uw extern genoemde javascripts met behulp van de websiteseocheck.nl javascript-tool. Als u er eenmaal zeker van bent dat u de dingen die u belt ook daadwerkelijk gebruikt, kunt u ze nu proberen te optimaliseren. Probeer de resterende javascripts te asynchroniseren of uit te stellen en kijk of uw pagina nog steeds correct functioneert. Als u merkt dat deze methoden niet voor u werken, neem dan contact op met de derde partij en vraag hen of zij een oplossing hebben om hun product uit het kritieke weergavepad te halen. Als ze geen oplossing hebben, zult u ze waarschijnlijk moeten vervangen door een soortgelijk product dat prioriteit geeft aan webprestaties.
Alle CSS moeten inline en formaatgebonden zijn
Kortom, CSS mag niet groter zijn dan 50k en moet in de HTML staan.
Dit betekent dat als u een CSS-framework gebruikt, u mogelijk uw manier van werken moet veranderen.
Onthoud dat alle css renderblokkering is. Dit betekent dat er helemaal niets in een browser kan worden weergegeven totdat de CSS is afgehandeld. CSS-frameworks roepen vaak honderden kilobytes CSS aan. Om AMP te gebruiken, moet je eigenlijk CSS schrijven voor de pagina zelf, in plaats van voor de hele site.
Deze pagina als voorbeeld
Ik hou echt van mijn ontwerp. Het ziet er goed uit, is responsief en heeft zelfs grote afbeeldingen met SVG en animaties. Raad eens hoe groot de CSS is voor de pagina die u nu leest?
Diverse artikelen gebruiken minder dan 4kb aan CSS. Ja dat klopt. 4k. Omdat die CSS inline is, wordt deze nog meer verkleind omdat ik compressie heb ingeschakeld. Dit is een goed voorbeeld van het gebruik van AMP-optimalisaties zonder AMP daadwerkelijk te gebruiken. Als u alleen CSS maakt voor de pagina waarop deze zich bevindt, is het verbazingwekkend hoe klein deze kan worden. Probeer de websiteseocheck.nl CSS-tool om te zien hoeveel CSS uw pagina’s gebruiken. CSS voor de meeste sites, met name sites die frameworks gebruiken, is een grote puinhoop die doorgaans minder dan 5 tot 10 procent van de CSS gebruikt die het laadt. Bootstrap, Foundation en andere dergelijke CSS-frameworks zijn niet echt de juiste keuze meer. Als je een ontwerper hebt die zegt dat hij een raamwerk moet gebruiken, raad ik je aan deze niet in te huren. Frameworks helpen ontwerpers alleen, ze veroorzaken in feite schade aan het bedrijf dat de ontwerper betaalt door opgeblazen code te maken die hun website vertraagt. CSS is een belangrijke kwestie. Ik denk dat het beperken van CSS tot minder dan 50k een geweldige optimalisatie voor het web is, en een zeer wenselijk en haalbaar doel voor elke webpagina. Zie mijn artikel over optimalisatie van CSS-levering voor meer informatie over de uitdagingen en oplossingen van CSS.
Hoe beperkt AMP de CSS-grootte?
Het doet dit door een harde limiet in te stellen voor de CSS-grootte (50k). AMP dwingt dit af door ervoor te zorgen dat elke pagina met meer dan 50k CSS niet wordt gevalideerd en daarom niet werkt met AMP.
Hoe doe je dit zonder AMP?
Het beste (en het moeilijkste) dat u kunt doen om uw website sneller te maken, is door CSS verstandig te gebruiken. Het echte antwoord hier is om alleen CSS te gebruiken die nodig is voor de pagina. In de meeste gevallen wordt de CSS die nodig is voor de hele site, geladen voor elke paginalading. Om een typisch WordPress-sjabloon als voorbeeld te gebruiken, vereist het laden van één pagina:
- Alle commentaar CSS (typisch tientallen of zelfs honderden regels) moeten worden geladen om een pagina te zien – zelfs als er geen commentaar op die pagina wordt gebruikt.
- Alle plug-in CSS moet worden geladen om een pagina te zien – zelfs als de pagina die plug-in niet gebruikt of zelfs als de plug-in iets is om admin-redenen die geen enkele gebruiker ooit zal zien
- Alle aanvullende stijlsjablonen (bijvoorbeeld: donker thema, licht thema, enz.) Moeten worden geladen om een pagina te kunnen zien, zelfs als de hele site die sjabloonstijl niet gebruikt
Hopelijk krijg je de foto, maar als je een CSS-framework zoals Foundation of Bootstrap gebruikt, is het zeer waarschijnlijk dat geen enkele pagina meer dan 3% tot 8% van alle CSS die je laadt gebruikt.
Dit veranderen is geen eenvoudige taak. Het kan veel geld en tijd kosten. Als u een herontwerp uitvoert, zorg er dan voor dat u geen grote CSS-frameworks gebruikt. Ze werken gewoon niet voor AMP of het moderne web. Als elke pagina alleen de CSS gebruikt die hij voor die pagina nodig heeft, zullen er niet veel redenen zijn om meer dan 50k te gaan.
