Microsoft voegt ondersteuning voor amp html toe aan zijn Bing-app

Microsoft heeft aangekondigd dat het ondersteuning voor amp html heeft toegevoegd aan zijn Bing-app. Daarmee moeten webpagina's die van deze techniek gebruikmaken ongeveer tachtig procent sneller geladen kunnen worden dan gewone html-pagina's.

Microsoft schrijft dat de Bing-app automatisch controleert of er van een bepaalde pagina ook een amp-versie beschikbaar is. Indien dit het geval is, laadt de app deze pagina van een server die bij de gebruiker in de buurt is. Dit kan ook via een amp cache gebeuren, waardoor meer snelheidswinst te behalen is. Is er geen amp-versie beschikbaar, dan laadt de app de normale versie. Volgens Microsoft heeft de beschikbaarheid van een amp-versie geen invloed op de rangschikking van de pagina's in zijn algoritmes.

Pagina's die de techniek ondersteunen, zijn in de app te herkennen aan een grijs symbool met een bliksemschicht, voegt het bedrijf daaraan toe. Het is onduidelijk of dit in zowel de Android- als de iOS-versies van de app op dezelfde manier werkt. Microsoft zegt in mei te zijn begonnen met het experimenteren met de techniek. Daarbij bleek dat amp html een snelheidswinst van ongeveer tachtig procent opleverde, naast een verminderd dataverbruik.

Google presenteerde amp html als een opensourceproject in oktober 2015. Sindsdien hebben verschillende organisaties, waaronder veel nieuwssites, de techniek geïmplementeerd. Amp html werkt door onder andere het gebruik van javascript te beperken en lagere prioriteit te geven aan advertenties. Voor analytics-doeleinden kunnen beheerders gebruikmaken van tracking pixels.

Amp-icoon in de Bing-app voor iOS

Reacties (46)

[Verwijderd]

De tijd die men spendeert om AMP te implementeren kan men ook gebruiken om de ganse site te optimaliseren. Toen dit project begon was er een medewerker van Yahoo (die alles haarfijn in een video uitlegde) dat in enkele uren tijd de site die toen AMP moest voorstellen terug bracht van enkele MB's naar 500 KB.

Een artikel die hieraan toegewijd is: https://www.tunetheweb.co...e-really-need-google-amp/

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:44]

[Robbemans]

Dat artikel is van oktober 2015. AMP is sindsdien behoorlijk gevorderd (waarom zou MicroSoft het anders gaan onderteunen?)

AMP trekt de wortel uit sommige bloated sites. Dit doen ze enerzijds door een zeer beperkte set van html middelen aan te bieden en anderzijds door de pagina's in Google's eigen cache onder te brengen.

AMP is kleiner en cleaner. Bedenk je dat Nederland erg voorop loopt met 4G en snel internet en dat dat lang niet overal maar half zo goed geregeld is - zeker voor mobieltjes.

Vanaf 2017 wordt AMP meegenomen in de zoekresultaten. Dat zal ook een boost geven aan AMP sites.

Aangezien Google searchengine nummer 1 is momenteel, is dit zeker de moeite van het implementeren waard. Optimaliseren doe je je site dan niet voor jezelf maar voor AMP. Een pagina van 500kb is nog steeds enorm. Een pagina van een paar kilobytes (max), dat is wat interessant is.

[Verwijderd]

