Google breidt amp-html uit met optie voor visuele artikelen

Google heeft een optie toegevoegd aan amp-html om artikelen te maken waar gebruikers op diverse visuele elementen kunnen klikken. De visuele artikelen zijn een aanvulling op de tekstartikelen die al mogelijk zijn met amp.

Google heeft samengewerkt met onder meer CNN en The Washington Post om bij deze aankondiging alvast wat visuele artikelen klaar te hebben staan. De zoekgigant noemt de functie een 'visual story', blijkt uit de tutorial. De opmaak van pagina's is opgemaakt in lagen. De eerste laag is de achtergrondafbeelding, waarna de tweede laag de titel is en de derde laag de tekst omvat.

Het is onbekend of Google amp-story's gaat uitlichten bij zoekresultaten, maar vermoedelijk gaat dat wel gebeuren. Huidige amp-pagina's krijgen een bliksemschicht naast de titel om duidelijk te maken dat het een amp-pagina is.

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.

De 'visual story' is ondanks het gebruik van veel interactieve en grafische elementen nog altijd zo licht mogelijk, om de pagina op die manier snel te kunnen tonen. Daarnaast kondigde Google dinsdag ondersteuning voor amp in Gmail aan, om op die manier webpagina's in mails te kunnen weergeven om bijvoorbeeld uitnodigingen voor evenementen te kunnen afhandelen zonder een browser te hoeven openen.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Lees meer

IT-banen

Reacties (44)

bartvb

13 februari 2018 15:48

Dat gebeurt door vooral html- en css-elementen toe te staan op pagina's, en het gebruik van javascript te beperken.

Dat gebeurt voor een belangrijk deel door pre-loading. De AMP pagina's staan allemaal op het google.com domein, als je naar het zoekresultatenscherm zit te kijken worden de assets voor de AMP pagina's al binnen gehaald. Dit in tegenstelling tot normale zoekresultaten waar je browser nog moet beginnen met uberhaupt het maken van een TCP connectie met de betreffende webserver.

Dit is ook meteen de belangrijkste reden dat ik (als publisher) ver van AMP (en b.v. Facebook Instant Articles) blijf. Alles staat op de servers van Google, als publisher lever je bijzonder veel controle in voor wat performance winst. Het gaat ook behoorlijk in tegen de basisopzet van het internet (een decentraal systeem van servers).

Met een goed geoptimaliseerde pagina is het verschil tussen AMP en een 'normale' pagina niet zo heel groot.

[Reactie gewijzigd door bartvb op 13 februari 2018 15:48]

Leknaas
@bartvb • 13 februari 2018 15:57

Nee. Je host zelf amp, op je eigen server. Daarvoor hebben ze nu ook de amp-toolbox uitgebracht, waarmee je je server kunt optimaliseren en daarbij de snelheid van google's cache kunt benaderen.

Google host dus niet jouw amp website, die host je zelf. Google laat wel een cache versie zien als je vanuit google search komt en daarom is het zo retesnel. Meer info hier: https://developers.google.com/amp/cache/overview

Net hebben ze hier (in de westergasfabriek) ook aangekondigd dat ze in de toekomst het gecachte amp domein er tussenuit kunnen halen. Dan zit die domeinnaam van de cache je in ieder geval ook niet meer dwars. https://twitter.com/trodrigues/status/963420805139968004

Edit: link naar tweet toegevoegd en link van amp-toolbox toegevoegd

[Reactie gewijzigd door Leknaas op 13 februari 2018 16:39]

bartvb

@Leknaas • 13 februari 2018 16:03

Klopt, de AMP pagina's staan op je eigen server. Alleen is de versie die de gebruiker ziet de versie die Google gecached heeft (en daardoor kan preloaden).
Bij een copy/paste van de URL komt er dus een www.google.com link te voorschijn en geen link naar je eigen domein. Dat vind ik bijzonder oncharmant en onhandig en gaat, zoals gezegd, in tegen hoe het internet zou moeten werken.

