Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 64 reacties

Google heeft amp html gepresenteerd, 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 worden weergegeven.

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

Moderatie-faq Wijzig weergave

Reacties (64)

Googles antwoord op adblockers, integreer de Ads in een nieuw formaat zodat ze uit het zelfde domein gehost kunnen worden:

uit de FAQ:

How will advertising work on Accelerated Mobile Pages?
A goal of the Accelerated Mobile Pages Project is to ensure effective ad monetization on the mobile web while embracing a user-centric approach. With that context, the objective is to provide support for a comprehensive range of ad formats, ad networks and technologies in Accelerated Mobile Pages. As part of that, those involved with the project are also engaged in crafting Sustainable Ad Practices to insure that ads in AMP files are fast, safe, compelling and effective for users.


https://www.ampproject.org/faq/#accelerated-mobile-pages-12

Tracking wordt dus ook zonder javascript opgelost maar met tracking pixels, er zal wel een backhaul aangeboden worden naar Google. Dwz. de tracking gaat via de servers en niet meer via de client servers.

Open standaard natuurlijk, want Google is gebaat bij openheid :*)

Erg benieuwd ook naar de gratis server software die Google hiervoor gaat aanbieden (websites naar de Google cloud wellicht?). Hoe je het ook wendt of keert Google wil ads leveren en gebruikersdata verzamelen, daar is een ingang voor nodig bij Content aanbieders. Nu niet langer via javascriptjes in de client maar via de achterkant: de (gratis) server software met een Google Ads/Google Analytics backhaul socket of volledige encapsulatie van content aanbieders web sites in de Google Cloud.

Dit is huge, de implicaties reiken zeer ver.

Hier staat de crux gewoon, wat ik hierboven "tracking via de server" noem :
Distribution: Publishers want people to enjoy the great journalism they create anywhere and everywhere, so stories or content produced in Spain can be served in an instant across the globe in, say, Chile. That means distribution across all kinds of devices and platforms is crucial. So, as part of this effort, we’ve designed a new approach to caching that allows the publisher to continue to host their content while allowing for efficient distribution through Google's high performance global cache. We intend to open our cache servers to be used by anyone free of charge.
Keyword is "gratis" hier, dan moet je altijd opletten bij Google. Alle AMP content via de Cache van Google. Effectief weet Google dus zometeen precies welke URLS je leest. Indexje op de cache en marketinginfo kan verzameld worden.
bron: https://googleblog.blogsp...lerated-mobile-pages.html

[Reactie gewijzigd door alfredjodocus op 7 oktober 2015 22:12]

Ads worden in grote lijnen op dezelfde manier geladen als nu maar met een paar beperkingen. De banners moeten nu in een iframe sandbox (zoiets als de IAB safeframes), worden als laatste geladen, mogen/kunnen de grootte van het iframe niet aanpassen.

Ze komen dus zeker niet van hetzelfde domein als de content! Dat is ook vrijwel onmogelijk en zou enorme security implicaties hebben. Wat adblockers betreft; die krijgen het vooral makkelijker. Deze hoeven alleen maar de <amp-ad> tags uit een pagina te filteren:

https://github.com/amppro...ter/examples/ads.amp.html

Tracking/analytics gaat inderdaad via een pixel ipv een JS library. Als je een pixel van b.v. Google Analytics gebruikt dan gaat die data idd naar Google. Maar je kan er ook voor kiezen b.v. Piwiki, Chatbeat of iets ander te gebruiken.

Verder is er voor AMP geen speciale server nodig, Google biedt wel een CDN/proxy aan voor AMP pagina's, maar je kan gewoon je eigen Apache/Nginx/etc server je AMP pagina's laten serveren. AMP is niet veel meer dan een HTML5 pagina met wat specifieke tags:

https://github.com/amppro...aster/docs/create_page.md

[Reactie gewijzigd door bartvb op 7 oktober 2015 18:03]

