Google linkt vanaf begin 2016 naar snellere en lichtere amp html-pagina's

Google zal vanaf begin volgend jaar vanuit zijn zoekmachine linken naar pagina's op basis van amp html, een variant op html om snellere mobiele webpagina's te maken. Javascript van externe partijen is op amp html-pagina's niet toegestaan, waardoor advertenties alleen in iframes kunnen.

Ontwikkelaars en sitebeheerders kunnen al pagina's in amp html online zetten, maar aangezien het linken pas vanaf begin volgend jaar gebeurt, zal het gebruik van amp html vanaf dan een grotere vlucht nemen. Google belooft snel meer details te geven van hoe het gaat linken naar amp html-sites. Dat zal vooral gelden voor mobiele pagina's, waar de kleinere en lichtere pagina's een groter verschil kunnen maken in de gebruikservaring.

Het doel van amp html, waarbij amp staat voor 'accelerated mobile page', oftewel versnelde mobiele pagina, is om mobiele pagina's sneller te laten laden. Volgens de projectgroep onder leiding van Google zijn pagina's dankzij amp html 15 tot 85 procent sneller. Dat gebeurt door vooral html- en css-elementen toe te staan op pagina's, en het gebruik van javascript te beperken. Advertenties hebben bij amp html een lagere prioriteit dan doorgaans, waardoor de iframes met advertenties pas geladen worden als de content al op het scherm staat. Websitebeheerders kunnen statistieken vergaren met behulp van tracking pixels, maar wel zonder gebruik van javascript.

Het project staat op GitHub, inclusief voorbeelden en uitleg. Google stelt zijn caching-infrastructuur van servers over de hele wereld beschikbaar om pagina's sneller beschikbaar te maken. Er zijn al veel grote sites die meedoen met het project en die beloven om pagina's in amp html te gaan tonen, waaronder die van de BBC, Buzzfeed, Mashable, The Wall Street Journal, The Guardian en het Nederlandse Nrc.nl.

Google heeft een demonstratie online gezet en zegt dat het gebruik van amp html te zien zal zijn in de zoekresultaten van zijn zoekmachine. Naast Google staan ook Twitter, LinkedIn, Pinterest en Wordpress.com in de lijst van deelnemers.

AMP HTML

Door Arnoud Wokke

Redacteur Tweakers

25-11-2015 • 07:49

88

Reacties (88)

Sorteer op:

Weergave:

Dit is weer typisch zo'n "Google, WTF?" momentje. Kondigen iets aan, zonder dat we er eerder van gehoord hebben. Heeft toch wel veel impact voor veel websites en lijkt vooral veel irritatie op te leveren en schiet zijn doel een beetje voorbij.

Allereerst is het prima om optimalisatie na te jagen en Google heeft dan ook aardig wat macht om sites tot aanpassen te brengen. De vraag is alleen of Google dat ook moet doen en het niet beter kan overlaten aan andere partners die voor standaardisering staan. Waarom? Omdat niet Google moet bepalen wat voor alle zoekmachines het beste is. Dit heeft namelijk niet alleen effect op de resultaten van Google, maar in principe op alle zoekresultaten van alle searchengines. Het neigt naar machtsmisbruik. En als je verder kijkt vraag ik me af of veel sites dit gaan gebruiken want het ziet er toch wel uit als een aardige klus voor iets wat je volgens mij weinig oplevert. Tenminste, nu levert het je nog geen penalty op bij de zoekresultaten. Maar voor hoe lang nog?

Wat opvalt in het bericht is dat ze beginnen met allerlei partners. Dat ze die hebben is prima, maar ik kan me niet aan de indruk onttrekken dat die net zo goed gebaat waren met diverse optimalisaties volgens huidige optimalisatie-technieken. Daarnaast gaat het dus om "early next year" dat dit live gaat. Waarom horen we dan nog pas later over alle details? Het gaat hier om slechts enkele maanden en we weten niet eens wat voor impact dit heeft, wil je het uitrollen op je site!

De techniek erachter vind ik ook wat apart. Waarom alleen mobile versnellen? Waarom niet gewoon elk apparaat? En er wordt veel niet toegestaan in een AMP HTML pagina.
Wat regels:
  • Iframe, img, video en audio wordt veranderd naar "amp-" tag en dus anders afgehandeld (na het laden van de overige content)
  • Geen object
  • Geen embed
  • Geen form (the what now?)
  • Geen Input of andere form-elementen (wut?)
  • 1 extra style-tag
  • Geen Script-tag, behalve als het type "application ld+json" is (kortom dat heeft nu niemand)
  • Geen "onClick", onMouseover" of "javascript:"
  • Diverse CSS regels verboden of gelimiteerd ("*", ":not", etc)
  • Strengere regels aan custom fonts waarbij extern laden voorlopig alleen werkt met googleapis
Als ik die lijst zo zie denk ik dat er alleen text-based sites voldoen aan die eisen en daarbij heb je dus geen enkele mogelijkheid tot interactie of dynamiek. Ik snap de intentie, maar wat is het resultaat? Is dit het web wat we willen of is dit een nare manier om allerlei problemen te omzeilen die Google gewoon zelf op moet lossen.

Ik blijf erbij, stimuleren tot optimalisatie is prima, maar ga niet nieuwe spelregels bedenken en al helemaal niet met zo'n kleine doorlooptijd. Als developer heb ik hier al geen zin in, maar ik kan me voorstellen dat de business ook reageert met "leuk Google, maar wij doen niet mee". Optimalisaties van Websites kunnen beter, maar dit is zeker niet de manier om dat te doen. Teveel restricties, te weinig mogelijkheden om websites interessant te houden en een aantal rare keuzes die hun doel al snel voorbij schieten. Van mij mogen ze terug naar de tekentafel (als ze überhaupt al verder mogen)
Ironisch genoeg zorgen de scripts van Google Analytics en Google Adsense voor veel vertraging bij websites.
"Is dit het web wat we willen"
Wat mij betreft wel. Er wordt IMO veel 'misbruik' gemaakt van javascript. Een miljard includes van een zelfde aantal andere domeinen, click/scroll hijacks en full page 'pop ups'. Hoe eerder we weer terug kunnen naar text only websites, hoe beter.
Firefox + NoScript is een must tegenwoordig.
Dan heb je een hele andere opvatting van het web dan ik. Dat is prima, maar geeft wel even aan waar we staan. Voor mij is het web namelijk een stuk vrijer en is het voor iedereen mogelijk om bij te dragen. Iets wat hier al niet mee lukt gezien je geen formulieren mag gebruiken. Maar nog los daarvan is het natuurlijk belachelijk dat je zulke strenge restricties wilt opleggen, puur omdat er trage devices zijn. Het internet moet niet gelimiteerd worden door de traagste devices. En daarbij is bij veel sites tekst niet de reden om er te komen. Denk een Youtube of Instagram. Een site als Tweakers is al niet mogelijk in APM. Diverse andere sites kunnen ook niet overleven.