Klopt dat ze bezig zijn met het weglaten van de cache tussenlaag maar dat gaat nog een tijd duren doordat browsers nu (begrijpelijk) geen pre-caching doen van content op een ander domein.

De huidige staat is een URL als:
https://www.google.com/am...ysis-explainer/index.html

De plannen van Google om dat te verbeteren juich ik toe, AMP is echt een veel beter platform dan b.v. Instant Articles, maar de oplossing die ze voor ogen hebben laat (in de praktijk) nog een ruim jaar op zich wachten.

[Reactie gewijzigd door bartvb op 13 februari 2018 16:10]

Leknaas
@bartvb • 13 februari 2018 16:33

Het is op dit moment gewoon een technische belemmering die ze aan het oplossen zijn. Wat Google wel al doet:

de cached versie heeft als canonical jouw versie
als je de share buttons gebruikt, dan gebruiken ze ook jouw eigen url
in de titel staat van: jouw_domein

En inderdaad, als je de moeite gaat nemen om de originele url letterlijk te kopieren en weer te plakken (wat lastiger is dan gewoon een share-button te gebruiken), dan krijg je de cache-url (die overigens alle ranking etc doorspeelt naar jouw domein vanwege de canoncial). Maar dat vind ik echt niet opwegen tegen de winst in snelheid voor je gebruikers. En mocht een gebruiker verder navigeren, dan gaat hij/zij/het verder via jouw eigen domein en server. Alleen de eerste pagina vanuit search is de cached versie.

Ik zie AMP als een veel betere versie van de google cache die er al jaren is. Daar heb je nog nooit iemand over gehoord dat die cache bij google staat. In feite is AMP niet veel anders.

[Reactie gewijzigd door Leknaas op 13 februari 2018 16:46]

Sando

Google

@bartvb • 13 februari 2018 18:37

"AMP is echt een veel beter platform dan b.v. Instant Articles"

Kan je eens uitleggen wat AMP is? Ik zie klikacties. Embedded video. Animatie. Voor iemand die er vandaag voor het eerst van hoort/ziet lijkt dit, gelet op de features, een soort vervanger van Flash, waarvan HTML5 al de vervanger is.

Is AMP een subset van HTML5 die gecached wordt door Google? En daarmee een vendor-lock-in, net als Instant Articles, maar dan meer media-centric ipv text-centric?

Flash -> HTML5 -> AMP?

[Reactie gewijzigd door Sando op 13 februari 2018 18:38]

henkjobse
@Leknaas • 13 februari 2018 16:07

Meer informatie over het tonen van de "eigen" url ipv de google domein url: https://www.ampproject.or...oving-urls-for-amp-pages/

Knippr
@bartvb • 13 februari 2018 18:11

Ik ben blij dat je deze opmerking al gemaakt had, hoef ik hem niet te maken.

Google speelt vals. Het heeft controle over google.com (uiteraard) en laad daarbij stiekem de pagina al voor.
Als ik er nu voor kies om geen AMP te gebruiken en een super snelle pagina in elkaar zet, dan nog zal ik secondes trager zijn dan AMP.

Dat geeft al aan dat AMP niet snel is vanwege zijn beperkingen, het is snel omdat Google als enige het voordeel heeft te kunnen preloaden.

Utoka
13 februari 2018 16:10

Als je voor netneutraliteit bent zou je ver van AMP moeten blijven. Google verpakt het allemaal als iets wat de wereld gaat verbeteren maar voor de beeldvorming AMP websites van 60kb worden nu nog boven niet AMP websites geplaatst van 10KB. Niks neutraal en oneerlijk hoog plaatsen en uitlichten van zoekresultaten die een google techniek ondersteunen. Dit zou hetzelfde zijn als websites met google adwords hoger plaatsen dan websites met een andere banner supplier. Of websites met angular hoger plaatsen dan websites met React.