Tracking/analytics gaat inderdaad via een pixel ipv een JS library. Als je een pixel van b.v. Google Analytics gebruikt dan gaat die data idd naar Google. Maar je kan er ook voor kiezen b.v. Piwiki, Chatbeat of iets ander te gebruiken.
Als bezoeker van een website heb ik geen keuze om wel of niet gevolgd te worden, dit kan niet met een adblocker gestopt worden, alleen als je zelf een server opzet die de boel eruit filtert, maar dan heb je de page al opgehaald.
Je zou het domein waar die pixel vandaan wordt geserveerd volledig kunnen blokkeren (via je hostfile).
Of met Request Policy. Daarmee kun je ervoor zorgen dat een pagina niet meer content van een ander domein kan laden (werkt uiteraard met witte en zwarte lijsten, omdat het voor sommige websites noodzakelijk is om wel van een bepaald ander domein iets in te laden).
https://addons.mozilla.or.../requestpolicy-continued/
Ja maar dan moet je mogelijk veel instellen omdat veel websites zaken als jQuery vanaf allerhande CDNs toevoegen, die moeten allemgaal gewhitelist zijn (net als Analytics etc). Mogelijk overigens dat dat er al deels inzit, dat weet ik niet.
Je moet inderdaad wel voor veel websites dingen whitelisten. Maar je kunt er ook voor kiezen om in één keer alle Jquery-domeinen te whitelisten voor alle andere domeinen, zodat dus elk domein vanaf Jquery dingen kan inladen. Je kunt allerlei flexibele regels instellen. Analytics heb ik juist geblacklist, geen problemen mee.

[Reactie gewijzigd door Cerberus_tm op 9 oktober 2015 19:42]

Zijn er wel standaard lijsten voor dat soort dingen of moet je dat allemaal zelf doen? Kan me namelijk voorstellen dat je naast jQuery zelf ook talloze jQuery modules van allerhande CDNs moet whitelisten, en dan wordt het al snel veel meer werk dan een klein aantal tracking domains te blacklisten.
Het is wel even wat werk ja. Er is een standaardlijst ingebouwd voor een handjevol van de grootste sites, zoals Google en Facebook. De rest zul je zelf moeten doen. Dat gaat gelukkig wel snel, klik-klik als je op een site bent. En als je ook veel advertentie-domeinen blacklist wordt het overzichtelijker welke sites je eventueel zou moeten toestaan om een site goed werkend te krijgen (die domeinen dus niet dan). Meestal werken sites wel, maar ziet de layout er raar uit omdat het CSS-bestand van elders gehaald wordt (waarom doen ze dat eigenlijk?). In elk geval geeft het extreem veel voldoening! Je haalt alleen binnen wat je nodig hebt.
Dat doen ze mogelijk omdat die lokaal wordt gegenereerd en dan (minified) op een CDN gezet wordt zodat hij bij de eindgebruiker zo snel mogelijk binnen is. Je ziet heel veel sites die 'statische' content van andere plekken afhalen, daarom is het volgens mij ook meer werk per sites allerhande domeinen te whitelisten dan andersom (want content komt rustig van dj2dji2jd32d3.cdn.domein.com en morgen vanaf 123781932.cdn.domein.com, om te zorgen dat na een aanpassing jij zeker niet een gecachede versie gebruikt).

Best case is natuurlijk blokkade voor ad domains, greenlisted van trusted en greylisting van onbekend, maar dan wordt je met een uurtje browsen helemaal gek denk ik van alle "do you allow to load X from resource Y"
In de praktijk werkt het helemaal prima, hoor. Als sites al wisselen van CDN gebeurt dat niet vaak in mijn ervaring, heb het zelfs nog nooit gemerkt. En dan nog zal dat een kwestie van klik-klik zijn. Bij sites die ik wel eens eerder heb bezocht hoef ik eigenlijk nooit iets te doen. En als je Cloudfront en Wordpress whitelist als inlaad-doel voor alle domeinen heb je het grootste deel van CDN's al gehad die ik zie in de praktijk.