Natuurlijk kun je ook op andere manieren analytics verzamelen of reclames weergeven. Daar lijkt het toch wel om te doen bij dit experiment (want dat is het), maar dit is niet de manier om dat te doen. Tevens het tegenzitten van CDNs is een rare keuze. Of limiteren van font-hosting neigt al snel naar misbruik.

En ja, Javascript wordt vaak misbruikt, maar dat is nog geen reden om het voor de rest te gaan verbieden. Denk aan de manieren waarop het wel handig wordt toegepast (alleen al het veranderen van de pagina op acties zoals bv het plaatsen van een reactie zonder volledige page-refresh), maakt dat het toch veel kan toevoegen. Zet dan in op het verbeteren van Javascript en strenger controleren op het misbruiken van clicks en views. Benadeel sites met full-page advertenties of andere hinderlijke zaken. Maar ga niet moeilijk doen met een nieuwe standaard die zogenaamd voor trage mobieltjes moet gaan werken. Dan doe ik dat liever zelf door te kijken hoe lang een device over het laden van de content doet om dan te bepalen welke dingen ik verder nog wel of niet ga inladen.
Vraag je zelf eens dit: zijn de pagina's waarop de 'verboden' tags staan nuttig om te vinden in Google? Een formulier om in te loggen bijvoorbeeld. Of zoeken. Dat kan allemaal prima op een pagina die niet 'amp' is.

Het idee erachter is, denk ik, de pagina's die je wil LEZEN sneller te maken. Pagina's waarop je interactie verwacht zullen hetzelfde blijven.

Het nieuws en reviews gedeelte van tweakers past hier bijvoorbeeld prima in. Helemaal geen fancy js of forms voor nodig. Alleen de zoek input in de balk verhuist dan naar een aparte pagina.

[Reactie gewijzigd door Montaner op 7 augustus 2024 16:13]

Dus jij zoekt in Google alleen om dingen te lezen? Dat is wel heel kortzichtig. Dit is alsof je het zadel, de verlichting en de spatborden weghaalt bij een fiets "want ja, iedereen fietst toch overdag als het droog is en is binnen notime op bestemming, je hebt de rest niet nodig". Fuck dat, wie is Google om te bepalen wat wel of niet nodig is?

Alleen zij hebben er echt wat mee te winnen (ze kunnen zo immers sites gaan uitsluiten).

[Reactie gewijzigd door Martinspire op 7 augustus 2024 16:13]

Ik begrijp je punt.

Ik ben het ook met je eens dat het web er zeker beter op is geworden met user input.
Aan de ene kant kun je met Javascript een mooie responsive website in elkaar klussen, aan de andere kant laat je er mee een bitcoin miner draaien. With great power comes great responsibility, zeg maar.

Uit het nieuwsbericht kan ik niet opmaken dat AMP een soort verplichting wordt. Een ontwikkelaar kan er met de komst van AMP nog steeds voor kiezen om een pagina in normaal HTML/JS te schrijven. Het is een beetje de vraag wat Google er mee doet in de search results.

Vooral omdat het optioneel is ben ik wel blij met de komst van AMP. Misschien dat het ontwikkelaars aanspoort om wat kritischer te kijken naar wat er allemaal in een pagina wordt gestopt.
Wel googleapis toestaan.... Pfff. Als je niet van machtsmisbruik beschuldigd wilt worden moet je vooral uitzonderingen voor jezelf gaan inbouwen.
Als ik die lijst zo zie denk ik dat er alleen text-based sites voldoen aan die eisen en daarbij heb je dus geen enkele mogelijkheid tot interactie of dynamiek.
Wat is daar mis mee? Text-based lijkt mij een stap in de richting van KISS. Veel van die zooi op het internet kan veel efficienter en simpeler als het voldoet aan:
  • text
  • hooguit enkele plaatjes
Commerciele lui willen wat aantrekkelijke animaties, tracking, statistieken, klantbinding etc zodat ze meer kunnen verkopen, maar vanuit technisch oogpunt is dat helemaal niet efficient. En ook niet KISS. Je wilt tenslotte een boodschap overbrengen van A naar B via het internet.
Daar ben ik het niet mee eens. Sites worden mooier en uitgebreider omdat daar vraag naar is en omdat dat nou eenmaal beter werkt. Kijk naar Tweakers, die had ook simpeler gekund, maar had dat fijner gewerkt? Had je er dan vaker gekomen? Ben je dan geneigd meer interactie aan te gaan? Ik betwijfel het.

Verder sloop je door formulieren niet toe te staan, elke vorm van interactie. Iets wat ook wel bij het web hoort. Als we alleen teksten wilden delen, hadden we wel bij jaren 90 forums gebleven of blijven emailen. Het hoe en waarom van het web is gegroeid, ook mede door de ontwikkelingen op het vlak van styling en scripting. En ja, net als elke andere markt, wordt er misbruik gemaakt van bepaalde zaken. Toch ben ik blij dat ik online mijn bankzaken kan doen, dat ik kan communiceren met anderen, dat ik me kan laten informeren op veel verschillende manieren en dat ik op veel verschillende manieren kan werken met het internet.

