Irritante bannerinjection op de frontpage

[Alex)]

Op dit moment loopt op de frontpage een bannercampagne van Ordina - van het type leaderboard (728x90). Ik surf momenteel veel via Remote Desktop, en dan bezoek ik ook de FP. Het laden van de FP is zo klaar, daarna wordt echter die banner geïnjecteerd waardoor de boel omlaagspringt. Op een gewone verbinding is dit in een fractie van een seconde gedaan, via Remote Desktop duurt het wat langer... hij moet immers de hele site zo'n 100 pixels omlaagschuiven... Uiteindelijk duurt het dus bijna 5 seconden voordat de frontpage geladen - en bruikbaar - is, hetgeen erg lang is - zelfs via Remote Desktop.


Kan er alsjeblieft iets worden bedacht zodat die banner-injectie er niet voor zorgt dat die boel verschuift?

[Wouter Tinus]

Volgens mij is daar weinig aan te doen. Het idee is om de banners pas als laatste in te laden (het is immers minder belangrijk dan de content), dus op het moment dat de pagina voor het eerst gerenderd wordt is nog bekend of er ruimte vrij moet worden gehouden.

[P_de_B]

Wouter bedoelde vast 'onbekend'

[Wouter Tinus]

Dat denk ik ook

[crisp]

Alex) schreef op dinsdag 17 juli 2007 @ 16:37:
[...]
Kan er alsjeblieft iets worden bedacht zodat die banner-injectie er niet voor zorgt dat die boel verschuift?

Grofweg gezien zijn er 2 mogelijkheden waarbij je het verspringen voorkomt:

1) De banner inline inladen op de plek waar hij ook dient te komen; dit betekent dat eerst de banner zal worden ingeladen en daarna pas de rest van de content. Gevolg is dat de content niet meteen beschikbaar is en bij een bokkende adserver zal de browser mogelijk zelfs wachten op een timeout.

2) De ruimte vast reserveren waardoor er in het geval van geen banner dus een grote lege ruimte overblijft.

Dat zijn beide ook geen redelijke alternatieven wel?

Maar wacht, er is nog een 3e optie

[Glaanie]

crisp schreef op dinsdag 17 juli 2007 @ 17:09:
[...]

Grofweg gezien zijn er 2 mogelijkheden waarbij je het verspringen voorkomt:

1) De banner inline inladen op de plek waar hij ook dient te komen; dit betekent dat eerst de banner zal worden ingeladen en daarna pas de rest van de content. Gevolg is dat de content niet meteen beschikbaar is en bij een bokkende adserver zal de browser mogelijk zelfs wachten op een timeout.

2) De ruimte vast reserveren waardoor er in het geval van geen banner dus een grote lege ruimte overblijft.

Dat zijn beide ook geen redelijke alternatieven wel?

Maar wacht, er is nog een 3e optie

Dit lijkt mij makkelijker en voor alle partijen de beste oplossing (let op, er staat LIJKT mij, ik denk alleen logisch na, met kennis die ik 2 jaar geleden voor het laatst heb toegepast):
4) Op de achtergrond checken of er een banner is, als ja, banner laden met witruimte, zo nee, niets doen. Zo moeilijk moet het toch niet zijn om te checken op een banner?

[Fire69]

5) Zorgen voor een sneller lijntje waarover je Remote Desktop gebruikt?

[Alex)]

Fire69 schreef op dinsdag 17 juli 2007 @ 22:38:
5) Zorgen voor een sneller lijntje waarover je Remote Desktop gebruikt?

Betaal jij? (Ik krijg binnenkort een wide-open ADSL2+-verbinding, ik heb nu 1 mbit up, sneller dan 1,2 mbit kan niet via ADSL)

Ontopic: ik persoonlijk heb geen enkel bezwaar tegen een leeg advertentievlak, op veel sites (Tweakers niet natuurlijk, anders zou ik niet klagen) zie ik die vlakken toch

[kamerplant]

Fire69 schreef op dinsdag 17 juli 2007 @ 22:38:
5) Zorgen voor een sneller lijntje waarover je Remote Desktop gebruikt?

Ook zonder remote desktop is het vrij vervelend dat zodra je op een knop klikt en er ineens een banner tussen verschijnt. Verspringende content leest ook niet prettig waardoor je sowieso moet wachten totdat de banner is geladen voordat je begint te lezen.
Persoonlijk zou ik het wel erg prettig vinden als hier een creatieve fix op gevonden kan worden. Zoals genoemd: Een check of een banner beschikbaar is en vooraf ruimte reserveren, is dat geen optie?

[crisp]

Datafeest schreef op dinsdag 17 juli 2007 @ 22:51:
[...]
Een check of een banner beschikbaar is en vooraf ruimte reserveren, is dat geen optie?

Er is maar 1 mogelijke check om te kijken of er een banner geserveerd gaat worden: de banner opvragen en kijken of je wat terug krijgt. Dat wil je niet doen voordat je je reguliere content serveert omdat dat juist de boel ophoudt, daarom doen we het als laatste.

[Verwijderd]

Fire69 schreef op dinsdag 17 juli 2007 @ 22:38:
5) Zorgen voor een sneller lijntje waarover je Remote Desktop gebruikt?

Nog een andere optie: Gewoon abbo worden, geen banner in zich dan. Wellicht zelfs goedkoper dan een nieuwe/betere/snellere lijn ;-)

[Fire69]

Datafeest schreef op dinsdag 17 juli 2007 @ 22:51:
[...]

Persoonlijk zou ik het wel erg prettig vinden als hier een creatieve fix op gevonden kan worden.

Banner onderaan de pagina zetten?

Even serieus, persoonlijk zou het mij ook niet storen gewoon een wit vak te zien.
Hoevaak gaat het gebeuren dat die banner niet beschikbaar is? Bijna nooit lijkt me. Dan heb je dus gewoon een pagina waar 1sec een wit vak staat dat daarna opgevuld wordt. Big deal... Doen!

[kamerplant]

In de praktijk blijft een banner vaak een bepaalde tijd op een vaste plek staan. Dat wetende zou bijvoorbeeld ieder half een uur bannerrequest uitgevoerd kunnen worden om te controleren of een banner aanwezig is, aan de hand daarvan wordt een keuze gemaakt:

• Wordt wel een banner ontvangen -> Reserveer het a.s. half uur bij iedere gebruiker de ruimte (indien geen banner dus een leeg vlak)
• Wordt geen banner ontvangen -> Gebruik de huidige methode (= vooraf geen ruimte gereserveerd, hoewel een banner kan worden ingevoegd)