Sowieso vraag ik me af, als het sneller is om de CSS op een CDN te zetten, waarom ze dan niet de hele site op dat CDN zetten?

Request Policy werkt niet met prompts: hij laadt gewoon wat hij kan laden, en je kunt dan dingen aan- of uitzetten in het menu, wat snel werkt. Net zoals Noscript, eigenlijk, of als een Adblocker. De hele tijd prompts voor je neus krijgen lijkt gebruiksvriendelijk maar is eigenlijk gewoon irritant en kost elke keer tijd. Ik ben eigenlijk over all heel tevreden met RP.

Het menu van RP als je op tweakers.net bent, waarbij ik Google Analytics heb geselecteerd, een van de mogelijke "destinations" waarvan Tweakers inhoud wil laden:
http://i.imgur.com/yrUQj6V.png

NRC.nl:
http://i.imgur.com/n621KIG.png

Gmail:
http://i.imgur.com/ksoieQE.png

[Reactie gewijzigd door Cerberus_tm op 13 oktober 2015 20:39]

".. Sowieso vraag ik me af, als het sneller is om de CSS op een CDN te zetten, waarom ze dan niet de hele site op dat CDN zetten?.."

Versimpelt: Omdat een deel van de website gegenereerd wordt speciaal voor jou op basis van wat je aanklikt. De Tweakers frontpage wisselt de hele dag (door nieuw nieuws/reacties/etc). Afbeeldingen en Stylesheets wisselen (als ze er eenmaal staan) vrijwel niet (afbeeldingen) of maar af en toe (stylesheets).

(los even dat er talloze trucs en mogelijkheden zijn om daarmee om te gaan).

Edit: Oh en dank voor de screenshots, nu heb ik een beter idee hoe het eruit ziet.

[Reactie gewijzigd door DonLexos op 14 oktober 2015 12:59]

Ik dacht juist dat een CDN meestal bedoeld was om sneller te zijn (dichter bij), maar okee, andersom dan: waarom niet alles op één en dezelfde server zetten, opdat alles snel zal zijn?
CDN = Content Delivery Network. Het is dus niet 1 systeem maar een netwerk van servers waarbij het idee is dat je altijd vnaf de dichtsbijzijnde de informatie ophaalt. Reden dat je dat vooral voor statische zaken kan gebruiken is dat die niet de hele dag door veranderen. De frontpage van Tweakers is de hele dag anders, dan ben je permanent bezig met het synchroniseren van al die servers in dat netwerk. Voor dat soort zaken zijn weer andere methodes.
Oftwel een proxyserver gebruiken.
Bij Google kan je opt-out'en, al is dat natuurlijk niet de enige tracker.
Ofwel: het verhaal van een 'sneller en lichter' mobile web is een dekmantel voor een gevecht tegen de adblocker. Tja, wat moest je anders verwachten van het grootste reclamebureau ter wereld. :D
Wat is nou het nut van een pagina puur conform `amp` te schrijven? Natuurlijk is het sneller om geen grote javascript libraries in te laden, etc. etc., maar zover ik weet kan ik dat ook gewoon doen zonder dat daar een spec voor moet bestaan :+ . Of gaat Google `amp` pagina's hoger ranken of anderzijds speciaal behandelen?

En fijne aanpak wat betreft advertenties, één van de irritantste dingen aan advertenties is inderdaad dat ze het web soms significant vertragen, maar anderzijds begrijp ik ook natuurlijk dat ze gewoon nodig zijn om content gratis aan te kunnen bieden op grote schaal. Als je advertenties gewoon laad na de normale content heb je dus het beste van twee werelden.

---