Microsoft zal hier waarschijnlijk wel hun beweegredenen voor hebben. Maar het artikel dat ik aanhaalde is nog altijd van toepassing. De website die AMP voorstelt (https://www.ampproject.org/) maakt gebruik van de volgende technieken om aan 136 KB te komen voor de ganse pagina:

• Afbeeldingen zo optimaal mogelijk serveren. Optimaliseren voor een bepaald scherm en daarmee de kwaliteit aanpassen. De grootte beperken door de afbeelding zo klein mogelijk te maken. Zie: https://www.ampproject.org/static/img/amp.jpg. Deze afbeelding is nog maar 16.5 KB groot. De orginele afbeelding op ware grootte die je terug kunt vinden via Google Afbeeldingen is 1.1 MB groot!
• Een tweede optimalisatie die men gebruikt zijn Service Workers. Die worden gebruikt om bepaalde onderdelen van een website voor offline gebruik toegankelijk te maken, maar ook als cache. Het voordeel is dat er geen HTTP verzoek meer nodig is.

Beide technieken kunnen nu al geïmplementeerd worden zonder dat je AMP nodig hebt.

[Robbemans]

De technieken, daar heb je helemaal gelijk in. Echter, omdat Google AMP pagina's zelf uit zijn eigen koker gaat hosten hebben ze volledige controle en hoef jij je hier niet meer zorgen over te maken.

Het staat je vrij om een AMP derivaat te maken en daarnaast is AMP misschien helemaal niet nodig. Google vindt echter van wel: zij willen gewoon nummer 1 zijn en blijven.

Voor sommige sites werkt AMP wel, voor andere niet. Een 100% Angular site zet je niet zo maar om, maar een nieuwssite of blog is geen probleem - en dat is nu net waarvoor AMP bedoeld is.

[Verwijderd]

Als ik een bloated site wil publiceren, dan mag dat toch? Daar heeft Google niets over te zeggen. Een site (dus niet pagina) van 500 KB is niet veel. Dit is de zoveelste stap van Google richting het domineren van het internet.

[Robbemans]

Die dominatie: zeker.

Je bent uiteraard niet verplicht om AMP te ondersteunen en voor sommige sites werkt het ook helemaal niet. Voor semi-statische pagina's is het echter geweldig. Denk hierbij aan nieuwssites, blogs, clickbait, etc.

[Ossebol]

Hoewel ik het een mooi streven vind om dataverbruik te verminderen en pagina's nóg sneller te laten laden, twijfel ik over het praktische nut ervan in ontwikkelde landen. Tegenwoordig is de hoeveelheid data via websites niet echt meer van belang (dynamische content als video en audio daargelaten) en ook wat betreft snelheid hebben wij hier niets te klagen. Het enige nut in mijn ogen is dat pagina's worden gecached, zodat ze ook kunnen worden geserveerd als de daadwerkelijke bron offline is. Het is naar mijn mening in ieder geval goed om te lezen dat Microsoft dit nog niet laat meewegen in het algoritme, omdat de technisch en het nut hiervan zich nog breed moeten bewijzen.

[dakathefox]

Hoewel ik het een mooi streven vind om dataverbruik te verminderen en pagina's nóg sneller te laten laden, twijfel ik over het praktische nut ervan in ontwikkelde landen.

Ik woon in een ontwikkeld land, namelijk Nederland. Ik heb vaak de beschikking over 4G, maar helaas soms ook 3G. In situaties waarbij ik afhankelijk ben van 3G vind ik het fijn alsnog over een snelle site te kunnen beschikken. Los daarvan hebben veel mensen gewoon internetbundels die maar 1 of 2 GB aan data kunnen afhandelen. Elke MB die je dan besparen kunt is er dan één.

[WillySis]

Als het om databesparing gaat kan ik je Opera Max aanraden. Werkt niet alleen in Opera, maar in alle apps. Datagebruik wordt met ca 30% teruggebracht. Het is geen addblokker, maar grote advertenties worden wel tegengehouden.

Of amp nu zoveel meerwaarde heeft weet ik niet. De ontwikkelaars kunnen nog veel winst halen door websites te optimaliseren. Als amp de snelheid al verbeterd maakt het de ontwikkelaars wellicht nog luier en wordt er alleen nog maar meer onnodige zooi als ongebruikte javascipts, afbeeldingen in een veel te hoge resolutie ed meegestuurd.

[dakathefox]

Data besparen begint bij de bron, niet bij de ontvanger.

[Verwijderd]

Het punt is dat als je voor het eerst naar een website gaat, je vaak een paar MB moet downloaden aan plaatjes en Javascript.

Als je bijvoorbeeld tweakers.net voor het eerst laadt op een 3G-verbinding, duurt het zo'n 5 seconden voordat je de content binnen hebt, en na 7 seconden is de site pas volledig geladen. Gebruik je internet op een kabel, dan laadt de pagina instant in 300 milliseconden.

Er valt dus enorm veel te winnen met AMP. Google verspreidt de statische content over hun CDN, en je download alleen dat wat nuttig is. Scheelt enorm veel nutteloze laadtijd!

(edit: ga maar eens in Chrome naar Developer tools -> Network; klik op "Disable cache" en kies "Regular 3G" bij throttling)

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:44]