Indien banners vaak wisselen van plaats, of onvoorspelbaar verschijnen, dan gaat dit natuurlijk niet lekker werken. Daarbij is het consistent gedrag van een website imo wel erg belangrijk, wat dat betreft is deze oplossing dan misschien niet erg sterk Het is maar een suggestie

[crisp]

Fire69 schreef op dinsdag 17 juli 2007 @ 23:04:
[...]


Banner onderaan de pagina zetten?

Even serieus, persoonlijk zou het mij ook niet storen gewoon een wit vak te zien.
Hoevaak gaat het gebeuren dat die banner niet beschikbaar is? Bijna nooit lijkt me. Dan heb je dus gewoon een pagina waar 1sec een wit vak staat dat daarna opgevuld wordt. Big deal... Doen!

Wrong assumption: soms hebben we tijden dat de bannerposities niet of nauwelijks gevuld worden, soms is er een bepaalde campagne waarbij er gedurende een periode weer heel veel bannerposities gevuld worden, maar soms ook enkel getarget op een bepaald onderdeel van de site of op bepaalde keywords. Dit is dus volkomen onvoorspelbaar en wij spelen daar verder ook geen rol in (behalve dat we aangeven wat voor soort banneruitingen we niet willen zien - geluid, floaters e.d.)

Datafeest schreef op dinsdag 17 juli 2007 @ 23:06:
In de praktijk blijft een banner vaak een bepaalde tijd op een vaste plek staan. Dat wetende zou bijvoorbeeld ieder half een uur bannerrequest uitgevoerd kunnen worden om te controleren of een banner aanwezig is, aan de hand daarvan wordt een keuze gemaakt:

Ook een foute aanname. Sommige campagnes zijn inderdaad op views ingekocht en zullen gedurende een bepaalde periode veelvuldig te zien zijn, maar veel vaker nog worden banners gecapped en afgewisseld.

[Wouter Tinus]

In de praktijk blijft een banner vaak een bepaalde tijd op een vaste plek staan. Dat wetende zou bijvoorbeeld ieder half een uur bannerrequest uitgevoerd kunnen worden om te controleren of een banner aanwezig is

Dat kan alleen als de banner daadwerkelijk bij iedere pageview verschijnt, maar vaak zijn ze ook 'persoonlijk' (d.m.v. een cookie), waardoor je ze bijvoorbeeld maar een keer per zoveel tijd of pageviews te zien krijgt. Soms zijn ze alleen getarget op bepaalde categorieën/siteonderdelen, of bepaalde regio's (a.d.h.v. ip-adres). Dat is allemaal op geen enkele manier af te vangen aan de kant van de server.

[Alex)]

Hmm, het blijft irritant, die banner-injecties (zie ook de link in mijn sig, ik heb er een klein stukje over geschreven), ook bij nieuwsartikelen vind ik het een gruwelijk irritante plek...

Op het moment dat bij een bericht een banner wordt geladen verspringt het hele bericht in breedte, hetgeen echt niet fijn leest... zet die banner dan middenonder een bericht i.p.v. ernaast... of gebruik een fixed positie die je opvult met reclame voor je eigen dingen...

"Geen banners meer zien? Neem een abonnement!"
"De laagste prijzen vinden? Pricewatch!"
"Nieuwe software zoeken? Meuktracker!"

Op die manier verspringt de content tenminste niet op allerlei manieren... dat is gewoon al irritant maar via Remote Desktop helemaal...

[Verwijderd]

Misschien een optie mogelijk maken in de profiel om (witte) vlakken te laten zien op de plekken waar normaal banners staan of er nu wel of niet een campagne loopt.

[Onbekend]

Ik reageer ook even op de TS.

Ik heb een vrij snelle directe internetverbinding (7000 kbps), maar bij mij duurt het ook zo'n 5 seconden voordat die banner in beeld verschijnt. Soms klik ik dan wel eens per ongeluk op de advertentie i.p.v. op de link die ineens 100 pixels naar beneden verschuift.
Sinds de Frontpage is vernieuwd staat FireFox constant tussen de 35% en 50% te draaien. (Waarschijnlijk door de JavaScript/Ajax-functionaliteit.)

Elke keer krijg ik de zelfde flash-advertentie te zien van Ordina met die reischeque.

[Wouter Tinus]

Alex) schreef op dinsdag 17 juli 2007 @ 23:20:
zet die banner dan middenonder een bericht i.p.v. ernaast...

Dan kan je meteen de prijzen halveren omdat het zo'n achterafpositie is.

of gebruik een fixed positie die je opvult met reclame voor je eigen dingen...

Reclame voor T.net op T.net . En begrijp ik het goed dat jij na al dat bannergeklaag op je blog nu zit te vragen om altijd zo'n groot blok op te vullen met reclame, in plaats van alleen als het nodig is?

Op die manier verspringt de content tenminste niet op allerlei manieren... dat is gewoon al irritant maar via Remote Desktop helemaal...

Ik zou wel eens een poll willen houden om te vragen hoeveel bezoekers via een trage remote desktop-verbinding aan het browsen zijn . Sorry hoor, maar dit soort ingrijpende maatregelen doorvoeren voor een enkeling vind ik persoonlijk erg ver gaan.

[Wouter Tinus]

Onbekend schreef op dinsdag 17 juli 2007 @ 23:27:
maar bij mij duurt het ook zo'n 5 seconden voordat die banner in beeld verschijnt.

Het alternatief is dan dat je 5 seconden aan het wachten bent voor je überhaupt iets in beeld krijgt. Dit is precies de reden waarom banners achteraf geladen worden.

Verwijderd schreef op dinsdag 17 juli 2007 @ 23:25:
Misschien een optie mogelijk maken in de profiel om (witte) vlakken te laten zien op de plekken waar normaal banners staan of er nu wel of niet een campagne loopt.

Een betere profieloptie zou zijn om banners voor de content te laden. Wie wil er nou met grote lege vlakken op alle mogelijke bannerposities (dat zijn er veel ) opgescheept zitten.

[ Voor 28% gewijzigd door Wouter Tinus op 17-07-2007 23:37 ]

[crisp]

Alex) schreef op dinsdag 17 juli 2007 @ 23:20:
Hmm, het blijft irritant, die banner-injecties (zie ook de link in mijn sig, ik heb er een klein stukje over geschreven),

Ik vind alleen het stukje over NG (wat imo ook alweer gedeeltelijk achterhaald is)

ook bij nieuwsartikelen vind ik het een gruwelijk irritante plek...

Op het moment dat bij een bericht een banner wordt geladen verspringt het hele bericht in breedte, hetgeen echt niet fijn leest... zet die banner dan middenonder een bericht i.p.v. ernaast... of gebruik een fixed positie die je opvult met reclame voor je eigen dingen...

