Vi har problem med laddtiderna i GAM När vi kopplar på 42 annonsbehållare laddas den nya sajten på 9177 msec att jämföra med 430 msec utan annonser. Vi kommer att behöva dra ner antalet annonsbehållare för att få sajten att ladda acceptabelt snabbt. Ett annat problem är att det inte går att få annonserna att ladda efter sidans laddning. Google jobbar på detta då det är fler som har problem http://www.google.com/support/forum/p/Google+Ad+Manager/thread?tid=528d88ec23c4ab5f&hl=en men dom garanterar inte att det blir löst. |
Din sista kommentar är nog inte helt sann, utan beror på hur ni lägger upp det. Om du tittar på hd.se så ser du att vänsterspalten laddar klar långt innan högerspalterna kommer på plats. Att det inte går att göra ascyncrona anrop inom GAM behöver inte nödvändigtvis vara det enda som avgör användarens upplevelse av sajten.
(sedan är ju iof 42 annonsplatser a shitload ;)
Kan bara konstatera att vi har exakt samma situation. Enda skillnaden är att vi bara har runt 30 pluggar vilket blir segt bara det. Vi har också vart på google i ärendet. Bland annat via den texten som du @Jocke vidarebefordrade till google i ämnet. Jag var på dom igen när dom hade sin RFC-runda för ett par veckor sedan. Det lät ungefär såhär:
Yes please: One important thing; We want to be able to load selected ad-slots in responce to a browser/javascript event, in contrast to the single option offered at the moment - inline in the html-loading phase. With our statistics-application (wich also lacks this possibillity) and GAM-code running to a complete, the browser DOM-loaded and load-events fire so late that using them for something usefull i doomed to fail. I should point out that we use quite a number of slots, 25-30 slots per page. Loading the major part of the slots on the load or DOM-loaded-event would make these events fire early enough to be usefull.
Frågar ni mig så har ni rätt båda två angående laddningen och upplevelsen. Kan inte heller se någon möjlighet att ladda asynkront som du säger @Erik, även om det är en våt dröm att jag har fel. Verkar lovande att dom är på det dock.
Vi kan ändå hålla oss precis ovan ytan på hd.se pga att de flesta pluggar ligger efter sidhuvud och den övre delen av löpet som laddar hyffsat kvickt. Majoriteten av annonsbulken ligger ju i högerkolumnen vilken ligger sist i html-koden, samt till viss del långt ner i löpet, och det räddar oss till stor del. Vi har genomsnittliga laddtider (vid våra datorer inhouse) på någonstans mellan 6 och 8 sek (load-eventet) och DOM-loaded bara millisekunder innan load.
Det som tråkar oss mest just nu är bildvisaren som kickar igång på DOM-loaded vilken fyrar av väldigt sent, bara millisekunder innan load :(
@martin: Tolkar jag det fel i forumet eller hintar man om att det finns en annan laddningsmodell i beta - eller skulle inte den heller lösa det? Hjälper det så kan jag nog bumpa in funktionen till oss.
Som jag minns vår tidigare diskussion på ämnet så var det här avancerade DOM-masserandet som du vill göra en "all in". Om inte alla delar av sajten stödde det, så sprack det lik förbannat, vilket innebär att vår stats-script, tex, kommer att sätta käppar i hjulen i vilket fall som helst?
Måste också fråga - är den här missen i er uppfattning något som är unikt för GAM, eller ser det lika illa ut med andra annonssystem? För ett år sedan när jag gjorde min utvärderinge så fanns det inte ens med som en parameter i bedömningen, och det kanske är en fet mea culpa på det?
Postade en av Martins texter på deras forum, tidigare har den bara skickats direkt till min kontakt:
http://www.google.com/support/forum/p/Google+Ad+Manager/thread?tid=4e3c789b45f46902&hl=en
@Jocke jo det verkar stämma. Kan eventuellt vara intressant, vi bör väl först läsa på vad "iframe tagging scheme" är och gör innan vi hoppar på dock. Känner inte igen det sedan tidigare.
"... iframe tags will load independently of page content so your ads won't have to wait for your page to load before being displayed." Här säger dom att pluggarna inte behöver vänta på resten av sidan. Vi vill ju åt det omvända förhållandet om det är går.
All-in: 100% behöver det inte vara, men iaf så pass att det inte försenar DOM-loaded för mkt. Beror delvis på typen av arbete som scriptet ska göra.
Exempel: Vi kan säkert ha ett par init-anrop, som t.ex. sidkartan, inline i koden för att få bästa speed på dom utan att det försenar allt för mkt, men inte så väldigt mkt mer. Den typen behöver inte göra så mkt arbete i laddningssekvensen. GAM däremot ska göra och ladda en j*vla massa saker innan den skickar pinnen vidare. Statistiken tar sin beskärda del också, men det kanske vi får leva med ett tag till.
@Erik: Vad kör ni för statistik-apps och hur laddas dom, 430ms med stats påslaget låter sexigt!? Kan iofs kolla själv men vad upplever ni att de tar i resurser och laddtid?
"Missen" har nog OAS också, bara det att vi inte har börjat använda LOAD/DOMLOAD-eventen mer aktivt förens på senare tid, så vi inte lidit av det i samma utsträckning.
iframe tagging refers to how the javascript will deliver the code. I was asking if there could be an iframe wrapper, so that instead of javascript code,
we add this:
<iframe src="http://pageads..../adframe.php?pubid=ca-3423423423423423&slot=Slot_name_here" />
to our page.
(ref: http://www.google.com/support/forum/p/Google+Ad+Manager/thread?tid=1e05edef4ee7b19c&hl=en)
@martin: Jag ska koppla in Johannes från oss på denna tråd så att han kan bidra med sin kunskap. I grova drag så har vi problem med dels laddningstiden och dels att vissa av våra funktioner på sajten inte fungerar förränns DOMen har laddat.
Har ni tittat på vart i världen som GAM laddas från? Ligger servrarna i USA så kan vi kanske spara lite prestanda på att ladda flasharna från en lokal server.
@jocke: Det är högintressant att komma med i den betagrupp som får testa asynkront.
En kommentar i forum som presenterar en workaround. Jag är inte säker på att jag tycker det låter så sunt ;) http://www.google.com/support/forum/p/Google+Ad+Manager/thread?fid=4e3c789b45f469020004639bb596d099&hl=en
Men det finns andra som är bättre på att bedöma det. Anyhow, jag har kollat runt lite till nu och det verkar som om både adtoma och oas hanterar annonsmatningen på samma sätt som GAM, så det borde inte göra någon skillnad där iaf.
@erik: att ladda flash lokalt tror jag inte skulle hjälpa - om jag har förstått det rätt är det inte den delen (renderingen) som är problemet. Men vad säger övriga?
@jocke: Jag gjorde en trace på GAMservern och den svarar från Kalifornien det kan vara en bidragande orsak till att det går så segt, att varje request måste över atlanten. Kan vi påverka Google så att de distribuerar sitt system till Europa så tror jag att det skulle hjälpa.
Nej, det påverkar inte renderingen om flashfilerna ligger i Sverige men det kan nog ändå påverka upplevelsen om själva flashfilen laddas snabbare. Vi kommer att prova att lägga flashfilerna hos IP-Only.
@erik: jag har lagt frågan om ett europeiskt CDN i deras forum, och jag kommer att ta upp det med googlers som jag träffar i nästa vecka. Men är det inte redan planerat så tror jag inte det händer före den 7/3...
@Jocke: Nej jag håller med. Workarounds av den typen, där man själv hackar till det, känns inte helt 100%. Hur ska man veta att man har samma driftsäkerhet och kompabilitet etc, och hur blir det med support och uppdateringar av GAM m.m? Och tar det oss verkligen närmare vårt mål? Kanske övrigt material på sidan skulle laddas snabbare, men allt arbete och laddning görs fortfarande innan DOM är laddad vad jag förstår. Rätt/fel?
Men han har rätt i det han säger: Så länge GAM-koden använder document.write blir det svårt att göra någon vettig homebrew som skulle förbättra läget väsentligt.
@Erik, eller @Jocke: Att lägga flash etc på egen vald plats, är det något som är lätt för användarna att komma igång med? Om ni ser att det blir bättre tider är hd givetvis intresserade av handgreppet.
@martin: Sista steget i bokningen är att definiera dina annonsmaterial. När det gäller flash så finns två alternativ. Hosted, då laddar man upp filen till googles cdn, eller att man bara anger en länk till var flashen finns. I det senare fallet får man alltså via någon annan mekanism lägga den på en egen, valfri server och se till att få med sig en url som kan klistras in i formuläret. Busenkelt, men ändå extra moment.
(nya safari 4 har snygga verktyg inbyggda för att kolla laddningstider etc...)