Google & AMP: dikke middelvinger naar alle webbouwers?
Websites hebben te maken met een obesitas epidemie. Het gewicht en aantal requests per pagina neemt drastisch toe. De gemiddelde afbeelding is niet geoptimaliseerd en pagina’s worden steeds complexer. Google heeft dit patroon al veel langer door, deelt al jaren kennis rondom dit onderwerp, ontwikkelde tools en maakte van de laadtijd een rankingfactor. In de hoop de trend te doorbreken. Helaas zonder resultaat; heeft Google de hoop in webbouwers opgegeven?
Google: “de gemiddelde tijd om een mobiele pagina te laden is 22 seconden.”
Last month, in an effort to get a better sense of how Google’s advertising partners are doing, we did an analysis of 900,000 mobile ads’ landing pages spanning 126 countries. That new analysis confirmed our thesis: The majority of mobile sites are slow and bloated with too many elements. – 02/2017: Daniel An, Global Product Lead, Mobile Web at Google
Is er nog hoop?
Ik ben de hoop al een tijdje verloren. Zijn er webbouwers die tijdens de ontwikkeling vanaf dag 1:
- Met performancedoelen en budgetten werken?
- Per paginatype continue de laadtijd meten met tools zoals SpeedCurve?
- Vertragende tracking scripts van marketeers niet toelaten?
- De mobiele-viewport extra aandacht geven (denk 2G, 3G, adaptive elementen, etc.)
- Vooruit lopen met de nieuwste optimalisatie technieken?
Ik ken deze webbouwers (nog) niet. Doe jij dit allemaal wel? Laat dan vooral een reactie achter.
Het meest frustrerende is dat wij, vaak eenmalig, de laadsnelheid mogen verbeteren en dat na een jaar, zes sprints, een redesign en honderden comments later, de website weer terug bij af is. Te vergelijken met het jojo-effect van een gemiddeld dieet. Hand in eigen boezem: de Traffic Builders site heeft hier ook last van.
Google: we vervangen het web met een ‘light-versie’
De pogingen van Google om de performance van het ‘gemiddelde’ web te verbeteren werpen (nog) geen vruchten af. Dus nu is er het open source Accelerated Mobile Pages (AMP) project, een ‘light-versie’ van het web, met een duidelijk doel:
“Instant. Everywhere.”
Een AMP-pagina is eigenlijk een normale HTML5-pagina, maar met extra regels en beperkingen. Het is nog het meest te vergelijken met een front-end framework zoals Bootstrap, maar dan met vooraf gedefinieerde functies waar je niet onderuit kan.
Wil je interactiviteit aan een pagina toevoegen, dan kan dat maar op een manier, via een AMP component (of tag). Al deze componenten zijn ontwikkeld met mobielvriendelijkheid en laadsnelheid hoog in het vaandel.
Je kan geen eigen functie of script toevoegen. Doe je dit wel? Dan wordt de pagina niet gevalideerd en niet getoond binnen Google. Hou je je netjes aan de regels? Dan cachet Google de pagina en wordt deze alvast gerenderd op de zoekresultatenpagina, waardoor deze ‘instant’ getoond zal worden.
Het lijstje componenten is beperkt, dus de kans is groot dat je niet iedere pagina om kan bouwen. Wij serveren nu ook (nog) enkel van onze blogs een AMP versie.
Over een paar jaar bouwen we sites volledig in AMP
Het project is volop in ontwikkeling en krijgt ondersteuning van veel grote bedrijven. Bekende nieuwssites draaien al een tijdje mee, maar ook complexe sites zoals eBay zijn aan het experimenteren.
Door de monopoliepositie van Google kan AMP als standaard afgedwongen worden. Geen AMP? Dan krijgt je concurrent met AMP voorrang. Geen AMP? Dan geen plekje in de nieuwscarrousel. Geen AMP? Dan kom je niet in Google Shopping. AMP first in Google Chrome. AMP voor op de desktop. Google kan alles maken, is niet evil, en doet natuurlijk alles voor de gebruiker.
De kans is dus groot dat we in de toekomst sites volledig in AMP gaan bouwen. Wil je toch meer vrijheid en functionaliteit? Dan zou je technieken zoals AMP & Progressive Web Apps (PWA’s) kunnen combineren. AMP voor de eerste landingspagina en PWA, voor na de doorklik, met meer functies en een ‘app-like experience‘.
Conclusie: wij denken dat AMP écht een middelvinger is naar webbouwers.
Tip: Vandaag en morgen is de first-ever live-streamed AMP Conf. (Vanaf 08:00 uur EST, om 14:00 uur in NL) Ik ga zeker kijken.
*) Dit artikel is ook gepubliceerd op de website van Traffic Builders.
Gerelateerde opleiding
Deel dit bericht
Plaats een reactie
Uw e-mailadres wordt niet op de site getoond
20 Reacties
Annelies
Ik denk niet naar _alle_ webbouwers, maar alleen naar de webbouwers die er dus een potje van maken. Als jarenlang tips en adviezen niet helpt, dan gewoon harde actie. Maar als je gewoon een topsite hebt, is er niks aan de hand lijkt mij. Overigens is dit geen probleem voor de webbouwers, maar voor de bedrijven die webbouwers inhuren. En die blijven maar webbouwers betalen voor crappy sites en weinig eisen omdat ze nou eenmaal niet van de hoed en de rand weten en een webbouwer heeft dus nul belang bij een topprestatie van de website. Dan moet je webbouwers afrekenen op performance of andere metrics waar ze harder voor gaan lopen. Heb inmiddels genoeg ervaring met webbouwers om dit te kunnen roepen…
Kortom, preaching to the wrong church als je t mij vraagt.
Ate - Snakeware
Wij maakten hier eind vorig jaar al melding van en zetten wel vol in op gebruiksvriendelijke sites die snel laden op mobiel en desktop met behoud van functionaliteit en kwaliteit. Voordeel van 22 jaar technologie combineren met creativiteit. We helpen onze opdrachtgevers aan blijvend hoge scores en weten zeker dat de komende tijd hier het verschil in gaat zitten. Voor onze opdrachtgevers en de positieve ervaringen van hun klanten. Wij zijn blij met de strengere waarderingen van Google. Kom maar door zeggen wij hier in Friesland 🙂
Wolter Tjeenk Willink - Traffic Builders
@annelies: eens, het gaat niet om alle webbouwers, zoals ook Ate suggereert. Maar er zijn er nog altijd veel die te weinig op de hoogte zijn van dit soort nieuwere ontwikkelingen. In meer dan de helft van de SEO begeleidingstrajecten die we doen is door de webdevelopment partij geen rekening gehouden met zaken als AMP. Performance staat vanzelfsprekend wel op de radar, maar heel concreet wordt het zelden. Omdat specifieke kennis ontbreekt, of omdat de developers de kennis wel hebben maar het onderwerp in het salestraject niet concreter is geworden dan het standaard verkooppraatje. Daardoor is concretisering al snel “out of scope”. Zonde, want de meeste developers vinden het juist gaaf om met dit soort technieken te werken.
Om die verantwoordelijkheid volledig bij de opdrachtgever te leggen is in mijn optiek niet geheel terecht. Die is immers vaak onvoldoende op de hoogte en dat mag je ook niet verwachten. Van een (webdevelopment) bureau mag je die kennis daarentegen wel verwachten lijkt mij. Evenals de drive om een opdrachtgever naar beste kunnen te adviseren.
Kortom: ga je als webbouwer leveren wat de klant vraagt, of wat de klant nodig heeft?
Ate - Snakeware
Een echt kwaliteitsbureau levert wat de klant nodig heeft, denkt mee en vooruit en had hoer allang op in moeten spelen en oplossingen voor aan moeten dragen. Snelheid in het serveren van code in combinatie met design thinking en heldere functionaliteit matchend met het device waar je op werkt is KEY!
Harro - Nivvo
Goed artikel! Snelheid is idd king op mobiel. Overigens is het op desktop ook best prettig ;-). En ook zonder AMP kan je hele snelle websites bouwen.
Heb veel ervaring met allerlei webbouwers en er zit inderdaad veel kaf onder het koren. Veel beloven, maar te weinig waarmaken. Het zegt trouwens ook veel over de klanten die zich nog steeds van alles laten aansmeren helaas.
Wendy Greyhat
Jullie zelf ook de bak, Robbert 😉 Verder prima artikel.
https://developers.google.com/speed/pagespeed/insights/?url=www.traffic-builders.com&tab=mobile
Martin Voorzanger - EclecticIQ
Vorige week hebben we als test 1 sectie op onze website (de News sectie, zie https://www.eclecticiq.com/amp/news) ‘AMP-compliant’ gemaakt. Dit was een dagje werk, inclusief aanpassingen in Google Tag Manager en Google Analytics. Pagina’s met meer interactie (lees Javascript) zullen vermoedelijk aanzienlijk meer tijd kosten. We hebben nog geen besluit genomen of we deze op korte termijn ook zullen aanpakken, gezien onze doelgroep beperkt via mobiel naar onze website komt.
Wolter Tjeenk Willink - Traffic Builders
@Wendy work in progress. Opdrachtgevers gaan altijd voor 🙂
Roy Lenders - Digital Operating Models
Mijn ervaring is dat de grootste snelheidsissues altijd liggen bij externe scripts. Denk dan aan Chat Widgets, Social Media scripts en dat soort dingen. Met name Javascript scripts hebben bij een gemiddelde webpagina de meeste nadelige gevolgen.
peter
Nou ATE Snakework, na jullie mooi promotiepraatje dacht ik: ik pak de eerste website uit jullie portfolio en draai hem door google pagespeed tool:
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fsprookjescamping.nl&tab=mobile
Resultaat? een mager 6-je…
Tim de Hoog - Timdehoog.nl
Ik ben het eens met Roy Lenders. Ook externe scripts van advertentie partijen zijn vaak een bottleneck wat betreft het inladen van een webpagina.
Voor de webpagina zelf kan al veel winst behaald worden door bestanden samen te voegen, afbeeldingen te comprimeren, pagina’s te cachen of lazy loading in combinatie met below the fold toe te passen.
peter
@Tim de Hoog: dit probleem is zeer eenvoudig op te lossen door alle externe marketing pixels in een GTM container te zetten en zorgen dat alles asynchroon wordt ingeladen. Bottleneck bestaat dan niet meer.
Ate - Snakeware
@peter,
Je maakt een goed punt. We zijn continu voor onze opdrachtgevers met snelheid bezig. Binnenkort wordt onze nieuwe ‘snelheidmodule’ bij deze en vele andere opdrachtgevers uitgerold. Haal dan onze producties allemaal maar door de Pagespeed :). Tot die tijd ga ik me natuurlijk schamen voor die magere 6 🙂
Tim de Hoog - Timdehoog.nl
@peter: ik bedoelde met advertentie partijen niet de marketing pixels maar de advertenties zelf die op een website worden getoond.
Martijn Oud
Het is wel erg makkelijk om een website sneller te maken door alle functionaliteit er uit te slopen. Natuurlijk word een website sneller als praktische alle Javascript niet is toegestaan maar je beperk hiermee een website wel. Het web was in 2005 misschien sneller hierdoor maar of het ook beter is?
Annelies
Ik bespeur hier een beetje de tendens dat iedere site maar supersnel moet zijn, maar dat is natuurlijk niet zo. Mijns inziens, om me er nog maar eens in te mengen, moet je goed kijken over wat voor soort bedrijf het gaat en wat het doel van de website is, en daarnaast uiteraard hoeveel mensen er via mobiel op je site binnenkomen en nu bouncen. Op veel B2B-websites komen mensen nog grotendeels via desktop of tablet. Optimalisatie voor mobiel is dan misschien niet direct nodig. Op e-commerce websites is het echter wel sterk de vraag wat je nou belangrijker vindt: allerlei tierelantijntjes of een soepele shopervaring. Als jij wilt dat mensen op mobiel converteren dan zul je concessies moeten doen aan de functionaliteit en mooiigheid. Het is dan belangrijker dat mensen kunnen vinden wat ze willen hebben en dat soepel kunnen aanschaffen. Snelheid, maar met name de perceptie van snelheid is belangrijk dan en dat hangt wel af van je internetverbinding op dat moment.
AMP is dan nu nog vooral een lekkere oplossing voor zware blogs met veel rich content, maar het nut daarvan vind ik een stuk minimaler dan een dergelijke oplossing voor e-commerce. En dan komt het wel aan op een creatieve webbouwer die een webshop voorzien van zinnig advies over de technische mogelijkheden, in samenwerking met een online marketing bureau dat ook aan de klant kan uitleggen waarom er bepaalde concessies worden gedaan.
En Robbert, om nog even op jouw eerdere reactie terug te komen: ik vind dat een klant met een website waar die geld mee wil verdienen, wel degelijk zichzelf mag opvoeden of mensen aan mag nemen of inhuren met verstand van zaken. Webbouwers bouwen websites en die moeten zich vooral met de nieuwste technieken en beste oplossingen etc bezig houden. En ja, enig verstand van zaken rondom online marketing, zoals SEO, conversie, usability, mag je wel verwachten van een webbouwer, maar ik heb vaak genoeg discussies gehad met webbouwers die dan zeggen: ja maar wij hebben ook een mannetje zitten en die zegt wat anders dan jij. Dan kun je beter een webbouwer hebben die jouw wensen (of je nu een klant bent of een bureau dat namens een klant werkt) kan vertalen naar wat er technisch kan, dan dat je er eentje hebt die voor jou gaat lopen denken en daarmee de plank misslaat. Iedereen zijn eigen expertise. Samenwerken is cruciaal. Ben het wel met je eens dat je van een webbouwer mag verwachten dat deze vooruit denkt en je website in elk geval technisch up-to-speed houdt en ook de mogelijkheden al kent op het moment dat je het vraagt.
In elk geval is het wel wat makkelijk om webbouwers hiermee op de hak te nemen, terwijl die vaak ook gebonden zijn intern aan allerlei legacy issues, gebrek aan kennis, teveel verschillende klanten die vanalles willen, etc, geen excuus, maar daarom nog belangrijker om goed te denken over wat je nou eigenlijk écht nodig hebt voor je website en met welk doel.
If that makes any sense at all. Beetje lang verhaal geworden.
Robbert van Ekris - Traffic Builders
@Annelies: Om het ook nog even voor webbouwers op te nemen. Het W3C is misschien nog wel de grootste boosdoener in dit hele verhaal. Die zouden veel meer populaire web functies (analytics, e-commerce, social, carrousel, lightbox, accordion, etc.) moet standaardiseren. Denk aan het HTML5 element en hoe lang we daar op hebben moeten wachten. Voor mijn gevoel hebben ze de mobile first trein ook compleet gemist.
Danielle
@robbert Nou ik sta verbaast van de felle uithaal en inderdaad hoor je zelf de zaken dan wel op orde te hebben zoals @wendy al aangaf. Dat jullie geen ontwikkelaars kennen die het wel goed doen zegt meer over jullie dan over de ontwikkelaars denk ik, en ik vraag me af waar bij jullie dan de benodigde technische kennis vandaan komt die je nodig hebt om anderen daarop te beoordelen en/of in te begeleiden.
Een project uit jullie portfolio:
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.kunstgrasnet.nl helaas ook met een zeer slechte score.
Over html 5, je opmerking raakt echt kant nog wal, html5 is geen element maar een taal.
Het vaststellen van standaarden is essentieel voor de verdere ontwikkeling van het web en veel van de componenten die je noemt kun je opbouwen op basis van deze standaarden. Verder dicteert het W3C niet ‘hoe’ je moet bouwen (b.v. mobile first) maar wel welke elementen je daarvoor tot je beschikking hebt op basis van standaarden.
Ik stel voor dat je je eerst eens wat meer in de materie verdiept een goed begin zou zijn eens bij Fronteers te gaan kijken, dat is een vakvereniging voor ontwikkelaars, zie https://fronteers.nl/
Zij hadden onlangs een zeer interessante masterclass over performance: https://www.voorhoede.nl/en/blog/why-our-website-is-faster-than-yours/
Ook voor de anderen hier, inladen van externe scripts is echt maar een klein onderdeel van het probleem.
Ik zou zeggen werk aan de winkel.
Robbert van Ekris - Traffic Builders
@Danielle: Er stond “HTML5 video element”, maar dan video in html, wat Emerce blijkbaar standaard uit reacties verwijderd.
Bart
Er zijn inderdaad veel teveel trage sites. Sites met meer code dan goed voor ze is. De cmsen zijn te zwaar doordat functionaliteit belangrijker is geworden dan performance. Zelfs WordPress is steeds trager geworden in de loop der tijd. Daar ligt volgens mij het grootste probleem. En in de tweede plaats zijn het de bouwers die teveel plugins menen nodig te hebben.
Je kan ook doen zoals ik bij m’n hobbysite heb gedaan. Gewoon zelf schrijven.
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.metaaldetectortips.nl%2F