Die positie hadden we aan de rechterkant (daarbij versprong iig de content van het artikel zelf niet), maar de meeste bezoekers vonden daardoor de content-column te smal...

Midden onder een artikel is geen optie voor de adverteerders omdat dan in de meeste gevallen de banner al dan niet gedeeltelijk 'onder de fold' komt te staan.

... dat is gewoon al irritant maar via Remote Desktop helemaal...

Tsja, maar dat laatste is een uitzonderlijke situatie (misschien niet voor jou maar wel voor de gemiddelde bezoeker). Misschien zou je Lynx kunnen gebruiken, ik denk dat dat wel sneller werkt via Remote Desktop - dan hoef je ook geen plaatjes, css en js binnen te halen (en heb je ook geen banners)

[Onbekend]

Toevoeging op mijn vorige post:

Wouter Tinus schreef op dinsdag 17 juli 2007 @ 23:16:
[...]
Dat kan alleen als de banner daadwerkelijk bij iedere pageview verschijnt, maar vaak zijn ze ook 'persoonlijk' (d.m.v. een cookie), waardoor je ze bijvoorbeeld maar een keer per zoveel tijd of pageviews te zien krijgt. Soms zijn ze alleen getarget op bepaalde categorieën/siteonderdelen, of bepaalde regio's (a.d.h.v. ip-adres). Dat is allemaal op geen enkele manier af te vangen aan de kant van de server.

Elke keer krijg ik de zelfde flash-advertentie te zien van Ordina met die reischeque.
Ik vraag me dan af waarom ik steedsd deze advertentie krijg. Deze is voor een Java-specialist en ik heb daar echt 0,0 ervaring mee. In mijn profiel staat dat dan ook niet aangevinkt.
Naar mijn mening zijn wisselende advertenties zinvoller.

[kamerplant]

Mag ik vragen waarom je Tweakers.net uberhaupt via Remote Desktop zou willen bekijken? Als je toegang tot internet hebt om RDP te kunnen gebruiken, dan kun je ook wel de lokale browser aanslingeren? Ga dan niet zaniken over veiligheid, Tweakers.net is geen banksite ofzo.
Het zou idd prettig zijn als dit banner-gedrag veranderd kan worden, maar als dat niet kan, tsja.. ach, op een lokale browser went dit gedrag wel.

@Onbekend. Sommige banners zullen wel gewoon altijd verschijnen tot een bepaald moment, onafhankelijk van je locatie of wat dan ook.

[ Voor 14% gewijzigd door kamerplant op 17-07-2007 23:37 ]

[Soultaker]

Er zijn legio manieren om je probleem zelf op te lossen:
• gebruik een lokale browser (wat voor systeem heeft wel support voor RDP, en de resources om dat goed te draaien, maar geen webbrowser?), desnoods een tekstbrowser;
• zet JavaScript uit - dan krijg je alleen statisch geplaatste banners;
• zet plaatjes uit in je browser.
Ik heb het idee dat je (de TS) specifiek op zoek bent naar problemen om je kritiek op de banners te motiveren. Vooral de noodzaak om Tweakers.net via RDP te bezoeken ontgaat me een beetje.

[Wouter Tinus]

Onbekend schreef op dinsdag 17 juli 2007 @ 23:33:
Elke keer krijg ik de zelfde flash-advertentie te zien van Ordina met die reischeque.
Ik vraag me dan af waarom ik steedsd deze advertentie krijg. Deze is voor een Java-specialist en ik heb daar echt 0,0 ervaring mee. In mijn profiel staat dat dan ook niet aangevinkt.
Naar mijn mening zijn wisselende advertenties zinvoller.

Tja, dat is de keus van de bannerboer en/of de klant (Ordina in dit geval), niet de onze .

[crisp]

Onbekend schreef op dinsdag 17 juli 2007 @ 23:27:
Sinds de Frontpage is vernieuwd staat FireFox constant tussen de 35% en 50% te draaien. (Waarschijnlijk door de JavaScript/Ajax-functionaliteit.)

Elke keer krijg ik de zelfde flash-advertentie te zien van Ordina met die reischeque.

Ik denk dat dat CPU gebruik juist van die Ordina flash-banner komt. Onze JS/AJAX-functionaliteit is puur on demand en is niet continue 'iets' aan het doen.

Helaas zien we wel meer resource-opslokkende banners langskomen; als een bepaalde banner echt problemen oplevert bij meerdere van onze gebruikers dan mag dat best gemeld worden en kijken wij of er wat aan gedaan kan worden

[Alex)]

Datafeest schreef op dinsdag 17 juli 2007 @ 23:33:
Mag ik vragen waarom je Tweakers.net uberhaupt via Remote Desktop zou willen bekijken? Als je toegang tot internet hebt om RDP te kunnen gebruiken, dan kun je ook wel de lokale browser aanslingeren? Ga dan niet zaniken over veiligheid, Tweakers.net is geen banksite ofzo.

Ik heb weinig zin om bijvoorbeeld op mijn werk (iedereen gebruikt die computer waar ik op werk) in te loggen op T.net (en GoT), als het net zo makkelijk kan via RDP.

(Ja, werk is werk, en niet privè, maar met mijn werk heb je ieder half uur afleiding nodig tegen woordblindheid - ik benn een soort menselijke spellchecker)

[Jungian]

Zet een portable versie van Firefox op een USB-stick. Klaar.

edit:
Wat een ongelofelijke hoeveelheid gezeik over de ads op je blog trouwens

[ Voor 41% gewijzigd door Jungian op 18-07-2007 00:14 . Reden: ads is met 1 d 8-| ]

[Onbekend]

crisp schreef op dinsdag 17 juli 2007 @ 23:37:
[...]

Ik denk dat dat CPU gebruik juist van die Ordina flash-banner komt. Onze JS/AJAX-functionaliteit is puur on demand en is niet continue 'iets' aan het doen.

Helaas zien we wel meer resource-opslokkende banners langskomen; als een bepaalde banner echt problemen oplevert bij meerdere van onze gebruikers dan mag dat best gemeld worden en kijken wij of er wat aan gedaan kan worden

Ik heb even de flash op stop gezet en dan zakt FireFox terug naar 0 tot 1%. Dus de flash lijkt inderdaad de oorzaak.

Ik heb even op het forum gezocht en kwam de laatste regelst tegen van deze post:
letatcest in "TNet heeft een [s]nieuw logo[/] nieuwe w..."
In de vorige versie van de Frontpage werden er Google Ads geserveerd. Sinds de nieuwe versie zijn dat dus flash-banners geworden.
De traagheid ligt dus aan de banner en niet aan de nieuwe Frontpage zelf.