Daarbij jaag je zo mensen naar apps toe in plaats van de website, iets wat ik een ernstigere actie vind dan dat een site misschien wat grote advertenties heeft of niet goed omgaat met statistieken. Als alles in een app veranderd, heb je er minder controle op en verhuist de macht van het web naar slechts een handvol leveranciers van content.
Sites worden mooier en uitgebreider omdat daar vraag naar is en omdat dat nou eenmaal beter werkt. Kijk naar Tweakers, die had ook simpeler gekund, maar had dat fijner gewerkt? Had je er dan vaker gekomen? Ben je dan geneigd meer interactie aan te gaan? Ik betwijfel het.
Zeker wel dat ik normaal gebruik zou maken van de site. Soms lees ik websites met lynx in een text console. Jammer dat veel websites niet gebouwd zijn op text consoles, of eventueel text met hooguit enkele plaatjes. Het gaat mij puur om de content en de snelheid van het laden. Ik ben niet iemand die op Tweakers komt met als hoofddoel de spetterende advertenties te lezen. De kleur van de website boeit me ook niet. Ik kom puur voor de content. IRC werkt ook tekstueel en daar heb ik geen moeite mee. Als je grafische meuk zichtbaar wil maken op IRC, dan plaats je een linkje naar een website. Daar heb ik geen moeite mee.
Volgens mij ben je wel een uitzondering met lynx en text console ;)
Reddit is ook vooral tekstueel met weinig poespas, toch is het één van de meest bezochte websites ter wereld. Mooier en vernuft werkt niet altijd beter. Ik denk dat amp gericht is op simpele informatiebronnen zoals nieuwssites, woordenboeken, encyclopedieën etc. waar men enkel krijgt wat er precies gevraagd wordt door de gebruiker. Als je dan user input nodig is, kan er gewisseld worden naar een gewone HTML pagina met de nodige JS, en die nog steeds mobiel goed presteert.
Prima dat ze zich daar op richten, maar zo brengen ze het niet.
En als je constant moet wisselen of voor elk wissewasje de andere site nodig hebt, waarom zou je dan nog voor AMP gaan werken?
Google bepaalt voor het grootste deel hoe HTTP/2 werkt, domineert de browsermarkt, bepaalt wat we wel en niet vinden en hoe we onze websites wel en niet moeten inrichten. Zo krijgen HTTPS en responsive websites al voorrang in de zoekresultaten. Het internet == Google. En niemand die zich hier druk om maakt?? Het is namelijk wel een commercieel bedrijf dat heel graag geld wil verdienen. Het liefst met jouw privégegevens...

[Reactie gewijzigd door Faeron op 28 juli 2024 00:13]

Het staat je vrij om andere browsers, zoekmachines en maps te gebruiken. Er is keuze genoeg omtrent al deze zaken. En Google verplicht je helemaal niet hoe je website eruit ziet. Het wil enkel lichtere pagina's vooraan zetten wat het gebruiksgemak enkel voordeel toe brengt.

Ik juich net zo'n zaken toe en hoop dat ze die ontwikkeling verder steunen.
"Het staat je vrij om andere browsers, zoekmachines en maps te gebruiken"

Dit is een vaakgehoorde stelling waarbij de daadwerkelijke problematiek niet begrepen wordt. Het gaat niet om gebruikers, het gaat om aanbieders. Website eigenaren dus.

Website eigenaren kunnen niet switchen, die moeten in Google gevonden worden. En om in Google gevonden te worden, dien je exact naar hun pijpen te dansen. Wanneer Google zegt dat performance belangrijk is, dan tune je je site (even los van dat je dit toch wel zou moeten doen). Wanneer Google vind dat micro formats belangrijk zien, dien je dit te volgen. Wanneer Google zegt dat HTTPs voortaan de default is, dien je te switchen. Wanneer Google HTTP/2 bevorderd, dien je mee te gaan.

En zo gaat de lijst maar door. Je kunt niet switchen als eigenaar van een website. Google's macht is zo groot dat het in feite bepaald of jij als website bestaat of niet.
Zodra Google eisen gaat stellen die slecht zijn voir gebruikers of het internet ga UK klagen. Tot dan kan ik alleen zeggen: jammer dat andere zoekmachines niet zo'n vooruitstrevend beleid hebben. Een sneller, veiliger internet is niet zo slecht...

En ja, je hebt natuurlijk gelijk dat de macht van Google te groot is, dat is niet goed. Gelukkig misbruiken ze het nog niet. We weten dat Apple en MS minder netjes zijn, wat dat betreft.
Het uit het niets toveren van een compleet nieuw HTML dialect zonder dat dit maar in de buurt is gekomen van W3C lijkt me een duidelijk geval van misbruik.
Het staat je ook vrij om geen wegenbelasting te betalen en je eigen wegen aan te leggen op prive gronden.. als de infrastructuur eenmaal ligt en behoorlijk rigide is word het moeilijk om andere paden te bewandelen...
Het bepaalt het wel degelijk voor een deel. Ze geeft in de zoekresultaten namelijk voorrang aan websites die aan hun eisen voldoen. HTTPS en responsive websites krijgen namelijk al voorrang.
Toch alleen maar beter!? Waarom zouden website's die ingericht zijn voor gebruiksgemak geen voorrang krijgen op websites die voor geen meter werken op mobile devices!?
Toch alleen maar beter!? Waarom zouden website's die ingericht zijn voor gebruiksgemak geen voorrang krijgen op websites die voor geen meter werken op mobile devices!?
Het gebruiksgemak is in mijn ogen een slecht argument als je gewoon driekwart uit je website ript. Nu kunnen gebruikers op mijn websites een berichtje achterlaten of contact opnemen via een formulier. Zowel voor mij als de klant is dat ideaal. Of neem bijvoorbeeld bepaalde javascripts die content inladen in meerdere tabbladen: de gebruiker krijgt geen overload aan informatie en kan content tonen waar hij interesse in heeft. Zijn die opties niet juist gebruiksvriendelijk?

Ik vind dat Google wel erg ver wil gaan en haar zin wil doordrukken. Laat websites gewoon zelf werken aan gebruiksvriendelijkheid en geef ze tips om hun site te verbeteren (zoals bijvoorbeeld Google PageSpeed Insights doet). Websites met lompe banners zoals popover / under mogen wat mij betreft minder prominent getoond worden, maar om websites te verplichten (want daar kun je niet omheen) driekwart van hun content en functionaliteit om te gooien gaat gewoon te ver.