Je kunt niet op jezelf reageren, dus ik ga m'n eigen vraag maar hier beantwoorden, na nog wat langer en beter te hebben gelezen lijkt het erop dat het inderdaad aan de technische kant niks toevoegd, wat het alleen wel doet is er voor zorgen dat er een duidelijk doel en benchmark bestaat voor publishers waar ze aan kunnen voldoen. Dit maakt het vanaf Google's kant veel makkelijker om content providers te overtuigen om sneller paginas te maken en zorgt er voor dat content providers minder geneigd zijn om hun nieuws via Facebook's content platform te verspreiden. Ter illustratie, dit is Facebook's eerste argument om content providers te overtuigen hun platform te gebruiken:
Leveraging the same technology used to display photos and videos quickly in the Facebook app, articles load instantly, as much as 10 times faster than the standard mobile web.
En dat laatste is denk (!) ik ook de hele reden voor het bestaan van dit project: Ad inkomsten via Facebook's content network gaan via Facebook ipv. Google1, en dat is natuurlijk niet ideaal voor Google. Als Google dus content providers duidelijk maakt dat pagina's wel degelijk snel kunnen laden op het mobiele web dan is dat een dubbele win voor content providers en Google: de tijd die de content provider besteed aan het content verspreiden via Facebook's technologie is nu besteed aan een amp versie maken met een veel breder publiek dan alleen Facebook gebruikers (bijv. IM berichtjes laden ook gewoon de `amp` versie) en Google houdt het open web ermee in leven waarvan ze afhankelijk zijn (een web waar onder anderen iedereen z'n eigen ad provider kan kiezen)2. En ja, het kan evil klinken dat Google meer ad-inkomsten wil, maar uiteindelijk heeft iedereen er baat bij als het open web wint i.p.v. gesloten tuinen zoals die van Facebook.

1 Er is niet al te veel informatie publiek beschikbaar over Facebook Instant Articles, dus ik zou me op dit vlak kunnen vergissen. Alles wat op de site staat is "Sell ads in your articles and keep the revenue.".
2 Al moet ik ook daar bij zeggen dat Facebook Instant Articles ook gebruik maakt van HTML, maar gezien ze niet een volle `webview` lijken te laden vermoed ik dat ze hun eigen minimale renderer hebben geschreven.

[Reactie gewijzigd door David Mulder op 8 oktober 2015 09:22]

Madness. Dit kan dus allemaal prima met HTML. Dit is een kreupele versie van HTML, om te dwingen dingen sneller te maken. Maar waarom zou je? Ik bedoel, waarom zou je de kreupele versie gebruiken? Ofwel de snelheid interesseert je wel, en in dat geval heb je je HTML al zo geoptimaliseerd om goed en snel op mobiele browsers te werken, met inachtneming van enkele principes die door AMP worden opgelegd, ofwel het interesseert je niet, en dan ga je sowieso geen AMP gebruiken.

Het heeft dus geen meerwaarde want het heeft niet meer functies maar juist minder. Wat het daardoor wel meer heeft is drie extra letters en een extra spatie in de HTML (" amp" in de html tag), dus de pagina wordt er zelfs iets groter en dus trager van. :9

Overigens zijn ze soms wel erg op de bytes aan het hameren; Google PageSpeed Insights geeft bij een van mijn websites aan dat ik een whopping 821 bytes kan besparen door JS te minifyen. Nu is de JS al geminified, maar vinden zij blijkbaar dat het nog net iets beter kan, en dat kost je dan minpunten. Nou, die 821 bytes ga je dus echt niet merken. De reductie van 400 KiB door de minifier tov de oorspronkelijke versie wel natuurlijk.

En dan maar ads naar de mobiele devices pompen, die nemen wel meer dan 821 bytes in beslag 8)7

[Reactie gewijzigd door MadEgg op 7 oktober 2015 21:33]

Persoonlijk vind ik het een onnodig en zelfs te beperkend project. Via XHR + History Api + DOM kan ik wanneer er op een link geklikt word een deel van de site (waar de content komt, dus niet de footer, header, sidebar) updaten met nieuwe content. Dit maakt het laden veel sneller en belast het netwerk veel minder. In combinatie met de service-worker kan ik de gehele ofline beschikbaar maken. Niet de gehele css, js, etc hoeft telkens geladen te worden.
Met IndexedDB kan ik artikelen en de lijst van artikelen op de homepage offline opslaan waardoor deze ook niet telkens opnieuw geladen te worden.