[passantr]

Goede tip, thanks

[Verwijderd]

Ik denk dat je erg optimistisch bent over mobiele snelheden en hoe weinig jij denkt dat dat uitmaakt:

https://www.doubleclickby...les/mobile-speed-matters/

[Timo002]

Moet ik sites gemaakt voor amp (in amp) zien als het vroegere wap? Ik zie er niet veel toekomst in om heel eerlijk te zijn. Leuk dat het kan, maar waarschijnlijk gaan 99% van de website geen app alternatief maken. Een website is al complex genoeg om te maken, laat staan een 2e amp site er bij naast!

[Reactie gewijzigd door Timo002 op 22 juli 2024 13:44]

[dakathefox]

Alhoewel AMP HTML zeer interessant is, ben ik ook nog niet om. Ik zie vrijwel dagelijks bloated websites die met één of ander shabby template van Themeforest zijn gerealiseerd. Die templates worden ontwikkeld door de eerste de beste Vietnamees die het liefst een template met zoveel mogelijk toeters en bellen zal willen lanceren. Immers, mensen kicken of het zien van sliders, parrallax effecten en andere ongein waar ze een harde plasser van krijgen. En dat betekent dat mensen de templates gaan kopen!

Maar al die toeters en bellen gaan gewoon keihard ten koste van de functionaliteit en snelheid van de website. Het moet allemaal ingeladen worden en bij de ontwikkeling is nooit rekening gehouden met het feit dat een site naast mooi, ook licht en snel moet zijn .

Ik vergelijk het altijd met een F1 auto. Daar zit geen airco, airbag, cruise control en andere shit is. Dat hoeft ook niet, want hij moet gewoon verdomd snel zijn. En zo geldt dat voor een site dus ook. Ontwikkel eerst een goede site, tweak je hosting en pas CDN toe. Dan heb je AMP HTML niet eens écht nodig.

[ThePendulum]

Het principe achter CDNs moet aan mij toch nog eens uitgelegd worden. Deze heb ik nu vele malen proberen te gebruiken, en bij andere zie ik ook steeds hetzelfde; bijna alles is netjes geladen, maar de CDNs laten nog even 2-3 seconden langer op zich wachten. Hoe effectief ze zijn lijkt dan een beetje af te hangen van waar je de website bezoekt.

Bovendien ben ik nieuwsgierig óf en hoe je van CDNs kunt profiteren als je buildtools zoals webpack gebruikt.

Gezien er veelvuldig gebruik van wordt gemaakt, heb ik het idee dat ik dan toch zelf iets verkeerd doe of niet goed begrijp. Als je op de bandbreedte of het data verbruik van je server probeert te besparen kan ik de voordelen begrijpen, maar het lijkt de laadsnelheid zelden te goed te komen.

[Reactie gewijzigd door ThePendulum op 22 juli 2024 13:44]

[Verwijderd]

" maar het lijkt de laadsnelheid zelden te goed te komen. "

Die conclusie kun je alleen trekken indien je vanuit vele lokaties waar je gebruikers zich kunnen bevinden hebt getest, tenminste als je publiek globaal is.

Als je hier in NL een server hebt staan en ook vanuit hier test, kan het zelfs zo zijn dat je eigen server sneller is dan die van Google, en zeker sneller dan die van Amazon.

Build tools en CDN zijn uiteraard prima te integreren. Of je nu gulp, npm of webpack gebruikers, bij allen kun je ieder deploy scripts wat je maar wil onderdeel van je build maken.

[eborn]

