Die Top 4 JavaScript Sünden des neuen IVW Pixels

Ende 2013/Anfang 2014 steht für viele Unternehmen die Umstellung auf das neue IVW Pixel SZMnG (SZM steht für Skalierbares Zentrales Messverfahren) an. Das neue Pixel soll dabei vor allem neue technische Möglichkeiten bieten und damit der Veränderung der Internetlandschaft in den letzten Jahren Rechnung tragen. Warum dieser Plan nicht ganz aufgegangen ist, zeigt euch Tobias.

Um allen Nutzern die Umstellung so einfach wie möglich zu machen ist eine Migrationsphase eingeplant, in der beide Messverfahren parallel betrieben werden. Die Migrationsphase hat jetzt im Oktober begonnen. Rechtzeitig dazu haben wir auch das Migrationshandbuch bekommen, das die Einbindung des neuen Codes beschreibt.

Ein moderner und überarbeiteter Code für eine neue Generation des Messsystems. Das klingt doch eigentlich ziemlich vielversprechend.

Nach dem ersten Lesen des Migrationshandbuches war meine Erwartungshaltung allerdings deutlich gedämpft. All die Learnings und Best Practices aus vielen Jahren JavaScript Entwicklung haben sich leider nicht auf das neue SZMnG Tag niedergeschlagen.

Deshalb habe ich hier kurz meine Top 4 der JavaScript Sünden im neuen IVW Pixel zusammengestellt.

Platz 4: Externes Skript

Im alten SZM Tag wurde manuell ein Image Request in die Seite eingefügt. Das hatte den Vorteil, dass kein weiteres JavaScript für das Tracking benötigt wurde. Die Einbindung war dadurch aber etwas komplizierter und nicht besonders flexibel. Mit dem neuen SZMnG Tag wird jetzt auch ein allgemeines JavaScript Library eingeführt, dass die Verwendung deutlich vereinfachen soll. Leider ergeben sich hier aber gleich ein paar Probleme.

Das Skript „https://script.ioam.de/iam.js“ wird extern gehostet. Im Migrationshandbuch wird explizit darauf hingewiesen, dass keine lokale Kopie (die auf den eigenen Servern abgelegt werden kann) verwendet werden darf.

Das hat mehrere Konsequenzen. Ein externes Skript birgt für jede Webseite immer eine gewisse Gefahr, da Änderungen des Skriptes unkontrolliert erfolgen, und so unerwartete und nicht vorhersehbare Fehler passieren können. Denn jede weitere Ressource bedeutet natürlich auch einen weiteren, möglichen Point of Failure. Dies ist insbesondere deshalb gefährlich, da das SZMnG Skript blockierend im Head der Seite eingebunden werden muss.

Einen Vorteil des Skriptes muss aber in diesem Zusammenhang auch erwähnt werden. Da das Skript auf sehr vielen Internetseiten zum Einsatz kommt wird es bei den meisten Besuchern bereits im Cache gespeichert sein.

Platz 3: Globale Variablen

Das alte SZM Tag benötigte eine globale Variable. Durch Verwendung einer anonymen Funktion konnte selbst darauf verzichtet werden.

Durch die neue Aufteilung in Skript und Codesnippet auf der Seite kann jetzt nicht mehr vermieden werden, dass eine globale Variable belegt wird. Weiter benötigt das neue Skript gleich drei globale Variablen (iam_data, iom, szmvars). Statt auf eine müssen Entwickler jetzt also beim Programmieren gleich auf drei weitere Variablen achten.

Best Practices zum Namespacing existieren auch für JavaScript schon seit vielen Jahren. Schade, dass diese Praktiken es nicht in das neue SZMnG Tag geschafft haben.

Kleine Randnotiz:
Im Migrationshandbuch wird nur auf zwei der Variablen hingewiesen. Der Hinweis für „szmvars“ fehlt leider.

ivw_warnhinweise

Platz 2: Unkomprimiertes Tag

Zur Performance Optimierung ist das Komprimieren von Skripten mittlerweile ja glücklicherweise Standard. Das SZMnG Tag ist leider komplett unkomprimiert. Dabei ließe sich die Größe ohne viel Aufwand um fast 50% reduzieren (von 13KB auf 7KB).

Platz 1: document.write

document.write hat bekanntermaßen ein großes Problem. Bei Aufruf nach dem initialen Laden der Seite wird die komplette Seite „gelöscht“. Aus gutem Grunde genießt also die Verwendung von document.write unter Entwicklern einen schlechten Ruf. Insbesondere bei der Verwendung von Ajax muss stets darauf geachtet werden, dass man sich nicht durch nachgeladenen Inhalt die Seite „zerschießt“.

Auf dieses Problem wird auch im Migrationshandbuch von INFOnline hingewiesen. Es stehen deshalb mehrere Möglichkeiten zur Übertragung des SZMnG Zählpixels zur Verfügung:

ivw_default_methode

Die Auswahl eines Übertragungsmodus ist optional. Aber warum wurde beim Design des Pixels ausgerechnet die Methode mit document.write als die Default Variante ausgewählt? Die beiden Alternativen funktionieren genauso zuverlässig (Die new Image Methode wurde ja in der Tat auch vom alten SZM Tag jahrelang erfolgreich eingesetzt). Warum wurde ausgerechnet die einzige Methode mit massiven Einschränkungen und potenziell fatalen Nebenwirkungen als der Standard festgesetzt?

Besonders traurig ist, dass die meisten Probleme ohne besonderen Aufwand vermeidbar gewesen wären.