Wat er echt moet gebeuren, is dat alle content optimized word (javascript, html, css minifyen, afbeelding optimizen+grootte resizen naar wat nodig is), bij afbeeldingen srcset gebruiken zodat ik geen onnodig grote afbeelding krijg, niet voor een functie heel jquery laden, niet 10 librarys gebruiken, geen honderd trackers en advertenties moeten kleiner qua bestandsgrootte!
Op zich eens, maar om dat allemaal te moeten doen zal je eerst een aardig framework binnen moeten halen bij de eerste pageview. Daarna is het browsen inderdaad behoorlijk snel.

In dit project gaat het echter voor een heel groot deel om die eerste pageview. Je ziet een linkje op Twitter, wil dat BBC artikel lezen en dan wil je niet eerst een complete HTML5 app van de BBC downloaden via je wat haperende mobiele verbinding voor je een artikel van 500 woorden kan bekijken.

Maar helemaal eens met je punt dat je zeker geen AMP nodig hebt om een pagina/site te bouwen die snel op je mobiel staat.
Advertenties in iframes? Neuh...
| iframe | Banned. May be replaced with amp-iframe in the future. |

edit: voor de duidelijkheid - dat laatste regeltje komt uit /amp/spec/amp-html-format.md. Volgens de specs zijn iframes dus niet mogelijk (wat trouwens weer in tegenspraak is met het artikel).

[Reactie gewijzigd door Zaph op 7 oktober 2015 17:59]

Je kan binnen AMP niet direct gebruik maken van iframes, maar als je een banner opneemt (via de <amp-ad> tag) dan wordt die banner geladen in een iframe sandbox. AMP gebruikt dus iframes voor advertenties (wat ook in het artikel staat) maar je kan als content author geen iframes gebruiken.
als je wel gebruik wilt blijven maken van goedkoop beschikbare nuttige content is de kans best groot dat je ook een zeer direkt voordeel hebt van acceptatie van advertentievormen die snel laden en non-obtrusive zijn..

een kat-en-muis spel tussen adverteerders en gebruikers zal voornamelijk verliezers kennen..
voor jou als eindgebruiker kan het dan ertoe leiden dat de adverteerders zich gedwongen voelen advertentieoplossingen te gebruiken die heel ondoorgrondelijk zijn en hierdoor ook meer laadtijd vergen; maar dus niet zo makkelijk 'algemeen' geblokkeerd kunnen worden.

Gebruikers kunnen er veel voordeel van hebben als er standaard toepassingen voor advertentie's zijn, juist omdat deze zelf dan ook de regels moeten volgen en ook beter herkenbaar kunnen zijn. Worden zulke ontwikkelingen gewoon puur geblokeerd omdat gebruikers tegen reclame zijn (maar anderszijds wel willen dat alle content op het internet gratis en breed beschikbaar moet zijn) snij je dels gewoon jezelf in de vingers, en 'steun' je juist die advertentieaanbieders die liever met stiekeme trucjes werken en het liefst hun adverenties zo intrusief laten functioneren met alle mogelijke technische trucjes

[Reactie gewijzigd door RM-rf op 7 oktober 2015 17:24]

een kat-en-muis spel tussen adverteerders en gebruikers zal voornamelijk verliezers kennen..
voor jou als eindgebruiker kan het dan ertoe leiden dat de adverteerders zich gedwongen voelen advertentieoplossingen te gebruiken die heel ondoorgrondelijk zijn en hierdoor ook meer laadtijd vergen; maar dus niet zo makkelijk 'algemeen' geblokkeerd kunnen worden.
Alles blokkeren wat niet van hetzelfde hoofddomein afkomstig is, m.u.v. een geselecteerde white-list aan goedgekeurde CDNs en je bent al voor 90% gedekt zonder dat adverteerders er ook maar iets tegen kunnen beginnen.