(Toen ik die flash even op stop had gezet, vond ik die Frontpage veel lekkerder werken. )

[crisp]

Onbekend schreef op woensdag 18 juli 2007 @ 07:58:
[...]
In de vorige versie van de Frontpage werden er Google Ads geserveerd. Sinds de nieuwe versie zijn dat dus flash-banners geworden.

In de vorige layout hadden we naast Google Ads ook 'gewone' banners (meestal flash, daar houden adverteerders blijkbaar van). Dat het zo opviel bij de introductie van de nieuwe layout was omdat Microsoft op dat moment een grote bannercampagne had lopen, net als Ordina nu.

[kamerplant]

Alex) schreef op woensdag 18 juli 2007 @ 00:07:
[...]
Ik heb weinig zin om bijvoorbeeld op mijn werk (iedereen gebruikt die computer waar ik op werk) in te loggen op T.net (en GoT), als het net zo makkelijk kan via RDP.

Waarom lukt inloggen op RDP dan wel zo makkelijk?

offtopic:
Nofi, maar door je blogpost in je sig vind ik je niet echt geloofwaardig meer overkomen.

[Alex)]

Datafeest schreef op woensdag 18 juli 2007 @ 08:13:
[...]

Waarom lukt inloggen op RDP dan wel zo makkelijk?

offtopic:
Nofi, maar door je blogpost in je sig vind ik je niet echt geloofwaardig meer overkomen.

RDP is maar één app die bovendien nog eens secure is ook, wat je van m'n blogpost vindt mag je zelf weten...

Huh, Flash van Ordina?

* Alex) geen Flash heeft

[ Voor 6% gewijzigd door Alex) op 18-07-2007 08:46 ]

[Femme]

Alex) schreef op dinsdag 17 juli 2007 @ 23:20:
Hmm, het blijft irritant, die banner-injecties (zie ook de link in mijn sig, ik heb er een klein stukje over geschreven), ook bij nieuwsartikelen vind ik het een gruwelijk irritante plek...

Het overgrote merendeel van onze gebruikers beschikt tegenwoordig over een snelle internetverbinding waarbij de verspringing nauwelijks een probleem is. Feit is dat wij gewoon bepaalde afwegingen moeten maken tussen de belangen van verschillende soorten gebruikers, adverteerders, onze eigen commerciële belangen, enz. Jij als gebruiker denkt alleen aan je eigen belang en dat is in dit geval van iemand met een trage verbinding. Het is niet mogelijk om iedereen tevreden te stellen.

Op het moment dat bij een bericht een banner wordt geladen verspringt het hele bericht in breedte, hetgeen echt niet fijn leest... zet die banner dan middenonder een bericht i.p.v. ernaast... of gebruik een fixed positie die je opvult met reclame voor je eigen dingen...

"Geen banners meer zien? Neem een abonnement!"
"De laagste prijzen vinden? Pricewatch!"
"Nieuwe software zoeken? Meuktracker!"

Op die manier verspringt de content tenminste niet op allerlei manieren... dat is gewoon al irritant maar via Remote Desktop helemaal...

Ik denk niet dat we mensen gelukkig gaan maken door de site vol te zetten met overbodige content, alleen om wat verspringing te voorkomen bij een kleine minderheid van de users die een trage verbinding heeft.

Overigens vind ik de blogpost met je "ongezouten schrijfstijl", zoals je het zelf noemt, tamelijk oppervlakkig en rijk aan onjuistheden.

[Alex)]

Femme schreef op woensdag 18 juli 2007 @ 09:24:
[...]


Het overgrote merendeel van onze gebruikers beschikt tegenwoordig over een snelle internetverbinding waarbij de verspringing nauwelijks een probleem is. Feit is dat wij gewoon bepaalde afwegingen moeten maken tussen de belangen van verschillende soorten gebruikers, adverteerders, onze eigen commerciële belangen, enz. Jij als gebruiker denkt alleen aan je eigen belang en dat is in dit geval van iemand met een trage verbinding. Het is niet mogelijk om iedereen tevreden te stellen.

Dat is waar, dat is heel moeilijk..

[...]


Ik denk niet dat we mensen gelukkig gaan maken door de site vol te zetten met overbodige content, alleen om wat verspringing te voorkomen bij een kleine minderheid van de users die een trage verbinding heeft.

Mja, dat is waar...

Mm, dan bezoek ik via remote desktop de pda-versie wel, die is - vooralsnog - bannervrij

Overigens vind ik de blogpost met je "ongezouten schrijfstijl", zoals je het zelf noemt, tamelijk oppervlakkig en rijk aan onjuistheden.

Je kunt reageren hoor

[Rrob]

Ik ben het helemaal met de TS eens, het kan onzettend irritant zijn omdat het gevolg is dat je het verkeerde artikel te zien krijgt. En ook zonder RD is het probleem aanwezig.

Femme schreef op woensdag 18 juli 2007 @ 09:24:
Het overgrote merendeel van onze gebruikers beschikt tegenwoordig over een snelle internetverbinding waarbij de verspringing nauwelijks een probleem is.

Zelfs op uni-lan is er een hinderlijke vertraging...

[ACM]

Rrob schreef op woensdag 18 juli 2007 @ 11:54:
Zelfs op uni-lan is er een hinderlijke vertraging...

Maar de keuze blijft:
- De advertenties tijdens het laden van onze page meenemen, wat er dus voor zorgt dat er altijd zo'n vertraging is voor de rest van de pagina afgemaakt wordt (en je dus dan pas kan gaan lezen).
- Alle posities vooraf reserveren en standaard opvullen met alternatieve reclame/uitingen (adsense, eigen content promoten, whatever).
- Alle posities vooraf reserveren en bij geen vulling verbergen, wat dus een verspringing de andere kant op levert.
- Alle posities standaard verbergen en als er wat is de positie vullen, wat we nu dus doen.

En de middelste twee hebben dan nog als nadeel dat we op de toppositie drie verschillende maten advertenties kunnen plaatsen en op de frontpage tonen we alleen adsense als er geen bigad en geen advertorial zijn.
Welke posities moeten we dan reserveren?

Imho blijft het een keuze uit vier kwaden, waarvan ik vooralsnog denk dat we de minst kwade nu te pakken hebben, zolang de vulratio van posities relatief laag blijft.

[ Voor 3% gewijzigd door ACM op 18-07-2007 19:05 ]

[Verwijderd]

ACM schreef op woensdag 18 juli 2007 @ 19:04:
[...]

