Server überlastet?...

media.fastclick war schuld.. aber kann dir jetzt keine adresse geben, ich achte drauf.
 
jo das is valueclick. der nachteil von javascript-bannertags. da hängt dann die seite wenn der adserver auch hängt. ist aber sehr unwahrscheinlich dass die down sind 8O das dürfte bei der dicken Infrastruktur von denen gar nich passieren. Ich geh mal meckern ...
 
Allerdings wohl nicht ganz im Sinne der Werbepartner ;)
Wieso? Die Werbung wird doch gezeigt. Allerdings läuft derjenige, der die Werbung schaltet (hier: klamm) nicht Gefahr einer Rufschädigung durch Dritte auf Grund von unkontrollierbarem "Ausfall" (so sieht es für den Benutzer aus, der drauf wartet, dass die Seite lädt).
 
www1 scheint zur Zeit leichte Ausfallerscheinungen zu haben

Grafiken funktionieren oft nicht, Webseite kann bei erstem Aufruf nicht angezeigt werden (nach Aktualisierung gehts wieder)
 

Anhänge

  • www1.jpg
    www1.jpg
    86 KB · Aufrufe: 19
  • www12.jpg
    www12.jpg
    33,5 KB · Aufrufe: 13
PHP:
$(document).ready()
? ;)
Geht leider nicht (so einfach). Ok ich könnte den Ad-Tag on document.ready() per document.write() hinmalen. Dann haben aber u.A. die Leute ohne JS gar keine Werbung und andere blockende Ressourcen könnten auch Werbung "blocken".

Eine schönere Lösung finde ich daher IFrame-AdTags. Da kann nichts passieren weil die eh asynchron laden. Ich hab denen schon gesagt sie sollen welche bauen (bietet nicht jeder Advertiser an - per JS hat man halt mehr Statistikdaten zur Verfügung und kann auch versch. Werbemittel miteinander kommunizieren lassen/syncen).

@Grafiken
Das hat nichts mit www zu tun ... die liegen ja extern auf Static Servern.
Ich hau ma Ecki an was da los war.
 
Geht leider nicht (so einfach). Ok ich könnte den Ad-Tag on document.ready() per document.write() hinmalen. Dann haben aber u.A. die Leute ohne JS gar keine Werbung und andere blockende Ressourcen könnten auch Werbung "blocken".

Eine schönere Lösung finde ich daher IFrame-AdTags. Da kann nichts passieren weil die eh asynchron laden. Ich hab denen schon gesagt sie sollen welche bauen (bietet nicht jeder Advertiser an - per JS hat man halt mehr Statistikdaten zur Verfügung und kann auch versch. Werbemittel miteinander kommunizieren lassen/syncen).

@Grafiken
Das hat nichts mit www zu tun ... die liegen ja extern auf Static Servern.
Ich hau ma Ecki an was da los war.

Selbst Iframes sind zu blocken !!!
Keine gute Idee Lukas ...
 
Was hindert dich dran, die ganze JS-Werbung in iFrames zu stecken?
Das würde für jedes Werbemittel 1 Connection mehr bedeuten,da ich die jeweilige IFrame-Source ja hosten müsste. Wenn Du klamm jetzt aufrufst, brauchst Du 1 Connection - mit IFrames dann 4-5 und das würde die Server vermutlich plätten. Ok plätten nicht direkt aber es wäre unnötige Mehrlast. Bis auf valueclick hab ich überall auch Iframes bekommen bisher. Das schaffen die dann auch noch.

Edit: Würde nicht auch das DEFER Attribut im JS-Tag helfen?
Das sagt dem Browser doch "mach schonma weiter", oder?


Selbst Iframes sind zu blocken !!!
Keine gute Idee Lukas ...
Es geht hier nicht um Werbung blocken, sondern darum, dass das Laden der Werbemittel den Seitenaufbau blockiert. Da IFrames asynchron (unabhängig) zum restlichen Dokument geladen werden, würde das damit nicht passieren.
 
Das würde für jedes Werbemittel 1 Connection mehr bedeuten,da ich die jeweilige IFrame-Source ja hosten müsste. Wenn Du klamm jetzt aufrufst, brauchst Du 1 Connection - mit IFrames dann 4-5 und das würde die Server vermutlich plätten.
Soll ich Pipelining für dich anschalten? :mrgreen:

edit:
Edit: Würde nicht auch das DEFER Attribut im JS-Tag helfen?
Das sagt dem Browser doch "mach schonma weiter", oder?
So wie ich das les, ist doch genau das Gegenteil der Fall: Du manipulierst die Seite ja mittels Script und kannst deshalb das Attribut nicht verwenden. - So versteh ich das jedenfalls:
When set, this boolean attribute provides a hint to the user agent that the script is not going to generate any document content (e.g., no "document.write" in javascript) and thus, the user agent can continue parsing and rendering.
Quelle: W3C
 
Zuletzt bearbeitet:
Edit: Würde nicht auch das DEFER Attribut im JS-Tag helfen?
Das sagt dem Browser doch "mach schonma weiter", oder?

Originally, this is nothing more than a hint to the browser that the script inside the tags does not modify the content of the web page (by doing a document.write, for instance).

Wird in deinem Fall also nicht funktionieren. Du könntest allerdings alle Werbecodes erst am Ende der Seite durch JavaScript in die Seite schreiben, wie theHacker schon vorgeschlagen hat. Aber ich weiß gerade nicht, ob document.write() dann so funktioniert, wie du dir das vorstellst...

Edit: Zwei Deppen...

Edit 2: Testcase: https://jsbin.com/ocufe
 
Zuletzt bearbeitet:
Naja Du kannst ja auch nach dem rendern noch jederzeit document.write() nutzen. Ich verstehe das so, dass man es nutzen kann, falls der Inhalt, der durch das JS generiert wird, nicht unbedingt sofort verfügbar sein muss. Und das ist ja der Fall.

Edit: OK Defer funzt nicht, grad gestetet.
So ein Attribut "halts maul und lade das jetzt asynchron" wäre nich übel. :ugly:

Edit2:
Soll ich Pipelining für dich anschalten?
Request mein ich, nicht connection.

Du könntest allerdings alle Werbecodes erst am Ende der Seite durch JavaScript in die Seite schreiben
Finde ich halt unschön, da dann der <noscript>-Teil des AdTags dann ad absurdum geführt werden würde.
 
Finde ich halt unschön, da dann der <noscript>-Teil des AdTags dann ad absurdum geführt werden würde.
Soweit ich mich erinnere, kann man sich ohne aktiviertes JavaScript nicht mal einloggen. Zu welchem Sinn und Zweck dann also <noscript> - Gäste jetzt mal ausgenommen? ;)