Dus dat het dan 'nog langzamer' gaat worden is een fabeltje.
kat en muis spel van advertenties en blocker begint meestal bij de adverteerder zelf die MEER wil altijd maar MEER zichtbaarheid, zo erg zelf dat hetgeen je wil zien verdrongen raakt.
en dan is verwonderd dat meer mensen adblockers gaan gebruiken.

moesten ze zichzelf aan de accepable add richtlijnen gehouden hebben (al bestonden die vroeger niet) dan zouden er veel minder adblockers gebruikt worden.
Sommige sites zijn op een mobiel idd alleen fatsoenlijk leesbaar in lees-modus waarbij alle reclame meuk wordt weggelaten en alleen de inhoud wordt getoond.
Zie mijn edit - volgens de specs die op Github staan zijn iframes niet toegestaan in AMP. Beetje vaag verhaal, dus.
En wordt vervolgens weer factor 3 trager door alle onzin reclames, takeovers en popups.

Ja, daar zijn adblockers voor, maar dat is een pleister voor het probleem. Sinds ik flash standaard heb uitstaan, is alles al stuk sneller, maar doe je nog weinig aan die 100% CPU slurpende sites die nog eerder vastlopen dan daadwerkelijk inladen.
uit het artikel:
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.
dat betekend dus niet meer wachten tot advertenties zijn ingeladen voor je de inhoudt kan zien (helemaal irritant als je time-outs krijgt op advertenties) en flash heb je bij mobile doorgaans ook geen last van omdat dat niet word ondersteund.

[Reactie gewijzigd door Countess op 7 oktober 2015 17:08]

flash? Wat is dat?

Serieus mensen, gooi die zooi er eens af, je merkt wel dat een video player links en rechts er net iets anders uitziet maar de meeste sites (hier toch) werken gewoon helemaal goed zonder die rommel. Tegenwoordig is html5-video best goed ondesteund.

Het jammere vind ik dan wel dat ik zowat overal meldingen krijg dat ik een flash-player nodig heb ... om vervolgens netjes de html-5 variant in te laden.

Ook bij youtube, hadden die html5 niet als standaard met flash als fallback?? Hier lijkt het alvast andersom.
Welke browser gebruik je? YouTube zou standaard HTML5 moeten gebruiken als je browser daar ondersteuning voor heeft. Check ook https://www.youtube.com/html5
Of ze nu vooraf of achteraf worden geladen, ze worden geladen en gooien een aanslag op je CPU. En als adverteerder ben je natuurlijk ook niet blij dat dit pas achteraf wordt geladen of in een iframe (welke je simpel kan uitzetten) en ik denk dat Google hier en daar zijn eigen advertenties wel wat prioriteit meegeven.

Natuurlijk is het op papier een stuk beter concept dan wat we nu hebben, maar tot op heden hebben alle 'site optimizing' tooltjes en platformen bar weinig toegevoegd aan snellere sites. Maar per saldo enkel voor mobiele sites, tablets en PC's zitten nog met de 'traditionele' problemen.

[Reactie gewijzigd door SinergyX op 7 oktober 2015 17:12]

Adblockers gaan moeilijk worden met deze nieuwe techniek, omdat het zal lijken alsof het een deel van de website is. Ads zullen het echter niet zo snel meer vertragen. Ze worden immers op het zelfde domein gehost
Niet als de ads allemaal in een iframe zitten. Die zijn makkelijk te herkennen door een adblocker.
Websites gebruiken zelf ook iframes. Je kunt moeilijk alle iframes standaard gaan blocken. 90% van de gevallen zal dat goed gaan, maar de overige 10% zal foutief worden weergegeven.
Ik heb in Sandboxie een volledige blokkade op iFrames van alle pagina's standaard aanstaan. Op alle sites waar ik kom heb ik geen problemen.