Bovendien slaat Google ook nog wel eens de plank mis. Een van onze sites scoorde minder hoog in Google. Navragen leverde de reactie 'de website is niet gebruiksvriendelijk, content kan niet gevonden worden'. Wat ze even vergeten waren is dat er een grote zoekbalk op de website te vinden is waar 95% van alle pageviews vandaan komen. Maarja, geen links of menustructuur: dus gebruikersonvriendelijk en dus een penalty. Dat terwijl het in feite niets anders is dan de Google homepage.
Als ik zoek gaat het om content, niet om gebruikersgemak. Vaak zat dat ik op websites van tien jaar oud kom waar niets meer aan gedaan is, maar wel de info bevatten die ik zocht. Ik Bing dan ook...
Nou zijn die websites van 10 jaar oud vaak niet overspoelt met full page popups voor newsletters en "(pc) enhancers".
Nee, maar als ze niet meer of veel lager in de zoekresultaten opduiken dan de bevoorrechte sites, heeft dat wel invloed op het vinden van content. En dáár was zoeken voor bedoeld, toch?
Omdat gebruiksgemak een nogal vaag begrip is. Ik vind de command prompt het toppunt van gebruiksgemak, maar iemand anders heeft veel lieve een gui.

En gebruiksgemak is niet het criteria voor de ranking, maar het gebruik van de techniek van Google. En die techniek grijpt nogal in hoe en welke advertenties op een pagina getoond worden. Advertenties is de core business van Google. Ik wil er nog geen waarde oordeel over geven, maar je moet hier heel erg alert zijn op machtsmisbruik.
HTTPS en responsive websites krijgen namelijk al voorrang.
Misschien is Google voor deze zaken dus een 'necessary evil', omdat het ondertussen 2015 is en er zonder Google nog steeds veel sites zouden zijn die beide niet implementeren?
Waarom zou je de overhead van https willen hebben op het moment dat een site alleen maar kale data verstuurd en je er niet op hoeft in te loggen?
Zoveel impact hoeft https niet te hebben op performance. Eén extra roundtrip. Waarom is simpel, gaat niemand wat aan wat je bezoekt. D'r wordt steeds meer bijgehouden en je kan altijd wel iets als verdacht zien.
CPU gebruik is ook hoger, voor simpele websites gewoon niet nodig. En wat je bezoekt zien ze alsnog, ze kunnen natuurlijk altijd zelf nog naar nieuws: Google linkt vanaf begin 2016 naar snellere en lichtere amp html-pagina's toe surfen om te kijken wat hier allemaal gebeurd.

Maar jij (en Google) willen mensen/bedrijven/organisaties gaan verplichten een bulk extra geld uit te geven voor hun websites waar dit gewoon overbodig is?
Zoveel impact hoeft https niet te hebben op performance. Eén extra roundtrip. Waarom is simpel, gaat niemand wat aan wat je bezoekt. D'r wordt steeds meer bijgehouden en je kan altijd wel iets als verdacht zien.
Het punt is dat SSL voor de gemiddelde website gewoon veel te duur is. De bakker die even zijn openingstijden op de website zet of de buurman met zijn contactgegevens voor zijn timmerbedrijf willen nou eenmaal geen honderden euro's per jaar uitgeven aan een website (hosting, ssl, noem het maar op). En die gratis certificaten die ze zelf kunnen installeren gaat simpelweg niet. Die mensen gaan niet zelf aan de gang zoals wij tweakers zouden doen en de host waarbij ze zitten biedt hoogstwaarschijnlijk zelf SSL voor een meerprijs aan.

Privacy vind ik erg belangrijk. Maar ik kan mij goed voorstellen dat kleine websites geen SSL nemen en dat dat vaak ook helemaal niet boeiend is. Laat ik mijn moeder als voorbeeld nemen. Zij zet eens in het jaar wat kattenfilmpjes op een pagina om aan mensen de jonge katjes te laten zien die zij via Marktplaats aanbied. Je kunt van haar toch niet verwachten dat ze SSL gaat regelen voor haar pagina? Ik begrijp je probleem, maar van heel veel sites kun je simpelweg geen SSL verwachten. En dat is naar mijn mening vaak ook helemaal geen probleem. Als je niet wilt dat iemand het kan zien, moet je niet naar pagina's gaan die zonder SSL draaien. Het world wide web is ontstaan als open platform. Iedereen is vrij om zijn of haar pagina toe te voegen, ook zonder SSL.

[Reactie gewijzigd door Zenomyscus op 7 augustus 2024 16:13]

Waarom zou je de overhead van https willen hebben op het moment dat een site alleen maar kale data verstuurd en je er niet op hoeft in te loggen?
Omdat het niemand wat aangaat welke content ik opvraag. Dat is tussen mij en de site die ik bezoek. Tevens wil ik een potentiële man-in-the-middle niet verleiden om het verkeer tussen mij en de opgevraagde site te modificeren.

Bovendien denk ik dat er meer overhead is in bijvoorbeeld het overmatig gebruik van JavaScript.

[Reactie gewijzigd door The Zep Man op 7 augustus 2024 16:13]

Zoveel overhead is er niet eens meer, het verschil is tegenwoordig een paar ms, amper merkbaar dus. Hier zijn genoeg benchmarks voor te vinden.
Google bepaalt daarin helemaal niets, er zijn namelijk diverse frameworks om responsive websites mee te bouwen, Bootstrap is daar echt niet de enige in, wel de populairste, dat is wel iets anders. Je bent tegenwoordig ook niet verplicht om OpenSSL te gebruiken om je website in HTTPS aan te bieden, LibreSSL kan bijvoorbeeld ook (al is dat ook een fork van OpenSSL) en er zullen vast nog wel meer alternatieven voor zijn.

Dat HTTPS en responsive voorrang krijgen, boven pagina's die dat niet hebben, is alleen maar logisch, zeker anno 2015, waarin gebruiksgemak heel erg op de voorgrond staat en waarom zou je onderscheid willen maken in waarmee iemand een website bezoekt en de content die dan zichtbaar wordt of niet (of gewoon zelfs niet werkt)? Dat zou ik alleen maar onlogisch vinden en Google vindt dat ook.

[Reactie gewijzigd door CH4OS op 7 augustus 2024 16:13]

Die eis wordt massaal genegeerd. Dat https gebeuren wordt sterk overdreven.
Bedrijven zijn 'verplicht' hun sites te optimaliseren voor Google en te dansen naar Googles grillen, want bijna alle consumenten gebruiken Google's zoekmachine. Bedrijven zijn niet zo vrij om naar een andere zoekmachine over te stappen want dan worden ze niet meer gevonden door consumenten.