En als je een systeem als cloudflare gebruikt, waarbij er altijd nog een 'source' server is, dan hoeft dat ook niet eens. Een correcte cachet buster toevoegen aan je building tools is dan voldoende om de cdn cache ook te flushen.

[dsmeef]

Het heeft o.a. Het voordeel van caching, als je jquery laadt vanaf een versie die iemand al heeft bezocht dankzij een andere site, is het een cached request, daarnaast is er een pagespeed pluspunt en dus google optimalisatie, en is het in een site met veel requests handig als je die kan verdelen over meerdere servers omdat een browser maar een x aantal request tegelijk per domein kan doen.

[NicoJuicy]

Minification voor http 1.1 ipv meerdere assets is volgens mij toch veel beter

[Yggdrasil]

Klopt, het laden van populaire JS frameworks en webfonts kun je beter doen vanaf een publieke CDN zoals ajax.googleapis.com of cdnjs.com. Goede kans dat een bezoeker deze dan al in zijn cache heeft.

Gelukkig zijn technieken zoals de domain sharding, sprites, etc. die je noemt niet meer echt nodig. Als je servers HTTP/2 ondersteunen dan is het namelijk beter om alles vanaf één domein te serveren zodat al je assets over één TCP-verbinding gemultiplexed kunnen worden. Of dat zinvol is hangt helaas weer af van de browserondersteuning binnen je doelgroep. In de eerste wereld niet echt een probleem, maar hoe dat in de derde wereld zit...?

[Robbemans]

Zelfs met de dikste CDN haal je de snelheid van AMP niet. Reden: AMP beperkt je tot het bot. Dat is een filosofie / werkwijze. Per saldo komt het voor templated sites neer op een andere template gebruiken.

Met AMP wordt de html over het algemeen ook nog eens flink kleiner en worden de pagina's vanaf Google zelf geserveerd. Dat scheelt enorm voor je eigen webserver.

Voorts wordt AMP vanaf begin 2017 een graadmeter voor scoring in Google.

Voor mijn voldoende reden om vol in te zetten op AMP.

[Verwijderd]

Dus ik betaal maandelijks een som geld voor een snelle internetverbinding en vervolgens gaat Google bepalen wat goed voor mij is door websites te verminken en webservers over te nemen?

[Robbemans]

Nee. Google cacht de AMP pagina's op zijn servers om er juist voor te zorgen dat jij niet met jouw servers een vertragende factor bent. Googles 'CDN' en batterij aan servers zijn iets krachtiger dan de gemiddelde huis-tuin-en-keuken-hoster biedt.

Ze verminken niks, want AMP is statisch: je mag geen extra (ongecontroleerde) javascripts uitvoeren en meenemen in je code.

[Verwijderd]

Ik heb geen servers. Ik ben een bezoeker van webpagina's en ik wil geen verminkte statische sites. Ik wil volledige informatie (geen censuur) en ik wil kunnen vertrouwen op informatie die ik binnenkrijg. Google vertrouw ik niet, en ik vind het een slechte zaak als ze op deze manier een voet tussen de deur krijgt.

[Robbemans]

Alle gegevens worden integraal doorgegeven, althans vooralsnog. Google zou wel erg dom zijn als ze dat niet zouden doen: dan is AMP direct dood.

Het verminken, dat is wat de uitbater van de AMP site zelf bepaalt Je kan veel, maar alles zonder javascript. Ja, dit zijn beperkingen, maar dat is in dit geval het voordeel.

[dakathefox]

Je hebt gelijk. Problemen moet je bij de bron aanpakken. AMP doet dat, CDN niet. Zie CDN als een hulpmiddel, maar niet als de heilige graal om je moddervette template sneller te doen lijken.

[Timo002]

Amen!

[dakathefox]

Dank u.

[kevin93w]