Heel soms de obscure pagina's waar je een fout krijgt, maar dat is in mijn gebruik nihil.
Geen last van, bij sites die ik veel gebruik en dus respecteer doe ik de moeite om ads toch te deblokkeren. Ik zal dan wel uitvissen hoe en welke iframes geblockt moeten worden.

Bij sites die ik niet vaak gebruik ... tjah, sorry maar met de huidige manier van ads voorschotelen op sommige sites ga ik echt niet uitvogelen wat wel en niet geladen moet worden, standaard blokkeren dus.

Klein voorbeeld, Arstechnica bezoek ik dagelijks meerdere malen, hun huidige black-theme om toch maar te passen binnen de LG ads vind ik VERSCHRIKKELIJK!

Bijgevolg al een paar dagen ars wel "gescand" maar eigenlijk amper een artikel gelezen.
Met een goede adblocker zijn reguliere websites al inderdaad veel sneller en is er weinig behoefte aan een snellere HTML. De insteek van Google is dus: Minder nuttige data zodat we meer van uw bezigheden kunnen traceren.
Vraag me dan echt af wat voor een soort computer je hebt en welke websites je bezoekt.
Flash uitstaan op je mobiele telefoon? Zat dat er nog op bij jou dan?
Het mobiele web was toch altijd snel totdat ineens alles responsive moest? Alleen de m. of mobile. URLs waren niet ideaal.

Dit is een voorbeeld van de BBC. Gewoon "/amp" achter "bbc.com/news" in een artikel URL typen.

[Reactie gewijzigd door Baspower op 7 oktober 2015 17:05]

Het mobiele web kan retesnel, mijn eigen webpagina's komen niet boven de 1,5 MB/stuk uit en dat is met veel afbeeldingen op hoge resolutie. Een pagina zonder afbeeldingen is maar ~25kb. Inclusief fonts. Ik heb een keer de resultatenpagina van Google exact nagemaakt, 16kb. De echte pagina weegt ruimt 1mb. Dit hele project van ze is dan ook te simpel voor woorden, al die bloat heeft in de eerste instantie al niks te zoeken op een simpel webdocumentje.
Ik ben het met je eens. Ik haal al 130mbit op mijn Samsung Note 4 (4G+), en kan paginas al sneller laden dan op mijn desktop. Snelheid hoeft voor mij niet meer. Mijn struikelblok zit juist in de grootte. Ik irriteer me dood aan de 30 seconden reclamefilmpjes die laden als ik ff naar NOS Journaal wil kijken. Elke keer is het weer hup 10MB van je databundel eraf.
Ik heb dat de apps meteen met reclame meegeleverd worden en dat er bij een view een signaal naar een API doorgestuurd wordt om aan te geven dat je de reclame hebt gezien.
Als je dan op WIFI zit, dan kan ie altijd nog nieuwe reclame inladen.
Ook zou het slim zijn als nieuws-APPs een "download" knopje krijgen om alle te downloaden, zodat je in flight mode of 4G alles meteen beschikbaar hebt.
Mijn conclusie is dus: laat de sites maar rusten en zorg voor apps die beter omgaan met de databundel van je klant.
Het voordeel van responsive zit vooral in drie dingen:
  • De mobiele versie heeft vaker/bijna altijd alle functionaliteiten van de 'volle' versie. Iets wat bijna nooit het geval was op het oude mobiele web.
  • En het kost minder ontwikkel tijd omdat je niet twee losstaande versies hebt.
  • Het is een stuk stuk makkelijker om een tussenvorm te maken voor tablet browsers
Het nadeel is natuurlijk inderdaad laadtijd en 'responsive design' werd pas een ding toen mobiele browsers *in principe* snel genoeg waren. Het probleem is nu alleen - zoals ik in m'n andere langere comment uitleg - dat Facebook (en andere partijen) nu met hun eigen gesloten - snellere - platformen komen aanzetten die met het responsive web concurreren... en dat is dus weer reden om 'terug' te gaan naar sommige oudere concepten (die vroeger net zo traag waren als responsive nu is, maar ondertussen bijna instantaneous zijn).
Het is een interessant opgezet project. Een groot deel van de vertraging/frustratie op het mobiele web komt door het laden van JS frameworks, het verbouwen van pagina's tijdens het laden, banners en analyticsc trackers die de pagina vertragen, etc, etc.