En het gaat Google niet om een beter gebruiksgemak. Dat is slechts een middel om consumenten buiten apps (want dan zijn ze buiten Googles add netwerk) te houden. Facebook probeert het omgekeerde. Die probeert meer content in de app te krijgen zodat je binnen Facebooks add netwerk zit.

[Reactie gewijzigd door Verwijderd op 7 augustus 2024 16:13]

Search Engine Optimization behelst wel wat meer dan enkel zorgen dat Google je website zo goed mogelijk 'ziet'. Daar kan je bijna een hele studie aan wijden, hoe een website voor een search engine er zo goed mogelijk mee uit de verf komt. Maar dat alleen is niet meer voldoende, je wilt ook opvallen, want jouw content kon nog best eens sterk lijken op dat van een ander, bijvoorbeeld. ;) Je moet dus ook populair zien te worden, om het simpel te zeggen.
Je moet populair worden op de manier die Google kwalificeert als populair.

Op mijn desktop gebruik ik nog Google en op mijn telefoon Duckduckgo. Op zich is alles wel te vinden, maar vooral de volgorde en wat op pagina 1 staat verschilt. Dus het maakt nog wel uit waarvoor je optimaliseert. En dan is Google de belangrijkste om hoog in de ranglijst te komen.
En Google verplicht je helemaal niet hoe je website eruit ziet.
Ehm, dat doen ze dus wel. Enerzijds omdat reclame niet meer op de huidige manier mag worden toegepast, plus enkele andere zaken die zeker wel effect gaat hebben op hoe websites werken (wat in principe weer effect heeft op het design).

Nee, dit is gewoon een verkapte manier om reclames en analytics aan banden te leggen die voor Google het beste uitkomen.
Google probeert inderdaad grip te houden, en maakt dit soort panieksprongen om dit te bereiken. Voor een heleboel mensen is Facebook synoniem voor internet.

En daarnaast krijgen ze steeds meer concurrentie van apps die de internetinfo voorschotelen (denk aan alle nieuws-apps, offline readers, maar ook instagram en snapchat). Dit soort apps leveren nu eenmaal een veel prettiger gebruikerservaring dan een website (want dankzij complexe htmls/javascriptt, webfonts en alle onderliggende trackers laadt een gemiddelde webpagina supertraag in vergelijking tot native apps).

Dus Google hoopt het tij te keren met deze techniek (maar ik denk dat dit te laat komt, en Google denkt dat vermoedelijk ook, vandaar dat ze dit zo hard pushen).
Vergeet de standaard ad-block bij Apple niet.

Google kan niet altijd zijn motieven vertellen, maar dat lijkt me een serieus issue. Zou me niet verbazen dat bij deze groep gebruikers een extreem groot deel deze heeft aanstaan of zelfs een extra app gebruikt.

En eenmaal bekend wil je niet meer terug. Een site van een telegraaf bevat bijvoorbeeld ook nieuws.

Problematisch voor google is dat veel apps adverteren dat je minder mobiele MB gebruikt, en dat zo'n app zichzelf terugverdient. Voor mij geen wiskunde, en voor veel gebruikers met een limiet hebben hier ook oren naar.
dit argument slaat nergens op van de website eigenaar zijn kant, even uit mijn "bronnen" van analytics

70% google organic, 1,92% bing organic

Dat betend dus grofweg dat ~70% van mijn verkeer wegvalt als ik niet naar de pijpen van google dans, terwijl ik het er volledig mee eens ben dat responsive en https (TLS tegenwoordig ipv ssl wat in de volksmond blijft hangen) is gewoon goed, certificaten voor de hobbyist zijn gratis (Startssl.com), je kunt ze zelf genereren (oke niet echt relevant voor publiek verkeer), en bijvoorbeeld comodo certificaat kost ook maar 5-15 euro per jaar afhankelijk van de partij waar je hem koopt.

Het internet word met volledig TLS beveiliging een stuk veiliger, en responsive websites zorgen er ook voor dat het ook op de (steeds verschillender wordende) resoluties allemaal goed werkt. Wie maakt er tegenwoordig nog een niet-responsive site vanaf 0?
Het gaat er niet om of je het er mee eens bent dat Google website eigenaren een bepaalde richting opduwt, het gaat er om dat men uberhaupt de macht heeft om dat te doen.

Zelfs wanneer dit goede verbeteringen zijn, is het nog steeds bizar dat een beursgenoteerde, op winst beluste onderneming in feite de baas van het internet is.
Zolang ze dit soort dingen vrij toegankelijk maken voor ontwikkelaars door de broncode vrij the geven, zie ik geen problemen.
En als ze de werking van het internet echt volledig in handen hebben, welke garantie heb je dan dat ze toekomstige technologieën ook open en vrij geven? Het is een commercieel bedrijf dat heel graag geld wil verdienen. Het liefst met jouw privégegevens...
Google will advertenties verkopen.
Het doel van dit sport projecten is het toegankelijker maken van het internet. Toegankelijker internet = meer inkomsten uit advertenties.
Ik lees hieronder dat amp html gebaseerd is op een js library. Van Google uiteraard. Dus geen standaard, en afhankelijk van Google. Ze proberen het nu nog meer te pushen door hun macht in de zoekmachinemarkt er tegenaan te gooien. Als dat geen machtsmisbruik en vertoon van dominantie is weet ik het ook niet meer.

En natuurlijk kun je gewoon een andere zoekmachine gebruiken die geen voorkeur heeft voor de Google bubble, maar als je dan op websites komt die amp html gebruiken ben je verplicht om Google meuk in te laden. Nu heb je met sommige slecht geschreven pagina's al dat bepaalde elementen niet meer werken als je Google Analyics blokkeert, maar zo'n pagina werkt natuurlijk uberhaupt niet als je Google blokkeert.
En zo wordt langzaamaan het internet steeds meer Google-only. Je hebt maar 2 keuzes: jezelf laten tracken door 's werelds grootste online advertiser of een gedeelte van het web niet meer op kunnen. Deze trend was al ingezet door Facebook en hun login-wall, en Google probeert nu z'n eigen territorium te pakken. Een zorgelijke ontwikkeling imho.
Het feit dat we het op deze manier te weten moeten komen (ipv via grote presentatie) geeft al aan hoe sneaky dit moet gebeuren. Kijk, dat je geoptimaliseerde pagina's wilt prioriteren is prima, maar Google behoort daar niet de spelregels voor te maken. Plus dat het wel een hele aparte library is die ook nog eens indruist met een aantal andere optimalisaties.
Dit ziet er eerder uit als een verkapte manier om andere analytics te gaan verbieden.
Dit is natuurlijk buiten het feit gerekend dat google de hele search markt in handen heeft en elke web developer naar de pijpen van google moet dansen om een goede rating te verkrijgen. Als google amp html gaat meerekenen in de score van de indexing, zou dat mijns inziens heel veel kunnen veranderen.