Toch kan het als internationaal bedrijf een hoop voordelen bieden. De internet snelheden liggen wereldwijd nog lang niet op het niveau zoals wij dat hier in het westen gewend zijn en met de toenemende mate aan scripts, frameworks, tools en extensies maakt het websites erg inefficiënt. Voor klanten die een snelle internet verbinding hebben wellicht geen probleem, maar als internationaal bedrijf is het toch prettig om te weten dat je een hoop nieuwe potentiële klanten kan bereiken die niet over zo'n snelle verbinding beschikken. Ik weet niet of AMP hier dé oplossing voor is, maar het is zeker één van de meest progressieve oplossingen op de markt die je kan gebruiken om dit probleem op te lossen.

[Reactie gewijzigd door kevin93w op 22 juli 2024 13:44]

[supersnathan94]

Ontwikkel dan op een framework zoals AngularJS. De view en controller worden eenmalig ingeladen (javascript) en alleen de veranderende data wordt via API calls binnengehaald. Initieel een wat langere laadtijd, maar voor grote projecten en monitoring pages echt een enorme verbetering.

[Robbemans]

Hier raak je net het probleem dat AMP oploset: geen initele laadtijd. De meeste pagina's en sites worden eenmalig bekeken.

[supersnathan94]

Ja je laad alleen de dingen in die je nodig hebt. Precies wat AngularJS ook gewoon kan doen.

[Robbemans]

Bij Angular laad je ook functionaliteit om bij te laden in de vorm van javascript en libraries. Dat is bij AMP niet van toepassing.

[supersnathan94]

Voor grote projecten en monitoring pages echt wel hoor. De hoeveelheid data zit hem dan niet in de scripting en libraries (hoogstens een paar MB), maar in de data zelf. Ik heb aan het einde van de dag rustig 20GB aan logs ingeladen. Dat is waar een halve seconde laadtijd voor de hele app dan helemaal niets meer uit maakt. Als de rest maar gewoon instant of asynchronoon is. Amp is leuk voor kleine pages met weinig data waarbij standaard libs als Jquery in verhouding ineens heel veel verbruiken.

[Robbemans]

AMP is niet bedoeld voor grote projecten. Precies zoals je al aangeeft. Twee werelden, twee functies.

De inzet van AMP is dan ook beperkt tot dingen als nieuwssites en blogs. Daar komt het tot zijn recht.

[Verwijderd]

Gzip, caching, minify en minimaal JavaScript doet al een hoop. Ook inline laden van css werkt erg goed. Amp is nieuw voor mij maar wellicht teveel omslacht.

[Verwijderd]

Ik denk dat jullie AMP HTML onderschatten. Ja, het is nog niet fantastisch, maar het is wel van Google en dat betekent dat ze er van alles mee kunnen doen. Het zou me niet verbazen als het straks de rankings op Google gaat bepalen.

SEO en AMP HTML zullen, naar mijn idee, straks hand in hand gaan.

[dakathefox]

Dat doet het al. Snelheid is voor Google een belangrijk argument, evenals mobiel-vriendelijkheid.

[Verwijderd]

Voor zover ik weet heeft het nog geen effect op de rankings. Heb je een bron?

[dakathefox]

Google even zou ik zo zeggen. AMP HTML zaak wellicht als zodanig niet direct een meetpunt zijn, maar het gebruik ervan wel van invloed op snelheid en mobiel-vriendelijkheid en daar is algemeen van bekend dat Google er naar kijkt.

[Verwijderd]

Dat is geen bron. Heb al Gegoogled en heb daar niks over kunnen vinden. Ja, tuurlijk heeft dat invloed, maar heeft dat nu ook al invloed op de rankings? Want dat is wat ik aangaf.

Zo ja, bron graag.

[dakathefox]

Snelheid is al een jaar of zes van invloed op je ranking. Daar moet je wel een bron van kunnen vinden lijkt me. Doe je best zou ik zo zeggen.

[Robbemans]

Rankings pas vanaf begin 2017.

[Robbemans]

Dat gaat inderdaad gebeuren. Snelheid is nu de belangrijkste factor, in combinatie met relevantie.

[Verwijderd]

Ik zie ik amp html ook tags staan met 'webkit' er in. Gaat Google nu allerlei tools produceren die specifiek voor webkit geschreven zijn?