[bug] Banner/afbeelding/special-header op de FP doet irritan

[Noxious]

Op het forum is in de loop van vorig jaar Check Images geautomatiseerd, wat ik een erg goede zaak vind!
Maar er is iets waar ik me extreem aan erger.

Voor sommige dingen zou t.net zelf hetzelfde moeten doen, voornamelijk de navigatie/cartech special header op de FP, maar ook de grote Visual Studio 2010 banner die op het moment op zowel het forum als de FP voorkomt (en er zijn vast nog meer dingen).

Deze worden 'later' geladen als de rest van de header, en eigenlijk pas nadat alle content er staat. Als ik snel door nieuwsberichten heen wil klikken smorgens, dan loop ik er iedere keer tegenaan dat net voor m'n 'klikmoment' de hele boel verspringt waardoor ik ineens totaal de weg kwijt ben.

Deze header bedoel ik dus: http://s0.2mdn.net/186244...ouseJaap_ThemaCartech.jpg en ook met sommige banners.

[crisp]

In de eerste plaats is de Visual Studio banner binnen de devschuur inderdaad wel heel erg aanwezig (en zal dat ook nog wel een tijdje blijven), maar je snijdt hier een heel ander probleem aan: namelijk het inladen en tonen van banners.

Sinds jaar en dag zijn wij van mening dat banners de beschikbaarheid van onze content niet mogen verstoren; in het kader van 'content eerst' laden wij de banners dus pas achteraf in, en als er een banner geserveert wordt dan plaatsen we die dynamisch op de juiste plek. Gezien het feit dat we daarvoor geen gereserveerde ruimtes hebben gaat dat helaas gepaart met een verspringing van de layout.

Het alternatief is om de banners op de plek waar ze moeten komen in te laden. Gezien het feit dat bijna alle banners dmv javascript worden geinjecteerd betekent dit dat de browser op dat punt stopt met renderen totdat de javascript binnengehaald en uitgevoerd is ('blocking' van rendering dus). Als je pech hebt en de adserver reageert traag (of zelfs niet) dan zit je tegen een half lege pagina aan te kijken.

De vraag is dus wat erger is... Zolang we afhankelijk zijn van derden voor de plaatsing van banners en we niet vantevoren weten of en wat voor banner er geserveerd wordt blijft dit een probleem.

Hier op het forum reserveren we doorgaans wel al een stuk ruimte bovenin omdat we sowieso adsense als fallback gebruiken om die ruimte op te vullen. Echter is de Visual Studio banner hoger dan het stuk dat we al voor adsense reserveren waardoor je helaas ook nog een stuk verspringing krijgt.

Deels is dit dus een design-issue (indien er geen banner is gebruiken we de ruimte liever voor de content zelf) en deels te wijten aan onze oplossing om de impact van het clientside-performance probleem van het inladen van banners (wat een internet-wide issue is) zo min mogelijk van invloed te laten zijn op de beschikbaarheid van onze content. Zolang het meerendeel van onze pagina's geen banners bevatten werkt dat in ons voordeel, bij campagnes met grote formaten merk je het nadeel...

[Noxious]

Hmm en die campagnes met grote formaten zijn niet achter de schermen te flaggen zeker zodat daar de juiste ruimte voor reserved is van te voren?

Nu moet ik zeggen dat het Cartech verhaal op de FP m'n grootste ergernis is, maar die Visual Studio banner kan er ook wat van.

[crisp]

Noxious schreef op vrijdag 23 april 2010 @ 10:55:
Hmm en die campagnes met grote formaten zijn niet achter de schermen te flaggen zeker zodat daar de juiste ruimte voor reserved is van te voren?

Nee, de banners worden aangelevert via een 3rd party systeem en de meeste campagnes zijn op CPM basis en draaien dus niet op 100% van de views.

Nu moet ik zeggen dat het Cartech verhaal op de FP m'n grootste ergernis is, maar die Visual Studio banner kan er ook wat van.

De cartech banner is ook een beetje een verhaal apart. Aangezien die maar tijdelijk hoeven te verschijnen bij bepaalde artikelen is besloten om die als een normale banner in te boeken via onze '3rd party'. Dat hadden we natuurlijk anders op kunnen lossen maar dat kost natuurlijk ook weer extra (schaarse) devtijd wat een beetje zonde is voor iets dat maar tijdelijk van aard is.

[Noxious]

Dat idee had ik inderdaad al, aangezien ie via doubleclick netjes teruglinkt naar t.net

[crisp]

Overigens zijn we wel aan het kijken naar manieren om het probleem van het 'verspringen' nog minder groot te maken. Het is in ieder geval iets dat onze focus heeft