Thomas Maier | Magento & WordPress Develover post@webzunft.de | +49 162 9313 708

Antworten auf die Fragen – nicht nur meiner Kunden 

RSS
Home WordPress Werbebanner entsprechend der Browserbreite einblenden

Werbebanner entsprechend der Browserbreite einblenden

Für eines meiner eigenen auf WordPress basierenden Projekte habe ich bereits vor Monaten auf ein responsive Design umgestellt, muss also statt einem Theme für mobile Endgeräte und einem für Desktop-Browser jetzt nur noch eines Pflegen, dass sich dank media queries im CSS dynamisch an die Breite des jeweiligen Browsers anpasst. Ein Problem bestand bis jetzt jedoch darin, die richtigen Werbebanner entsprechend der Browserbreite einzublenden. Seit einigen Tagen teste ich einen für mich neuen Ansatz, der mir dabei größtmögliche Flexibilität bietet.

Mobile an oder aus

Nachdem ich das Responsive Design zunächst online gestellt habe, gab es bei mir noch ein WordPress Plugin mit dessen Hilfe ich anhand des User Agents ermitteln konnte, ob es sich um einen mobilen Browser oder einen Desktop-Browser handelt. So ein Plugin benötigt man seit WordPress 3.4 nicht mehr unbedingt, da es jetzt mit wp_is_mobile() eine Funktion gibt, die genau das überprüft.

Ich habe schon auf meinem Vortrag beim WP Camp 2012 in Berlin betont, dass ich mir zusätzlich eine Funktion wp_is_tablet() wünsche, denn zwischen Anzeigen auf mobilen Geräten und Bannern in Desktop-Browsern fehlt mindestens noch diese Stufe. Hinzu kommt, dass es mobile Geräte gibt, die sich bewusst nicht als solche ausgeben. Oder Browser sind kleiner als die üblichen 960px oder …

Dank der heutigen Geräte- und Browservielfalt zeigt sich der weit verbreitete User Agent Ansatz als sehr fehleranfällig. Selbst mit einem manuellen Umschalten (das ich zwischendurch auch eingeführt hatte) gibt es nur ein an oder aus. Außerdem habe ich dabei gemerkt, dass auch Desktop Nutzer dann die mobile Version benutzen, weil die Seite schlanker und die Werbung kleiner ist.

Probleme mit Responsive Design

Nun lässt sich schon sehr viel mit Responsive Design machen. Doch das Problem dabei ist, dass der Quellcode weiterhin geladen wird. Im Falle von Bannern wie etwa die von Google AdSense kann man jedoch nicht einfach alle Banner laden und nur dann jene anzeigen, die ins Layout passen. Das widerstößt gegen die entsprechenden Richtlinien (die wahrscheinlich darauf zurückzuführen sind, dass allein das Laden des Codes ja als Anzeige desselben gewertet werden kann, die Views also künstlich nach oben treibt. Hinzu kommt sicherlich die verschenkte Performance durch das Laden von etwas, das niemand sieht.)

Einblendung nach Browserbreite

De einzige Größe die sicher darüber entscheiden kann, ob ein Element gerade geladen werden soll oder nicht, ist die Browserbreite. Die Vorbereitung des entsprechenden Inhaltes beginnt im PHP-Quellcode. Nun gibt es aber in PHP meines Wissens nach keine direkte Möglichkeit, die Browserbreite abzufragen, denn PHP läuft auf dem Server und der weiß noch nicht, wohin das Ganze geliefert wird.

Die Kommunikation zwischen PHP auf dem Server und HTML im Browser geht normalerweise nur in eine Richtung. Ich brauchte jetzt einen Weg, wie ich die Browserbreite in die andere Richtung senden kann. Dieser schien nicht an JavaScript vorbei zu kommen.

Nachdem ich mir ein paar Möglichkeiten angeschaut habe, bin ich schließlich darauf gekommen, dass ich einfach per JavaScript einen Cookie mit der Browserbreite setzen kann. Sobald gesetzt, wird dieser mit PHP ausgelesen. Ist kein Wert bekannt, wird wp_is_mobile() als fallback verwendet.

Der Cookie wird übrigens bei jedem Seitenaufruf überprüft. Bisher habe ich dabei keine Performanceprobleme erlebt. Mit JavaScript ist es ebenfalls möglich, Veränderungen der Browserbreite zu überprüfen, wenn der Besucher z.B. sein Browserfenster verkleinert, dann wird der Inhalt beim nächsten Seitenaufruf entsprechend angepasst.

Dieser Ansatz ermöglicht es mir, Inhalte nach Browserbreite zu schalten und z.B. für einen Anzeigenplatz 3 oder mehr verschiedengroße Anzeigen auszuliefern. Die ersten Tests zeigen, dass sich der Aufwand gelohnt hat. Noch gibt es das entsprechende WordPress Plugin nur lokal bei mir bzw. läuft es auf zwei meiner weiteren Seiten. Dabei fehlt noch generell eine Benutzeroberfläche. Diese kann ich hoffentlich in den nächsten Monaten hinzufügen und die Lösung dann auch anderen zur Verfügung stellen. Weitere Artikel hier im Blog werden dann wahrscheinlich auf Einzelaspekte und Einsatzmöglichkeiten eingehen.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.