Maar de keuze blijft:
- De advertenties tijdens het laden van onze page meenemen, wat er dus voor zorgt dat er altijd zo'n vertraging is voor de rest van de pagina afgemaakt wordt (en je dus dan pas kan gaan lezen).

Die redenering volg ik niet helemaal...?

Femme zegt: "We gaan ervan uit dat Tweakers een snelle verbinding hebben, dus het verspringen moet niet zo'n issue zijn."
Rrob zegt: "De verspringing gebeurt ook bij een snelle verbinding"
...en vervolgens zeg jij dit?

Welke keuze is er nu gemaakt? Als T.net voor een snelle verbinding is gemaakt, waarom zou het dan erg zijn om de advertenties pas op het laatst te laden? Of geef je nu toe dat T.net gewoon niet geoptimaliseerd is als er advertenties getoond worden? Wat is de gedachte hierachter?

En je gaat mij niet wijsmaken dat het niet anders kan, T.net is de enige site die ik ken waarbij zo'n verspringing gebeurt. Bij T.net oude stijl gebeurde het nooit, en duizenden andere sites die ik ken ook niet...

Ik wil trouwens ook vermelden dat dit precies de reden is dat ik nooit meer op de frontpage kom. Dat is jammer, maar het informatie-aanbod weegt niet op tegen de irritatie die die banner veroorzaakt. Helaas.

[ Voor 8% gewijzigd door Verwijderd op 18-07-2007 23:19 ]

[Alex)]

In de oude layout was waarschijnlijk een vaste <div> gereserveerd voor advertenties, als er geen ad was bleef die <div> leeg en zag je de welbekende socket (nostalgie...), in NG is er geen vaste ruimte voor advertenties ingebouwd... daardoor zijn die injections dus nodig...

[Verwijderd]

Alex) schreef op woensdag 18 juli 2007 @ 23:19:
In de oude layout was waarschijnlijk een vaste <div> gereserveerd voor advertenties, als er geen ad was bleef die <div> leeg en zag je de welbekende socket (nostalgie...), in NG is er geen vaste ruimte voor advertenties ingebouwd... daardoor zijn die injections dus nodig...

Ik ga even met de botte bijl op dit onderwerp in hakken, maar: dat interesseert mij weinig. Tweakers.net is tegenwoordig een bedrijf geworden, en ik een klant. Als klant heb ik het recht om mijn kritiek te uiten op bepaalde aspecten, en terwijl ik voorheen nog sympathie had voor achterliggende processen, interesseert het mij tegenwoordig niet zoveel meer. Tegenwoordig zie ik een minderwaardig product (de FP is dusdanig frustrerend geworden door de bannerinjections) en daarover wil ik graag mijn beklag doen.

Het verspringen is simpelweg een design-keuze, en in mijn ogen een verkeerde...

[ Voor 4% gewijzigd door Verwijderd op 18-07-2007 23:24 ]

[Snake]

Alex) schreef op woensdag 18 juli 2007 @ 23:19:
In de oude layout was waarschijnlijk een vaste <div> gereserveerd voor advertenties, als er geen ad was bleef die <div> leeg en zag je de welbekende socket (nostalgie...), in NG is er geen vaste ruimte voor advertenties ingebouwd... daardoor zijn die injections dus nodig...

offtopic:
Jezus, wat voor een blaas hebt gij, ge blijft serieus constant zeiken over dit hier allemaal. Ik heb u nog niets positief zien zeggen.
Was dat niet ooit een van u ondertitels? Alex-media. Je raakt niet uitgezeken?
En u blog? mv /blog /dev/null

Je moet niet klagen bij T.net, ga klagen bij de Advertentieaanbieders, als zij snellere server neerpoten, dan krijg jij je ads rapper voor ogen, ipv hier je gal te gaan spuien.

T.net besteld ads, gerichte, en ik denk (denk!) niet dat zij er ZOVEEL inspraak in hebben.

[ Voor 9% gewijzigd door Snake op 19-07-2007 00:30 ]

[Harm]

Kritiek leveren is prima, maar dan wel graag onderbouwd (dat doen jullie goed ) en met ideeën voor oplossingen. Niemand is blij met het verspringen, ik geloof dat we het daar allemaal wel over eens zijn. Goede oplossingen (die evenveel of minder negatieve gevolgen hebben) zijn er echter nog niet gegeven. Het lijkt mij goed als jullie daar ook over meedenken.

Verder, de bannerinjections werden voor zover ik weet al eerder gebruikt dan sinds de nieuwe frontpage. Bij een code-update van de vorige frontpage is er door crisp volgens mij ook al dat soort code toegevoegd. Helemaal nieuw is het dus niet. Wel is het mogelijk dat dit destijds, omdat banners nog een stuk minder in de site waren geïntegreerd dan nu, minder negatieve effecten had.

[Snake]

Harm schreef op woensdag 18 juli 2007 @ 23:48:
Kritiek leveren is prima, maar dan wel graag onderbouwd (dat doen jullie goed )

Mogen we nu naar het volgende klasje?

Verder, de bannerinjections werden voor zover ik weet al eerder gebruikt dan sinds de nieuwe frontpage. Bij een code-update van de vorige frontpage is er door crisp volgens mij ook al dat soort code toegevoegd. Helemaal nieuw is het dus niet. Wel is het mogelijk dat dit destijds, omdat banners nog een stuk minder in de site waren geïntegreerd dan nu, minder negatieve effecten had.

Ik denk dat ze wel in de site waren geïntegreerd, maar werden 'geplakt' over reeds bestaande content (de socket), waardoor er niets versprong.

[ACM]

Verwijderd schreef op woensdag 18 juli 2007 @ 23:17:
Die redenering volg ik niet helemaal...?

De redenering is heel simpel: Er is een keus te maken door ons tussen:
A: Altijd vertraagd laden van de hele site (wat je bij diverse andere sites ziet), waar eerst/halverwege advertenties geladen worden
B: Altijd de posities tonen en als er geen echte banners zijn, alternatieve content tonen (zodat er minder/geen verspringing is). Bij diverse andere sites zie je dat ze gewoon altijd banners inladen.
C: Altijd de ruimte reserveren, maar als er geen advertentie is het vlak verbergen: levert alsnog verspringingen op.
D: Wat we nu doen.

Femme zegt: "We gaan ervan uit dat Tweakers een snelle verbinding hebben, dus het verspringen moet niet zo'n issue zijn."
Rrob zegt: "De verspringing gebeurt ook bij een snelle verbinding"
...en vervolgens zeg jij dit?