Het is zeker geen open standaard. HTML(5) is een open standaard. Alles wat google AMP kan veel beter met gewoon puur HTML. Het initiatief is misschien uit een goed idee ontstaan om de wildgroei aan javascript zware websites tegen te gaan maar het is best ironisch dat je nu een javascript moet inladen om de AMP te kunnen gebruiken terwijl er al een hele goede standaard bestaat die elke browsers begrijpt (HTML)

Leknaas
@Utoka • 13 februari 2018 17:36

Het is niet alleen Google. Bing, yahoo, pinterest, baidu en linkedin ondersteunen AMP ook. Natuurlijk is er veel op aan te merken, maar je hebt nu eenmaal een standaard nodig die een pagina 1-op-1 kan cachen in de cache van het platform die AMP ondersteund. Met html en css alleen kun je ook allerlei rare websites krijgen die voor geen meter laden.

De vergelijking met 10kb en 60kb is te beperkt IMHO. Andere factoren spelen waarschijnlijk een veel grotere rol dan het aantal kb's dat een site groot is. Het Google Search team heeft meerdere malen aangegeven dat AMP geen ranking factor is. En pas recent hebben ze gepubliceerd dat laadsnelheid op mobiel wordt meegenomen. Wat me overigens verbaasde, ik dacht dat dat in het algemeen al werd meegenomen.

En voor bijvoorbeeld articles in search kun je zonder AMP ook gewoon in terecht komen. Wel moet je dan gebruik maken van structured data, wat ook weer een zoveelste standaard is dat ook door vrijwel alle tech bedrijven wordt ondersteund. Je kunt nu eenmaal niet zonder standaarden.

AJediIAm
@Utoka • 13 februari 2018 19:35

Dit niet waar netneutraliteit om draait. Netneutraliteit gaat over het gebruik van een dienst als consument of bedrijf met de garantie dat ik niet extra hoef te betalen uit angst dat de dienst afgeknepen wordt door een service provider van een klant.
Amp vergelijkbaar met Flash, Java, Silverlight, YouTube of Amazon hosting. Het is een dienst die je kan gebruiken of niet. Natuurlijk zijn er concurrenten van elk van deze voorbeelden die open source en/of self hosted zijn, maar een heel groot deel van de websites in de wereld maakt gebruik van externe diensten van commerciële partijen en daar is niets mis mee. Sterker nog, deze partijen zijn de grote vechters voor netneutraliteit.

MoietyMe
13 februari 2018 16:42

Maak mij ernstig zorgen om AMP, en met mij nog een hele hoop andere: AMP letter.

We are a community of individuals who have a significant interest in the development and health of the World Wide Web (“the Web”), and we are deeply concerned about Accelerated Mobile Pages (“AMP”), a Google project that purportedly seeks to improve the user experience of the Web.

In fact, AMP keeps users within Google’s domain and diverts traffic away from other websites for the benefit of Google. At a scale of billions of users, this has the effect of further reinforcing Google’s dominance of the Web.

[Reactie gewijzigd door MoietyMe op 13 februari 2018 16:42]

WhatsappHack

Internet
Google

13 februari 2018 15:53

Is er al een manier om AMP uit te zetten? Het is de meest irritante en vertragende functie die er is.

YopY
@WhatsappHack • 13 februari 2018 16:07

Ik geloof dat je niet helemaal snapt wat AMP is / doet. Kun je uitleggen hoe het vertragend is? Of bedoel je dat je nog een extra stap moet doen om op de "echte" site (met alle meuk + ads + extra trackers) te komen?

WhatsappHack

Internet
Google

@YopY • 13 februari 2018 16:31

Ik weet wat het is en doet, maar vind het over het algemeen strontvervelend. Het enige doel dat het ironisch af en toe heeft, is juist om alsnog een artikel te kunnen lezen van een site die anti-adblocking heeft.

Die ads en trackers blokkeer ik zelf al en heb ik AMP van Google niet voor nodig. (Wel slim trouwens, want zo kan zonder anti-tracking Google je wel gewoon tracken, maar andere trackers niet. Slim bedacht van ze om meer data te vergaren dan de rest.

)