Zum Abschluss gibt es aber auch noch etwas Positives anzumerken. Durch das neue Verfahren wird die unterschiedliche Einbindung auf HTTPS Seiten abgeschafft. In Zukunft wird der Code also auf beiden Seitentypen gleich eingebunden.

Was denkt Ihr über das neue IVW Pixel SZMnG?

TAGS > , , , ,

  • Bjoern

    Hi!
    Vielen Dank für diesen Artikel. Er hat mir bei der Umsetzung des SZM-Tag 2.0 sehr geholfen. Ich befand mich leider in der Situation, dass die Seite durch den Default-Parameter defekt angezeigt wurde. Vielen Dank! :)

    Gruß
    Björn

    Antworten
  • akel

    Ich finde es eine Zumutung, dass jede Seite nun in 8 Kategorien eingeteilt werden muss! Und das, nachdem ich erst letztes Jahr alle Seiten (ca. 800) erstmals zugeordnet habe und auch viel Zeit in eine Geschwindigkeitsoptimierung gesteckt habe.

    Nun muss ich aber durch und bedanke mich recht herzlich für diesen Beitrag, anhand dessen ich mich besser mit dem SZM-Tag zurechtfinden werde. Die Dokumentation von Infonline ist wie immer grauenhaft und leider findet man wenig im Netz darüber.

    Antworten
  • Julian

    Muahaha, dieses neue Tag ist so unglaublich. Top 5 Sünde ist übrigens, dass die Entwickler scheinbar Boolean-Werte gescheut haben. Den Migrationsmodus zumindest aktiviert man mit mg = „yes“ und im Script der IVW gibt es dann lustige Abfragen wie result.mg === „yes“. True und false wäre wohl zu uneindeutig…

    Antworten
  • Julian

    Ach und Top 6: iam_data heißt die Variable… das CamelCase in JavaScript üblich ist, ist auch an der IVW vorbeigegangen.

    Antworten
  • IVW-Zählung Übertragungsmodus richtig setzen « DevBox

    […] Link: Die Top 4 JavaScript Sünden des neuen IVW Pixels […]

    Antworten
  • Chris

    Noch ein Punkt wurde hier nicht erwähnt:
    Nutzer, die die Seite ohne aktiviertes JavaScript besuchen, werden nun gar nicht mehr mitgezählt.
    Der einzige Aspekt, der diesen Punkt verschmerzbar macht, ist die Tatsache, dass das alle Seiten betrifft und die Vergleichbarkeit nicht beeinträchtigt.

    Antworten
  • Christian Haller

    Ich würde das furchtbare iam.js gerne selbst hosten, aber offensichtlich ist die Datei nicht statisch.
    https://www.dropbox.com/s/bya42ixqoqi9g7z/Screenshot%202014-07-11%2011.29.35.jpg

    Zum Nachvollziehen das Script über einen Proxy laden:
    http://anonymouse.org/cgi-bin/anon-www_de.cgi/https://script.ioam.de/iam.js

    Das könnte auch der Grund sein, warum sie es nicht minified ausliefern.

    Antworten
    • Tobias Kleyer

      Das Skript ist tatsächlich nicht statisch. Es findet ein IP Lookup statt um die Region des Users zu bestimmen. Bei mir „DE/Bayern“. Über den Proxy erhalte ich „EU/n.a.“.
      Außerdem werden im Skript auch die Pixel URLs dynamisch gesetzt. Allerdings nur bei der document.write Methode und für die Umfrage. Die Nützlichkeit dieses Mechanismus ist also mindestens fragwürdig…
      Und warum sie nicht, wie der Rest der Welt, den IP Lookup machen, wenn der Pixel Request vom System verarbeitet wird ist ein Rätsel.

      Ein selber hosten ist also im Moment tatsächlich nicht möglich. Leider.

      Antworten
  • Christian Haller

    Noch ein Nachtrag: Die globale Variable „iam_data“ kann vermieden werden, indem der Aufruf folgendermaßen umgestellt wird:
    https://gist.github.com/christianhaller/6db606f82c959b89fd87

    Antworten
  • Christian Haller

    eBay Kleinanzeigen hostest die iam.js trotzdem lokal
    https://www.dropbox.com/s/1hkjcv2t0fadiiq/Screenshot%202014-07-24%2017.28.41.jpg

    Antworten
  • Kolya

    Das Problem 4. ist heute überdeutlich geworden, als die IVW offenbar aufgrund eines Routing Problems iam.js nicht mehr ausliefern konnte und daher praktisch der gesamte deutsche Online-Journalismus still stand.

    Antworten
  • sokl

    Danke für die Aufklärung:

    Und ich habe wieder eine Seite für den DNS Filter:

    Query Request: STD A for script.ioam.de
    Request filtered

    Und ich kann trotzdem normal surfen.
    Es fing mal an mit 3 gefilterten Seite:
    Facebook.com und alle Nameserver via IP Filter
    Twitter.com
    Alles mit Google ausser Google.de

    Mittlerweile hat die Filterliste knapp 500 Einträge und ich erwäge auf WhiteList umzustellen.
    Das ist nicht normal dieses rumspionieren.

    Antworten
  • Kolya

    Das IVW Pixel spioniert nicht sondern zählt Seitenaurufe, damit Online-Zeitungen gegenüber Werbepartnern nachweisen können, wie viele Besucher sie haben und ihre Werbeplätze entsprechend vermarkten können. Kurz gesagt geht es darum, dass Online-Journalisten auch ihre Miete zahlen müssen.

    Antworten
  • Marco

    „Das SZMnG Tag ist leider komplett unkomprimiert.“ Das stimmt so ja nicht ganz. Das Ding wird ZIP-komprimiert ausgeliefert.

    Antworten

Post a comment