Ja... als antwoord op de suggestie dat het anders moet kunnen. Allevier de manieren hebben nadelen, de een zorgt er voor dat we nog meer advertenties moeten vertonen, de andere dat we in het geval de advertentieservice langzaam is de site vertraagd weergeven (en dat is geen theoretisch probleem!) en de laatste twee dat er verspringingen optreden.

Welke keuze is er nu gemaakt? Als T.net voor een snelle verbinding is gemaakt, waarom zou het dan erg zijn om de advertenties pas op het laatst te laden? Of geef je nu toe dat T.net gewoon niet geoptimaliseerd is als er advertenties getoond worden? Wat is de gedachte hierachter?

Eerlijk gezegd is een snelle verbinding niet de enige vereiste om de tijd die het kost om de advertenties te tonen te minimaliseren. Een snelle PC en een browser die efficient met Javascript om kan gaan zijn ook erg nuttig. De gedachte achter mijn opmerking is dat ik een en ander in de context plaats waar wij mee zitten. Een beetje dramatisch weergegeven is onze keus dus:

- Geven we de gebruiker gewoon altijd X advertentieposities op zijn scherm (wat hebben jullie veel banners!!!!)
- Geven we de gebruiker een potentieel langzamer, maar minder springerig opbouwend scherm (jemig, het duurt af en toe meer dan 5 seconden voor er wat staat!!)
- Geven we de gebruiker een verspringende pagina (dit topic).

En je gaat mij niet wijsmaken dat het niet anders kan, T.net is de enige site die ik ken waarbij zo'n verspringing gebeurt. Bij T.net oude stijl gebeurde het nooit, en duizenden andere sites die ik ken ook niet...

Bij t.net oude stijl gebeurde het in eerste instantie met de advertorial-positie, totdat we daar maar standaard adsense in stopten om van het gespring en geklaag af te zijn, en sowieso altijd met de bigads. Dus daar gebeurde het ook, het grootste verschil was natuurlijk dat die posities lager stonden en je er wat minder van zag.
Maar ik probeer nergens te stellen dat het niet anders kan. Maar de vraag is dan of het ook beter is...

[Femme]

Verwijderd schreef op woensdag 18 juli 2007 @ 23:17:
[...]

Welke keuze is er nu gemaakt? Als T.net voor een snelle verbinding is gemaakt, waarom zou het dan erg zijn om de advertenties pas op het laatst te laden? Of geef je nu toe dat T.net gewoon niet geoptimaliseerd is als er advertenties getoond worden? Wat is de gedachte hierachter?

En je gaat mij niet wijsmaken dat het niet anders kan, T.net is de enige site die ik ken waarbij zo'n verspringing gebeurt. Bij T.net oude stijl gebeurde het nooit, en duizenden andere sites die ik ken ook niet...

Uiteraard kan het anders, bijvoorbeeld door de banner in dezelfde volgorde binnen te halen als de content van boven naar beneden wordt getoond, of door vaste ruimte te reserveren. Het eerste heeft tot gevolg dat de site gruwelijk traag kan worden op het moment dat de adserver op zijn gat ligt of slecht bereikbaar is. De tweede keuze zorgt voor inefficiënt ruimtegebruik. Ga maar eens inbeelden hoeveel ruimte er wordt verspild als er witruimte voor de leaderbord, large rectangle, tekstadvertenties en skyscraper gereserveerd moet worden op alle pagina's. Mooi layouten wordt ook knap lastig als er gaten in de layout zitten.

Onder normale omstandigheden (als er geen leaderboards zonder frequency cap draaien, zoals de nogal irritante Ordina-leaderbord van dit moment, zul je als regelmatige bezoeker niet zoveel last hebben van verspringing omdat er op de meeste pagina's alleen een tekstadvertentie getoond zal worden. Ik ben geen voorstander van advertentiecampagnes zonder frequency cap omdat ze mijn inziens snel irritatie veroorzaken en daardoor eerder contraproductief zijn voor de adverteerder.

Op dit moment zou het beter zijn om vaste ruimte voor de leaderbord te reserveren. Het probleem is dat wij pas achteraf weten of een user een leaderbord getoond krijgt. Een mooie oplossing voor server-side communicatie tussen onze servers en die van Doubleclick, waarmee dit alles voorkomen had kunnen worden, bestaat nog niet vziw.

Verder ben ik van mening dat je op T.net altijd nog weinig over advertenties te klagen hebt vergeleken met de sites van buitenlandse collega's zoals AnandTech en Tom's Hardware, die véél meer advertenties bevatten.

Harm schreef op woensdag 18 juli 2007 @ 23:48:

Verder, de bannerinjections werden voor zover ik weet al eerder gebruikt dan sinds de nieuwe frontpage. Bij een code-update van de vorige frontpage is er door crisp volgens mij ook al dat soort code toegevoegd. Helemaal nieuw is het dus niet. Wel is het mogelijk dat dit destijds, omdat banners nog een stuk minder in de site waren geïntegreerd dan nu, minder negatieve effecten had.

Het achteraf positioneren van advertenties wordt inderdaad al heel lang gedaan, sinds de introductie van de vorige layout gedaan.

[crisp]

Snake schreef op woensdag 18 juli 2007 @ 23:51:
[...]
Ik denk dat ze wel in de site waren geïntegreerd, maar werden 'geplakt' over reeds bestaande content (de socket), waardoor er niets versprong.

Inderdaad, voor wat betreft de topbanner deden we dat inderdaad - die ruimte was er standaard al maar in dit nieuwe design niet. Voor o.a. de rectangle deden we in de oude layout echter ook al 'injection'.

Uiteraard is deze issue nu weer 'hot' omdat we nu 'doodgegooid' worden met die Ordina banner...

Een deel van de vertraging komt overigens ook door onze eigen javascripts en ik zie hier en daar ook wel mogelijkheden om daar nog wat tijd vanaf te snoepen

[Onbekend]

Zoals Harm zegt is niemand blij met een verspringing.
Om geen verspringing te krijgen zou dus vooraf de ruimte gereserveerd moeten worden.
(Ik neem aan dat vlak voordat de pagina wordt geserveerd, bekend is hoe hoog die banner wordt.)

Het idee erachter om vanwege snelheidsredenen de advertenties als laatst te laden is voor de rest een prima idee.

[crisp]

Onbekend schreef op donderdag 19 juli 2007 @ 08:00:
[...]
(Ik neem aan dat vlak voordat de pagina wordt geserveerd, bekend is hoe hoog die banner wordt.)

Assumptions... Nee dus, van te voren is niet bekent of we voor de topbanner een 468x60 of 728x90 geserveerd kijken (of zelfs een 1000x120)

[Alex)]

Is het niet mogelijk om i.p.v. een JS-injection een 'gewone' (serverside) include te doen? Of zijn jullie daarvoor afhankelijk van de bannerboer?