Als ik een site wil openen, dan wil ik die site openen en niet in een sterk uitgeklede versie van die site komen om een heel scala aan redenen. Google duwt AMP door je strot (sure, met medewerking van de sites; maar gezien AMP resultaten een voordeel hebben is het logisch dat die eraan meedoen voor SEO-purposes) en dan moet je inderdaad extra acties ondernemen die op het normaal perfectionistische Google toevallig niet altijd direct werken. Zo hebben ze een tijdlang, al hebben ze dat eindelijk toch maar eruitgesloopt geloof ik, de boel zo gebouwd dat de eerste keer dat je op de link klikt om toch naar de originele site te gaan er helemaal niets gebeurt waardoor je nogmaals die dropdown moet openen en op de link moet klikken - de 2e keer werkte het magischerwijs altijd. Daarnaast valt het AMP balkje vaak omhoog weg na scrollen waardoor het lastiger wordt om op die link knop te drukken.

Ik wil meestal gewoon direct naar de site, al is het omdat ik de comments gewoon direct wil lezen aan t eind of gebruik wil maken van bepaalde handige features die op de site zelf aanwezig zijn maar niet in AMP - nog niet te spreken over t feit dat afbeeldingen soms weg lijken te vallen of misplaatst worden. Ik heb zowel thuis (500MBit) als op 4G (verschillend van 20 tot ~190MBit) razendsnel internet waar ik t verschil met AMP niet tot nauwelijks merk en verwaarloosbaar is; zeker niet als ik de site al eens bezocht heb en het merendeel van de assets gecached is; en de ads + trackers worden reeds geblokkeerd dus boeien me niet.

AMP is niet altijd vervelend en heeft zo z’n usecases, maar ik ervaar het vaker als zeer irritant en belemmerend voor wat ik wil doen waardoor de sporadische voordelen niet opwegen tegen de nadelen (naar mijn mening, uiteraard kan het zijn dat jij en anderen AMP wél prettig vinden) en ik het dus gewoon in t algemeen niet voorgeschoteld wil krijgen.

[Reactie gewijzigd door WhatsappHack op 13 februari 2018 16:37]

Mellow Jack
@WhatsappHack • 13 februari 2018 17:31

Lijkt mij dat vrijwel elke grote serieuze sites gebruik maken van caches. Voor zover ik weet zit bijv microsoft.com achter de akamai diensten en die doen niets anders dan cachen

WhatsappHack

Internet
Google

@Mellow Jack • 13 februari 2018 17:38

Ik bedoel lokaal gecached op het toestel

Anonymoussaurus

Google

@WhatsappHack • 13 februari 2018 15:56

https://www.makeuseof.com...le-search-android-iphone/

Vertragende functie? Hier werkt het juist retesnel..

[Reactie gewijzigd door Anonymoussaurus op 13 februari 2018 15:56]

WhatsappHack

Internet
Google

@Anonymoussaurus • 13 februari 2018 16:38

Leuke work-arounds, maar ik zie liever dat Google de belofte nakomt om het in de opties uit te zetten zodat je niet door hoepeltjes hoeft te springen om het uit te schakelen.

Anonymoussaurus

Google

@WhatsappHack • 13 februari 2018 16:39

Dat is wat anders inderdaad

. Die optie is er nog niet, behalve met (vage) work-arounds inderdaad. Volgens mij werkt het wel als je /amp weghaalt in de URL. Althans: zo doe ik het altijd.

calvinturbo

@WhatsappHack • 13 februari 2018 15:56

AMP vertragend? Surf jij nog op 2G met een Nokia 3310?

WhatsappHack

Internet
Google

@calvinturbo • 13 februari 2018 16:39

Juist het tegenovergestelde, op 2G zou AMP wellicht wél vaker een voordeel kunnen geven.

henkjobse
13 februari 2018 15:42

In dat zelfde kader ook Google AMP voor e-mail binnenkort beschikbaar: https://www.blog.google/p...bringing-power-amp-gmail/

calvinturbo

@henkjobse • 13 februari 2018 15:44