AMP is vooral een flinke versimpeling van het web, vooral bedoeld voor relatief statische content zoals nieuws- of Twitterfeeds. Een AMP pagina bestaat uit puur HTML/CSS, van alle resources moet tijdens het laden de grootte duidelijk zijn, custom Javascript is niet toegestaan.

Het grote voordeel hiervan is dat er veel minder requests nodig zijn en je krijgt helemaal geen reflows en heel weinig jank tijdens het laden van de pagina.

Geen JS is natuurlijk een forse beperking, om daar omheen te werken is er een AMP javascript library die een aantal custom HTML5 elementen toevoegt zodat je toch een poll, image carrousel, etc, etc, op de pagina kwijt kan.

Analytics kan niet meer met complexe JS libraries maar alleen via een tracking pixel. Advertenties lopen ook via de AMP library waarbij wordt gezorgd dat eerst de content er staat waarna de advertenties pas worden opgehaald (in een iframe). Die advertenties kunnen vervolgens niet zorgen dat de pagina verspringt en er wordt ook voorkomen dat er super zware creatives binnen worden gehaald.

Op zich een mooi initiatief en Google lijkt zich hier redelijk op een afstand te plaatsen. Alles is vrij beschikbaar, je hoeft niets van Google te gebruiken en ze hebben al een erg brede basis van supporters. Natuurlijk doet Google dit ook niet voor niets, zij worden bedreigd door een internet dat dadelijk bestaat uit app-silo's waar alle data in opgesloten zit. Google wil alles op het open web hebben/houden en de beste manier om dat te doen is het web beter maken. Naar mijn idee doen ze met dit project een aardige poging.

[Reactie gewijzigd door bartvb op 7 oktober 2015 17:13]

wat een naieve reactie. Meerdere reacties bevestigen dat google dit initiatief neemt om adblockers tegen te gaan. Zo altruïstisch is google echt niet. De titel zou beter moeten zijn "Google presenteert amp html om adblockers te blokken"...
In meerdere reacties wordt gesteld dat Google dit vast zal gebruiken om adblockers tegen te gaan. Dat is iets heel anders dan dat Google dat daadwerkelijk doet.

Zoals ik hierboven ook al schrijf; binnen AMP pagina's komen banners in een <amp-ad> tag te staan. Hoeveel makkelijker wil je het adblockers maken?
Ik heb geen trek in een Google-curated internet.
That simple.
Als een flink deel van het verkeer zo via Google caching servers gaat lopen komt het daar wel op neer, geen behoefte aan.
Kan iemand dit even nacheck met Windows Phone 8.1 IE?
Ga naar g.co/amp
En scroll wat.
Bij mij ging hij op groen scherm ineens kon ik geen gebruik maken van WP. :+ Wel activiteitenscherm weergeven.
Na een herstart werkte het weer. (windows lumia 535)
Geen probleem op m'n 635.
Kan zijn dat het eenmalig crash was. :o Ik schrok van de actie.
Als sites er dan ook voor gaan zorgen dat ze geen plaatjes van 4mb op die pagina's gaan tonen en dit resizen
4MB, heb al eens mobile site's voorbij zien komen van rond de 80MB, was een foutje :)

/ontopic
Maar weer een standaard? Adblocker maakt een site op een mobile toch al stukken sneller?

/edit
Als ads nu van het domein komen van de site die ik bezoek en ze serveren mallware. Is de site dan wel verantwoordelijk? En daarmee ook direct aansprakelijk?

[Reactie gewijzigd door wica op 7 oktober 2015 17:29]

De "standaarden" van tegenwoordig betekenen vooral: NOG een extra platform om te gaan ondersteunen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True