[crisp]

Alex) schreef op donderdag 19 juli 2007 @ 08:44:
Is het niet mogelijk om i.p.v. een JS-injection een 'gewone' (serverside) include te doen? Of zijn jullie daarvoor afhankelijk van de bannerboer?

Dat laatste sowieso, het bannersysteem draait immers niet op onze eigen servers. En het serverside opvragen van de banners en inline injecteren (voor zover technisch ueberhaupt mogelijk) verplaatst het probleem van de vertraging alleen maar nog verder naar voren (het duurt langer voordat je de pagina ueberhaupt geserveerd krijgt).

Op dit moment denk ik dat enkel het zoveel mogelijk verkorten van de tijd tussen de initiele rendering van de pagina en de verspringing een haalbare optie is die een deel van de irritatie kan wegnemen.

[ Voor 14% gewijzigd door crisp op 19-07-2007 08:49 ]

[Alex)]

crisp schreef op donderdag 19 juli 2007 @ 08:48:
[...]

Dat laatste sowieso, het bannersysteem draait immers niet op onze eigen servers.

Ah ok, is dat altijd al geweest eigenlijk?

En het serverside opvragen van de banners en inline injecteren (voor zover technisch ueberhaupt mogelijk) verplaatst het probleem van de vertraging alleen maar nog verder naar voren (het duurt langer voordat je de pagina ueberhaupt geserveerd krijgt).

Dat is ook niet wenselijk nee...

Op dit moment denk ik dat enkel het zoveel mogelijk verkorten van de tijd tussen de initiele rendering van de pagina en de verspringing een haalbare optie is die een deel van de irritatie kan wegnemen.

Dat zou fijn zijn

[ACM]

Alex) schreef op donderdag 19 juli 2007 @ 08:52:
Ah ok, is dat altijd al geweest eigenlijk?

De term 'webads' zegt je vast nog wel iets, dat was onze vorige bannerleverancier en dat werkte wat dat betreft op precies dezelfde manier als nu Ik kan me iig geen tijd herinneren dat het anders was.

Dat zou fijn zijn

Voor jou blijft het probleem bestaan... Want er blijft een forse verschuiving van een stuk van het beeld waardoor je via RDP ineens een heel stuk scherm (het hele rechter vlak?) opnieuw moet ontvangen.

[justmental]

crisp schreef op donderdag 19 juli 2007 @ 08:38:
Assumptions... Nee dus, van te voren is niet bekent of we voor de topbanner een 468x60 of 728x90 geserveerd kijken (of zelfs een 1000x120)

Kun je niet standaard een ruimte van 90 hoog reserveren?
Nu verspringt de boel dus 60,90 of 120 pixels (gemiddeld 90), dan maximaal 30.

[P_de_B]

maar het kan ook zijn dat er geen banner komt, dan zit je weer met een nutteloos leeg vlak.

[justmental]

P_de_B schreef op donderdag 19 juli 2007 @ 09:38:
maar het kan ook zijn dat er geen banner komt, dan zit je weer met een nutteloos leeg vlak.

Dat kun je dan toch in je banner lader script weer weghalen?
sum(kans * hoogte) = ?, maar beduidend groter dan 0.

[Femme]

justmental schreef op donderdag 19 juli 2007 @ 09:48:
[...]

Dat kun je dan toch in je banner lader script weer weghalen?
sum(kans * hoogte) = ?, maar beduidend groter dan 0.

Maar dan zie je alsnog verspringing op het moment dat er geen leaderboard is.

Op dit moment met die overdaad aan Ordina-leaderboards zou het een handige strategie zijn, maar anders niet. Het heeft ook geen zin om een gedeelte van de ruimte te gaan reserveren, dan weet je namelijk zeker dat er altijd verspringing is.

[Harm]

Is het een idee om wel standaard ruimte te reserveren, nu je toch zeker weet dat een bepaalde banner op een bepaalde plek vaak opduikt? Of komt de banner daarom nog te weinig langs en heeft dit veel negatieve gevolgen?

[justmental]

Femme schreef op donderdag 19 juli 2007 @ 11:45:
Maar dan zie je alsnog verspringing op het moment dat er geen leaderboard is.

Op dit moment met die overdaad aan Ordina-leaderboards zou het een handige strategie zijn, maar anders niet. Het heeft ook geen zin om een gedeelte van de ruimte te gaan reserveren, dan weet je namelijk zeker dat er altijd verspringing is.

Nu heb je alleen geen verspringing als er geen leaderboard is, het is geen universele win situatie, maar vermindert de gemiddelde verspringing.
Dat bedoel ik met die kans*hoogte.
Dus bv.
20% geen leaderboard
20% 60 hoog
30% 90 hoog
30% 120 hoog
.2*0 + .2*60 + .3*90 + .3*120 = 75
Dus met het reserveren van 75 pixels hoogste heb je dan gemiddeld de minste verspringing.

[ACM]

justmental schreef op donderdag 19 juli 2007 @ 13:17:
Nu heb je alleen geen verspringing als er geen leaderboard is, het is geen universele win situatie, maar vermindert de gemiddelde verspringing.
Dat bedoel ik met die kans*hoogte.

Zelfs die kansen veranderen met de dag... Nu is er een tijdje een banner zonder frequency cap, straks komen er vast weer dagen dat we misschien 10% of 20% in totaal aan grote/kleine leaderboards hebben...

20% geen leaderboard
20% 60 hoog
30% 90 hoog
30% 120 hoog
.2*0 + .2*60 + .3*90 + .3*120 = 75
Dus met het reserveren van 75 pixels hoogste heb je dan gemiddeld de minste verspringing.

De 120-px positie bevindt zich boven de breadcrumb. dus er verschuift heel wat meer als dat ding verschijnt, gelukkig is die er bijna nooit. Maar het is dus niet zo eenvoudig in te richten als jij nu stelt.

[justmental]

ACM schreef op donderdag 19 juli 2007 @ 13:37:
De 120-px positie bevindt zich boven de breadcrumb. dus er verschuift heel wat meer als dat ding verschijnt, gelukkig is die er bijna nooit. Maar het is dus niet zo eenvoudig in te richten als jij nu stelt.

eh Hans en Grietje gaat me een beetje te ver hoor.
Het leek me dat het gemiddelde (ook al varieert het) altijd een stuk meer dan 0 zou zijn, dat is alles.
De makkelijke oplossing is natuurlijk gewoon "b_ vervangen door "x_

[Femme]

Harm schreef op donderdag 19 juli 2007 @ 11:49:
Is het een idee om wel standaard ruimte te reserveren, nu je toch zeker weet dat een bepaalde banner op een bepaalde plek vaak opduikt? Of komt de banner daarom nog te weinig langs en heeft dit veel negatieve gevolgen?

Wat we in theorie zouden kunnen doen is tijdelijk die ruimte wel reserveren als er een campagne zonder frequency cap loopt.

justmental schreef op donderdag 19 juli 2007 @ 13:51:
[...]

eh Hans en Grietje gaat me een beetje te ver hoor.
Het leek me dat het gemiddelde (ook al varieert het) altijd een stuk meer dan 0 zou zijn, dat is alles.
De makkelijke oplossing is natuurlijk gewoon "b_ vervangen door "x_

Mijn inziens maakt het weinig uit of de verspringing nu 45 of 90 pixels is, het is niet zozeer de afstand maar het feit dat er verspringing is wat als storend ervaren wordt. In een normale situatie is het merendeel van de pagina's vrij van een leaderboard. Dan is er helemaal geen verspringing nodig.

[ACM]

Femme schreef op donderdag 19 juli 2007 @ 14:06:
Wat we in theorie zouden kunnen doen is tijdelijk die ruimte wel reserveren als er een campagne zonder frequency cap loopt.

Wat ondertussen ook in de praktijk is gedaan voor de topbanner

[ Voor 3% gewijzigd door ACM op 19-07-2007 15:40 ]

[Alex)]

ACM schreef op donderdag 19 juli 2007 @ 15:40:
[...]

Wat ondertussen ook in de praktijk is gedaan voor de topbanner

Dat is al meteen een stuk beter

[Verwijderd]

Femme schreef op donderdag 19 juli 2007 @ 14:06:
Mijn inziens maakt het weinig uit of de verspringing nu 45 of 90 pixels is, het is niet zozeer de afstand maar het feit dat er verspringing is wat als storend ervaren wordt. In een normale situatie is het merendeel van de pagina's vrij van een leaderboard. Dan is er helemaal geen verspringing nodig.

Hmm, voor mij geldt dat niet zo. Het is niet zozeer irritant omdat de pagina verspringt (natuurlijk is dat ook irritant), maar meer dat er opeens een banner onder mijn cursor zit. En aangezien ik altijd tekst selecteer die ik lees, klik ik veel te vaak per ongeluk op die banner. Als het maar 45px zou verspringen, zou dat veel minder vaak gebeuren.

[Femme]

Waarom selecteer je altijd tekst die je wilt lezen?

[Alex)]

Ik vermoed dat hij dat fijner vind lezen? Lichte letters op een donkere achtergrond is wel rustiger dan andersom

[crisp]

ACM schreef op donderdag 19 juli 2007 @ 15:40:
[...]

Wat ondertussen ook in de praktijk is gedaan voor de topbanner

En daarnaast heb ik een aantal JS functies nog wat weten te versnellen en heb ik het moment van verspringen naar voren gehaald (in het geval we geen vaste ruimte kunnen reserveren)

[Alex)]

crisp schreef op donderdag 19 juli 2007 @ 16:00:
[...]

En daarnaast heb ik een aantal JS functies nog wat weten te versnellen en heb ik het moment van verspringen naar voren gehaald (in het geval we geen vaste ruimte kunnen reserveren)

Wat voor dingen heb je aangepast? (Altijd leuk om te weten)

Ik moet trouwens zeggen dat T.net wel goed naar de gebruikers luistert

[Femme]

Ik heb even contact gehad met onze vrienden van sales. De Ordina-campagne bleek per abuis zonder frequency cap te draaien . Dit zal zsm stopgezet worden.

[crisp]

Alex) schreef op donderdag 19 juli 2007 @ 16:03:
[...]
Wat voor dingen heb je aangepast? (Altijd leuk om te weten)

Ik heb in 2 generieke functies (first_child() en node_after()) een branch gemaakt voor het geval ze met of zonder expliciete nodeName worden aangeroepen hetgeen behoorlijk wat onnodige calls naar is_ignorable() scheelt

[Soultaker]

@crisp: gebruik jij ook tools om client side code te benchmarken? Zo ja, welke zijn dat, en op welke browser werken die? Of zijn dit soort tweaks nattevingerwerk?

(Lijkt me bij een complexe site als tweakers.net nogal lastig om te herleiden waar de tijd nu precies in gaat zitten.)

[crisp]

Soultaker schreef op donderdag 19 juli 2007 @ 17:01:
@crisp: gebruik jij ook tools om client side code te benchmarken? Zo ja, welke zijn dat, en op welke browser werken die? Of zijn dit soort tweaks nattevingerwerk?

(Lijkt me bij een complexe site als tweakers.net nogal lastig om te herleiden waar de tijd nu precies in gaat zitten.)

Firebug heeft een hele mooie javascript profiler
En voor PHP gebruiken we vaak Xdebug

[ Voor 6% gewijzigd door crisp op 19-07-2007 17:04 ]

[ACM]

Soultaker schreef op donderdag 19 juli 2007 @ 17:01:
Of zijn dit soort tweaks nattevingerwerk?

Zie de tools die crisp noemt, maar afgezien daarvan is het natuurlijk ook regelmatig als van ouds tijden af laten drukken, het in de gaten houden van de tijd die als "Client Parse Time" wordt getoond voor/na een wijziging, etc. En we loggen sowieso alle queries die meer dan een ingestelde tijd kostten om dat af en toe es na te kunnen lopen (en uiteraard kunnen we die tijd on-the-fly verlagen zodat we van een specifieke request zien waar de tijd in zat op het gebied van queries).

(Lijkt me bij een complexe site als tweakers.net nogal lastig om te herleiden waar de tijd nu precies in gaat zitten.)

Is het ook. En vaak zat dat we ineens allemaal trage pages zien en we geen flauw idee hebben waar het vandaan komt (eergisteren om 19:22u oid nog...), de hoeveelheid statistiek die eventueel verzameld kan worden is niet altijd een voordeel in zulke gevallen, vaak zie je door de bomen het bos niet meer.

[ Voor 4% gewijzigd door ACM op 19-07-2007 17:32 ]

[Alex)]

Net werden er bij mij ineens twee lege vlakken gereserveerd (bij een artikel), kan dat te maken hebben met een gebrek aan Flash?

[crisp]

Alex) schreef op dinsdag 24 juli 2007 @ 09:21:
Net werden er bij mij ineens twee lege vlakken gereserveerd (bij een artikel), kan dat te maken hebben met een gebrek aan Flash?

Ja, dat kan, hoewel het dan niet zo netjes is dat de bannerboer geen fallback-content heeft verzorgd.