Het hele concept van amp html is overigens maar bizar. Het doel is ondermeer om javascript te beperken (ok, voornamelijk van externa partijen), maar het is zelf een javascript library die voornamelijk zelf verzonnen html tags gaat aanpassen naar normale html afhankelijk van de browser.

Mochten webdevelopers zich gewoon aan standaarden houden en het gebruik van javascript sowieso wat proberen te beperken, zou hier weinig nood aan zijn. Het gebruik van iframes voor advertenties is inderdaad een oplossing, maar is bijna meer een js hack dan iets anders.
usenet was en is ook vrij toegankelijk, toch begon een paar jaar geleden iedereen het al Google te noemen.

Het is nooit een goed idee om ergens een monopolist te hebben rondlopen. Standaarden zet je met een comité.

[Reactie gewijzigd door mae-t.net op 7 augustus 2024 16:13]

Domineert de browsermarkt? Chrome heeft een groot aandeel (bijna 60%), maar de browsermarkt ermee domineren, nee, verre van, dat deed Internet Explorer in diens hoogtij dagen wél.

Daarnaast heeft Google drafts voor HTTP/2 en bepaald het - en zeker niet als enige - hoe het nieuwe HTTP protocol te werk gaat, leuk dat het op SPDY gebaseerd is, maar meer dan dat is het niet en is er een Working Group ingesteld (het IETF doet dit) om HTTP/2 verder te standaardiseren. Ook wordt HTTP/2 amper nog gebruikt (volgens Wikipedia 1,9% van de top 10 miljoen websites).

Dat HTTPS en responsive websites voorrang krijgen, boven pagina's die dat niet hebben is alleen maar logisch; zo krijgt de eindgebruiker meer veiligheid op de pagina (want HTTPS) en wordt er gebruik gemaakt van de nieuwste technologiën, omdat de website responsive is, zodat het niet uitmaakt waarmee (mobiel, tablet of desktop) de gebruiker jouw pagina's bezoekt. Zo technisch hoogstaand of moeilijk is HTTPS en responsive echt niet (meer). Het gaat tegenwoordig steeds meer om veiligheid en gebruiksvriendelijkheid, op deze manier kan Google dat dus alleen maar toejuichen.

Dus nee, Google is niet hetzelfde als het internet, verre van zelfs; je bent bovendien ook niet verplicht om Google te gebruiken. Google maakt dan weliswaar een profiel over jou aan, met o.a. jouw zoekgeschiedenis e.d, maar dat is allang hun core business niet meer.

Daarnaast is Google ook niet de enige die graag gebruik maakt van jouw privé gegevens, er zijn er meer die dat doen. Denk maar aan Facebook, om een andere grote partij te noemen.

[Reactie gewijzigd door CH4OS op 7 augustus 2024 16:13]

Dat HTTPS en responsive websites voorrang krijgen, boven pagina's die dat niet hebben is alleen maar logisch; zo krijgt de eindgebruiker meer veiligheid op de pagina (want HTTPS) en wordt er gebruik gemaakt van de nieuwste technologiën, omdat de website responsive is, zodat het niet uitmaakt waarmee (mobiel, tablet of desktop) de gebruiker jouw pagina's bezoekt.
Maar sites die HTTPS en/of responsive zijn hoeven niet per definitie het beste antwoord op je zoekresultaat te geven. Dat is toch ook wel van belang lijkt mij.
Responsiveness betekend ook betere leesbaarheid op mobile devices. Als ik een zoekopdracht heb gedaan, maar de site is brak leesbaar, doordat het niet responsive is, ga ik gauw weg van de site, zeker als ik met een mobile device de site bezoek en dan maakt het mij niet uit of het gegeven antwoord het beste antwoord is voor mijn zoekopdracht of niet. Gebruiksgemakt staat zeker op mobile devices wat dat betreft hoger.

Met andere woorden; het gebruiksgemak van de site bepaald of ik (zeker op mobile devices) mijn antwoord ga zoeken op de site of niet. Vanaf desktop is dit natuurlijk minder van toepassing, tenzij het een oude IE6 only pagina is.

[Reactie gewijzigd door CH4OS op 7 augustus 2024 16:13]

Ik maak me er wel druk om. Los van of Google het juiste bevorderd of niet, het is verschrikkelijk eng hoeveel macht Google heeft. Het bepaald in feite al zo goed als alle toegang tot informatie, en daarmee heeft het ook de macht de technische toekomst van het internet te bepalen.

Alhoewel AMP open source is, komt het uit het niets opzetten en het gaat geheel buiten het W3C om. Men vind dus even doodleuk een nieuwe web standaard uit. En gezien de macht zullen publishers wel mee moeten doen.

Weinig mensen staan hier echt bij stil. De macht is onmetelijk en ongekend groot.
Als je op Github kijkt, zie je dat AMP HTML een subset van HTML is. Indirect heeft W3C dus wel degelijk invloed erop. AMP HTML is niets anders dan een gestandaardiseerde manier van het opzetten van een (mobiele) webpagina in HTML5 in combinatie met CSS3 en Javascript.
Het is niet gestandardiseerd, het is een verzinsel van Google. Zomaar subsets van standaarden aanbieden als nieuwe standaard en websites indirect dwingen er aan mee te doen is een belachelijke gang van zaken.
Dat doen we in principe helemaal zelf, niemand die je verplicht google.nl/.com te gebruiken of Chrome te installeren, het is nergens geforceerd zoals dat toentertijd wel met MSIE is gegaan. Niets wat iemand in de weg staat om een andere search-engine te gebruiken en een andere browser.

Hier op tweakers en vergelijke techsites over de wereld zal het gemiddelde van gebruikte alternatieven wel wat hoger liggen zoals DuckDuckGo e.d. en alternatieve browsers, maar alles bij elkaar is dat nog steeds een heel kleine gebruikersgroep... de doorsnee gebruiker zal doorgaans niet verder komen dan een search met google en in mindere mate Bing en Yahoo, qua browsers het gebruik van MSIE/Chrome/Firefox en Safari.

Maar het is uiteraard te beredeneren dat Google het qua gebruiksgemak etc. het wel goed voor elkaar heeft, persoonlijk krijg ik ook nog altijd de beste zoekresultaten met google en blijkt in de praktijk Chrome mij ook de minste compatibiliteitsproblemen op te leveren.
Ehm, dan gebruik je toch yahoo ofzo.. stel je niet zo aan.
Aanvullend vind ik het vreemd om javascript te ontmoedigen, juist op het moment dat template-based websites (angular, meteor, etc) een opmars lijken te maken en door data/content te scheiden op sites de boel vlotter maken voor trage verbindingen.
Maar je kunt een site met angularjs (wat overigens ook door google word ontwikkeld) nog steeds bijzonder zwaar maken. Het heet dan ook "Accelerated Mobile Pages", niet voor alle doeleinden.
Web performance is not unexplored territory for the tech community: books have been written about it, many talks have been given – there is even an entire conference series dedicated to the topic. However, users still frequently see poor web performance in the wild, particularly on mobile devices.

Consumption of news articles, and similar relatively static content, is often painfully slow, with pages taking a long time to load. Even after text becomes visible, pages continue to build up over many seconds, as ads and images come into display. The result is an often jarring experience of janky scrolling and users needlessly losing their reading position.
Dat proberen ze hiermee op te lossen.
Maar dan is het toch beter om guidelines op te stellen en websites te laten testen (wat ze in zekere zin al wel doen) om sites te verbeteren? Dit lijkt me redelijk geforceerd en ik vraag me af hoeveel sites hier graag gehoor aan gaan geven. Zeker ook omdat ze nu eenmaal op bepaalde manier aan hun reclameleveranciers en analytics vastzitten.
Die analytics worden geserveerd met pixeltrackers (helaas).
Er zijn al grote sites die hier aan mee doen. Zie hier onderaan.
Ja en Nee. Voor gewone websites wordt het niet vaak gebruikt, wel voor webapps e.d. (daar maakt het toch minder uit dat het een seconde langer duurt om te laden en zijn meestal niet direct beschikbaar vanuit de zoekmachine). Maar het is inderdaad wel apart gezien meer sites interactiever worden.
Niet vaak inderdaad, maar wel steeds meer: vi.nl en ajax.nl draaien bijvoorbeeld al op AngularJS. Persoonlijk vind ik dat voor de eindgebruiker geen slechte keuze omdat de sites vlot(ter) aanvoelen (ook op mobiel).
Maar ik weet ook niet wat Google als 'zware' javascripts beschouwt!?
Externe javascript (i.e. alles behalve de AMP library) wordt ontmoedigd (= niet toegestaan). Dat zegt verder nog niets over in hoeverre de AMP library zelf mogelijkheden biedt om opmaak en data te scheiden. Geen idee overigens of dat soort functionaliteit er in zit.

Aan de andere kant: Misschien ontmoedigt AMP het wel bewust, omdat door die scheiding data niet meer in "gewone html" staat, maar in inline script elementen als json, of helemaal van buiten het document gehaald wordt, en dat Google daar last van heeft omdat pagina's dan minder makkelijk te indexeren zijn...
"Javascript van externe partijen is op amp html-pagina's niet toegestaan, waardoor advertenties alleen in iframes kunnen."

Onverwachte actie van Google: een heel groot deel van hun verdienmodel hangt nu juist af van ads&JavaScript. Als veel sites hier op zouden overstappen, dan kost dat hen een boel geld. Al zal ik er niet rouwig om zijn als ads weer wat meer 'gewoon .jog' of tekst worden zonder scripts.

Aan de andere kant: iframes op op smartphones gerichte pagina's: ieuw.
Als veel sites dat doen, worden dat soort advertenties de basis. Adverteerders hebben de keuze tussen "geen advertentie" of deze "statische advertentie". Denk niet dat Google daarbij (veel) op prijs zal inleveren.
iFrame != statische advertentie. Het staat de server die het iframe serveert vrij daar iedere keer iets anders voor aan te leveren.
...ik mag toch aannemen dat er wel restricties liggen aan de content van het iframe? (anders krijg je straks alsnog 30meg aan flashfilmpjes binnen)
Geen idee hoe ze dat willen opleggen/controleren. In principe kan je alles wat je wil in een iframe stoppen, zelfs een volledige website.

En ja dat kan dus ook een 30meg filmpje zijn.

Het voordeel is dat als je de juiste maat voor de iframe al mee geeft, de hele pagina al werkt voordat deze iframe is geladen en de opmaak niet meer wijzigt.

Als ik het goed heb ben je zo wel van die irritante reclames af die over je webpage heen liggen en de content verbergen.
Net eens opgezocht, blijkt dat men een nieuw type iframe introduceert: amp-iframe. Lijkt er op dat er wel wát restricties worden gelegd, maar niet op het type content (zou immers eerder vanuit een render-engine voortkomen dan uit de documentstandaard). Grappig genoeg wordt er wél de mogelijkheid geboden om de grootte van het iframe nog aan te laten passen tijdens runtime.
Daarnaast vraag ik me af of dit dan ook niet belemmerend is voor CDN netwerken, die zich hebben gespecialiseerd om niet alleen bestanden betrouwbaar te hosten, maar ook nog eens sneller (en omdat het op een ander domein staat, kun je meer bestanden inladen omdat het aantal connecties omhoog gaat)
Er mist een essentieel stuk in dit verhaal: Google geeft wel brede support voor pixeltrackers, zo kunnen ze alle adblockers omzeilen en de mens toch blijven tracken over het web, dit samen met iframe ads - wat overigens niet de definitieve oplossing is.

Dat het nu geaccelereerd word snap ik gezien ad-blocken aan de orde van de dag is.

[Reactie gewijzigd door z1rconium op 7 augustus 2024 16:13]

Ik ben niet bekend met zogenaamde iframes, maar gaan we straks weer verspringende pagina's krijgen, omdat de advertenties pas later worden geladen?
Bij een incorrecte implementatie kan dit inderdaad voorkomen. Maar dat zie ik op dit moment ook al vaak genoeg. Ik zag net dat de homepage van deze site ook verspringt door de grote Galaxy S6 banner.

Nu weet ik wel niet of AMP hier specificaties rond heeft. Blijkbaar heeft AMP hier specificaties rond "Resources must declare their sizing up-front" ads worden expliciet genoemd.

[Reactie gewijzigd door MrSnowflake op 7 augustus 2024 16:13]

In principe krijgt een iframe een vooraf gedefinieerde breedte en hoogte mee, in de huidige situatie gebeurt het inderdaad vaak dat de ontwikkelaars achteraf met Javascript de grootte van het iframe aanpassen aan de inhoud die erin verschijnt. Echter is dit in deze situatie niet meer mogelijk, omdat AMP een javascript-loze omgeving zou moeten worden. De ontwikkelaars zullen dus veel meer moeite vooraf moeten doen om de iframes op de juiste groottes te zetten, of de content aan te passen naar geschikte groottes. In dat geval zullen bezoekers dus veel minder last krijgen van verspringende pagina's dan nu het geval is!
iframes geef je een bepaalde hoogte en breedte, dus als het goed is verspringt de pagina zelf niet zolang het iframe maar geladen wordt maar de content van het iframe nog niet,

Je zou een iframe een beetje kunnen zien als een aparte browser tab allen dan in HTML.
Dus je opent content van 3de binnen jou pagina.
Geen extern javascript? Opvallende move. Meetpixels zijn toch een stuk minder uitgebreid als Analytics, lijkt mij toch een vrij belangrijke tool voor Google.
En hoe zit dat dan met CDN's? Het hele idee achter CDN's is toch juist dat ze het internet sneller maken? :)
Ze zullen wel uitzonderingen in hebben gebouwd voor hun eigen meuk. Dat lijkt me echt iets voor Google. Ze hebben het al eerder geprobeerd door adblockers in Chrome uit te zetten op bv youtube. En dan beweren dat het een bug was... ik geloof niet in sprookjes.
Geen javascript van de publisher zelf of van 3rd party (bv. ad / analytics servers). Maar dat wil natuurlijk niet zeggen dat er in de AMP javascript library niet voldoende mogelijkheden voor ads en analytics ingebouwd gaan worden:
Ensuring that traffic to AMP articles is counted just like current web articles is also a major focus of the project. comScore, Adobe Analytics, Parse.ly and Chartbeat have all stated that they intend to provide analytics for AMP pages within their tools. They have since been joined by many others: Nielsen, ClickTale and Google Analytics.
Our vision is to deploy a single, unified, auditable, high performance, open source analytics library with AMP HTML that can report to various existing analytics provider backends, ...
Today we’re announcing that Outbrain, AOL, OpenX,, DoubleClick, and AdSense are working within the framework to improve the advertising experience for users, publishers and advertisers on the mobile web.
Controle over de library (ook al is die open source, hoeveel partijen zullen er hun eigen versie van gaan forken?) geeft Google indirect natuurlijk nog meer invloed op de ad/analytics markt.
Verder lijkt het ook een grotere rol te willen toebedelen aan CDN partijen, waaronder ook weer Google zelf:
Our goal with AMP HTML is reliable performance, so we designed it to be easily cacheable by content delivery networks (CDNs). Google is offering a service that delivers AMP HTML documents given their URL through its CDN. Others can use this service or make their own or serve AMP HTML pages from a plain-old-web-server.
By using this AMP format, content producers are making the content in AMP files available to be crawled, cached, and displayed by third parties.
... they are also designed to be optionally served through specialized AMP serving systems that proxy AMP documents. These documents serve them from their own origin and are allowed to apply transformations to the document ...
Hmm Betekent dit automatisch dat je niet meer van die grote overlappende ads meer krijgt die over de feitelijk pagina heen komen?
Het klinkt namelijk alsof ads in een vooraf gedefinieerd i-frame hier niet buiten kunnen komen.
Dat zou voor mij in ieder geval al redelijk wat ergernis schelen.
Dat kan dan inderdaad niet meer. Net als de adds dan geen info meer van de site zelf kunnen scrapen.
Nog makkelijker voor ad blockers dus, gewoon elke iframe blokkeren.
Dat is niet zo handig. Een libary van mezelf gebruikt on-the-fly iframes om in de achtergrond bestanden te kunnen uploaden (ajax-file-upload).
Er is een methode zonder iframes, maar die werkt niet in oudere browsers.
De snelheid is het meeste gebaat bij een website die draait op een snelle server en waarbij keepalive aanstaat. Die zou een betere ranking moeten krijgen, sites met veel externe links naar plaatjes etc. zouden een lagere rank moeten krijgen.
Met een extra lage ranking voor trackers, webbugs etc.
Sommige pagina's hebben wel 30 trackers aan boord....
absolute tobscorer (met een b, want top is het niet) was er een met 62 trackers/ad brokers en enkele webbugs..

[Reactie gewijzigd door tweaknico op 7 augustus 2024 16:13]

Dit doet Google om websites beter te kunnen blijven analyseren met webcrawlers. Vele webpaginas bevatten in mindere mate gestructureerde content, gecodeerd in de pagina zelf. Dit omdat de pagina nu wordt opgebouwd bij de gebruiker en niet op de server. Google Angular is daarvan een uiting, single page application.
Kortom de webpage fysiek doorzoeken is veelal niet meer voldoende. Daarom laat Google ook al sommige web pagina's draaien in een viruele omgeving, alleen maar om te kunnen zien wat de pagina uiteindelijk doet (content). Maar dat is onbegonnen werk.
Dus zijn ze hard op weg om alternatieven te zoeken. Heel begrijpbaar, maar wat Google nu voostelt is eigenlijk het internet van 15 jaar terug. Nauwelijks javascript, geen CSS die content en opmaak manipuleerd, simpele interactie vormen. Maar nu onder het moto; het wordt er sneller door. Maar voor wie?

Op dit item kan niet meer gereageerd worden.