Dat is best wel netjes! Goed bezig Google.
Zo te zien een open standaard

Stoelpoot
@calvinturbo • 13 februari 2018 16:03

Hmm... Email is daar juist niet voor bedoeld. Ik zie alleen maar privacy- en veiligheidsrisico's.

calvinturbo

@Stoelpoot • 13 februari 2018 16:14

Privacyrisico's? Elke grote e-mailtool, denk aan Mailchimp en Sendgrid, houden al bij wie de mail heeft geopend en gelezen, hoe laat en op welk apparaat.

isama
@calvinturbo • 13 februari 2018 17:00

zolang je de tracking pixels laadt, of je op de trackinglinks klikt ja.

Zed_no1
@calvinturbo • 13 februari 2018 15:54

Hoe bedoel je openstandaard? Als Google morgen in een nieuw opruim rondje besluit dat AMP niet oplevert wat ze verwacht hadden dan is het meteen afgelopen met AMP.

YopY
@Zed_no1 • 13 februari 2018 16:03

AMP hosted op Google.com wel, maar de open source standaard blijft gewoon bestaan: https://github.com/ampproject/amphtml

joelharkes
13 februari 2018 15:48

Het idee van AMP is toch dat je java-script vervangt door een aantal bruikbare HTML tags en wel je css behouden blijft. En hierdoor pagina super snel kunnen laden?

Wat ze in het fimpje laten zijn lijkt bijna een soort van Flash reborn dit is toch niet waar ze met AMP heen willen lijkt me?

pookie79
@joelharkes • 13 februari 2018 15:52

css animatie kan een hele hoop.

pim
13 februari 2018 18:23

Ik zie amp meer als gedoe, dan dat het me helpt.

The Accelerated Mobile Pages (AMP) Project is an open source initiative that makes it easy for publishers to create mobile-friendly content once and have it load instantly everywhere.

AMP helpt me mobiele vriendelijke content te maken? Het is juist lastig, omdat ik het werk nu dubbel moet doen.
Ik heb al een website, die responsive is, en minder dan 100kb is. Die moet ik nu overnieuw gaan maken door AMP te leren?

Met html&css is het ook mogelijk "mobile-friendly content" te maken, die instant overal laadt. Hoezo is dat een voordeel van AMP?

[Reactie gewijzigd door pim op 13 februari 2018 18:26]

Gapert86
@pim • 13 februari 2018 19:57

Het voordeel van AMP is dus dat het voorgeladen wordt, en jouw eigen website niet. Maar ik ben het geheel met je eens. Mijn websites zijn allemaal responsive en zoveel als mogelijk geoptimaliseerd, en ik zoek het totaal niet om overal ook nog eens een losse AMP versie van te gaan maken zodat de gebruiker, die over het algemeen tegenwoordig op 4G en 50mbit+ wifi zit, de website 0,1 seconde eerder ziet.

Mavamaarten

13 februari 2018 15:44

Geef mij maar gewoon wat minder oppervlakkige journalistiek dan wat mooie prentjes met een mini tekstje bij.

pookie79
13 februari 2018 15:48

Vreselijk dat alles maar moet bewegen met minimaal aan info als het er maar hip oogt. Ik denk wel dat het een succes wordt maar voor mij is het niets.

_Thanatos_
13 februari 2018 15:51

Leuk dat AMP, en dat het schijnbaar snel is, maar het is gewoon weer een javascript MVC-framework erbij. Niets bijzonders. Sterker nog, dat heeft Google al, in de vorm van Angular. Waarom dat niet wat slanker maken? Dat heeft Angular dramatisch hard nodig nml.

Het snelste is nog altijd om gewoon kale html+css te laden. Er is niets sneller dan dat. Het is ook niet voor niets dat dat de "way to go" is voor pagina's die op kleine langzame devices met een trage verbinding bruikbaar moeten zijn. Bijv op featurephones in derdewereldlanden. Ieder denkbaar javascript framework is veel te zwaar. Als zo'n telefoon al javascript heeft... (wrs heel beperkt, met Opera Mini)

