Téma: Google Accelerated Mobile Pages

Lassan vissza fogunk térni a WAP-hoz...

A fő probléma az, hogy megint egy újabb verziót kell ehhez készíteni a weboldalból. Eddig volt a reszponzív, ami ment mobilon is, most megint egy újabb szabvány szerint egy újabb változatot kellene készíteni, letesztelni, stb.

Kinek van erre kapacitása? (A nagy cégeken kívül.)

Én szeretem weboldalakat kódolni hobbiból, amióta bejött a responsive azóta megutáltam és nem is csinálom.

Hobbiból az egy dolog, de itt kényszer lesz, mert vélhetően a google jobban fogja rangsorolni mobilon azokat az oldalakat, amiket ezzel a szabvánnyal kódolnak.

Hacsak nem csinálnak valami konvertert, amivel meglevő HTML-t automatikusan erre lehet konvertálni, de ez valószínűtlen, mert nem lenne trivális.

A reszponzívban az volt a pláne, hogy nem kellett kétszer dolgozni, ugyanaz az oldal megjelent olvashatóan mobilon is.

Ez az új rendszer lehet, hogy nem lesz bonyolult, de akkor is végig kell nézni minden oldalt, hogy megfelel-e neki, és ha egy komolyabb weboldalnak pl. 50 vagy több fajta aloldala is van, akkor az nem kis munka mindet végignézni.

Geri eredeti hozzászólása

A responsive nem a mobilra van kitalalva mivel ugyanaz az adatmennyiseg letoltodik a kliensnek es hiaba jelenik meg a tartalom szepen, attol meg lassu marad az oldal, mert az asztali valtozatot tolti le a mobilkliens.
Ha jol latom ez az AMP nem lesz tul komplikalt ugyhogy nem lesz nagy extra melo vele, viszont sokkal gyorsabban fognak mukodni mobilon az oldalak.

Jó, de azért ma már egy átlag weboldal által generált adatmennyiség nem tétel (ha a képeket és egyéb médiákat nem számoljuk - márpedig azok AMP-nél is megmaradnak - akkor KB-okról beszélünk, és most azért csak mindegy már, hogy 8 vagy 12 század másodperc alatt tölti le az adatot). Ráadásul a telefonomon lassan gyorabb netet kapok 3G-n mint ami a lakásba jön kábelen. Inkább azzal van a gond, ha valaki dugig pakolja olyan dolgokkal az oldalt, amitől szétfagy a böngésző (pl. tonnányi javascriptek, amik rosszul vannak megírva), és hát itt a telefon azért jóval hamarabb beadja a kulcsot mint egy PC.
Szerintem ezzel az AMP-vel elékéstek pár évet... úgy nyolcat-tizet. Akkor jól jött volna.

Sok embernek kevés adatforgalmas mobilnetje van, mert nem akar full mobilnetért fizetni még az otthoni neten felül, nekik pl. ez hasznos lesz, ha eleve tovább tart a csomagban levő adatforgalom, illetve akkor pláne, ha elfogy a csomag, és lekorlátozzák a sebességet.

Manapság inkább még a kisebbség az, akinek olyan netje van a telefonján, hogy se a sebesség, se a forgalom miatt ne kelljen aggódnia.

spontan eredeti hozzászólása

Sok embernek kevés adatforgalmas mobilnetje van, mert nem akar full mobilnetért fizetni még az otthoni neten felül, nekik pl. ez hasznos lesz, ha eleve tovább tart a csomagban levő adatforgalom, illetve akkor pláne, ha elfogy a csomag, és lekorlátozzák a sebességet.

Manapság inkább még a kisebbség az, akinek olyan netje van a telefonján, hogy se a sebesség, se a forgalom miatt ne kelljen aggódnia.

Hát, Telenornál csak most kasztálták el a mobilnetet, eddig úgy volt, hogy csak lelassítják és nincs túlforgalmazási díj (értsd: végtelen mobilnet). Vodánál még mindig így van (értsd: végtelen mobilnet). T-ről inkább nem nyilatkozom, sosem szerettem őket. Belassított mobilnettel pedig ja, jóval kisebb a sebesség, de valahogy sosem sikerült zavarnia. Plusz az, akinek korlátozott az adatforgalma, az szépen fészbúkozik, és wifiről netezik amúgy. Akkor meg aztán pláne nem számít.

De nem ez a lényeg, hanem az, hogy egyszerűen ignoráltad a hozzászólásom lényegi részét, ami arról szólt, hogy ez a dolog a képeken nem változtat. Márpedig egy weboldal forgalmának túlnyomó részét még mindig a képek adják. Hogy most 200KB javascript helyett 100 lesz, 100KB css helyett 60 lesz és 5KB html helyett 3 lesz nem fog csökkenteni az 1-2 megányi képen, ami néha egy oldalon van. Háttérképek, fejlécet, terméket bemutató képek... ez a sok adatforgalom, nem a html és css.