Voor andere situaties waarin snelheid gewenst is, geldt natuurlijk ook dat je niet eerst een heel framework wil binnenhalen. Want hoe klein dat framework ook is, het komt hoe dan ook vóór het laden van je eigenlijke content. Terwijl je juist je content het liefst als allereerste inlaadt.

En nou kun je wel zeggen "ja maar als het eenmaal ingeladen is, is het supersnel". Ja leuk. Maar daarvoor moet het wel een maal ingeladen worden. En als dat te lang duurt, maakt de bezoeker rechtsomkeert.

[Reactie gewijzigd door _Thanatos_ op 13 februari 2018 15:52]

YopY
@_Thanatos_ • 13 februari 2018 16:06

Het is geen JS MVC framework, dan heb je het gewoon niet begrepen. Het is een subset van HTML geoptimaliseerd op performance: zie https://www.ampproject.org/docs/reference/spec

Het is sneller dan gewoon kale html + css. Het idee is dat je die subset van html / css die ondersteund worden door AMP gehost worden door een AMP server, die op zijn beurt nog meer optimalisaties kan toevoegen, o.a. inlining, above-the-fold optimalisatie, image resizing en preloading.

Maar ok, toegegeven; je hebt geen AMP nodig om een snelle site te maken, en de meeste content publishers zouden al enorm geholpen zijn als ze hun websites sneller konden maken door eenvoud.

willem_liu
@YopY • 13 februari 2018 16:17

_Thanatos_ heeft geen ongelijk door te zeggen dat het een js framework is. Je hebt Amp js library nodig om je custom html tags te laten werken.
Deze moet daarom eerst geladen en geparsed zijn voordat je content daadwerkelijk gerendered wordt.
Je stelling dat het sneller is dan kale html en css is dus niet correct.

_Thanatos_
@willem_liu • 14 februari 2018 09:30

Precies dat ja. Wat het ook is, hoe je het ook wendt of keert, je moet *iets* downloaden voordat je de pagina kunt zien zoals bedoeld. En met pure html hoeft dat niet.

Knippr
@_Thanatos_ • 13 februari 2018 18:14

"Het snelste is nog altijd om gewoon kale html+css te laden. Er is niets sneller dan dat."

Ik zou willen dat dat waar is, maar het is het niet. Google laad stiekem al de AMP pagina's voor, nog voordat je ze aanklikt. Bij jouw snelle pagina die geen AMP is, gebeurd dat niet. Hierdoor is AMP altijd sneller.

willem_liu
@Knippr • 13 februari 2018 18:45

Dat is enkel op dieper liggende urls als je al op de website bent. Als je initieel naar de website navigeert geldt dat dus niet tenzij je via Google search results doorklikt naar de website.
Maar je punt is wel valide.

_Thanatos_
@willem_liu • 14 februari 2018 09:32

tenzij je via Google search results

Dat lijkt me sterk. Website A kan geen resources voorladen voor website B.
En bovendien wordt er dan nog steeds iets voorgeladen. Het *lijkt* dan alleen sneller.

willem_liu
@_Thanatos_ • 14 februari 2018 10:11

Het kan omdat een amp page via Google.com wordt uitgeserveerd als je gebruik maakt van de amp cache. Dat is ook de reden dat er zoveel geklaagd wordt over de URL omdat er altijd Google.com voor staat.
Je kan het wel zelf cachen, maar dan krijg je de voordelen van instant loading niet via de Google search results.

_Thanatos_
@willem_liu • 16 februari 2018 02:00

Dat is juist nog een spijker in de kist.

Je website via google laten hosten (cachen, maar close enough). Leuk als je Google gebruikt, maar zinloos als je via een andere weg op de site komt. En zeer onprofessioneel. Je kunt net zo goed terug naar geocities of tripod als we zo websites moeten gaan bouwen.

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

Google breidt amp-html uit met optie voor visuele artikelen

Lees meer

IT-banen

Reacties (44)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden