Schnellere Emoji für WordPress (Mini-Plugin)

Emoji – man hasst sie, oder man liebt sie. Ich persönlich verwende sie gerne. Deswegen ist mir auch aufgefallen, dass sie unter Umständen etwas Hilfe bei ihrer Geschwindigkeit brauchen. Denn nur wenn eine Site mit SSL läuft, laden Emojis in WordPress wirklich so schnell, wie sie können. Hä?! 😯

Für alle, die lieber gleich Code lesen: Emoji Rocket 🚀

Update 03.03.2016

Mit Version 4.4.2 hat WordPress die Emoji-URLs im Core auf HTTPS umgestellt. Der Artikel, sowie der weiter unten verlinkte Plugin-Code behandeln also ein Problem der Vergangenheit.

10mal schnellere Emoji mit SSL

Neulich habe ich mal zum Spaß ein paar Seiten dieses Blogs durch den Pingdom-Test gejagt. Dabei sprang mir eine nicht ganz winzige Verzögerung beim Laden eines Emoji auf meiner Seite ins Auge.

Emoji in WordPress werden, im Unterschied zu den alten Emoticons, nicht aus der Installation direkt, sondern von einer Quelle auf WordPress.org geladen – seit WordPress 4.2.

Ich wiederholte den Test mit der URL des Emoji selbst und sah das hier:

Pingdom-Werte für den Redirect der Emoji-Anfrage von HTTP zu HTTPS: 345ms Verzögerung
Verzögerung aufgrund der Weiterleitung von HTTP zu HTTPS: 345ms
Pingdom-Werte für Emoji von s.w.org, angefordert über HTTP
Pingdom-Werte für Emoji von s.w.org, angefordert über HTTP

Zwei Requests statt einem, und eine ganz hübsche Wartezeit für anderthalb Kilobytes.

Zum Vergleich fragte ich die HTTPS-Quelle direkt an. Das ging natürlich schneller, und zwar knapp zehnmal so schnell:

Pingdom-Werte für Emoji von s.w.org, angefordert über HTTPS
Pingdom-Werte für Emoji von s.w.org, angefordert über HTTPS

Angesichts einer zehnmal schnelleren Ladezeit über SSL, fragen sich Emoji-Fans jetzt natürlich: Wieso druckt WordPress hier überhaupt eine URL mit einfachem HTTP-Protokoll aus? WordPress.org ist afaik komplett verSSLt, warum gibt WordPress hier nicht gleich eine Emoji-URL mit HTTPS aus, damit das Bildchen ganz fix lädt?

Für die Antwort habe ich etwas im Core gebuddelt.

Wieso nur für Sites mit SSL?

Die Emoji-URL kommt über einen Filter, der an mehreren Stellen in wp-includes/formatting.php auftaucht:

apply_filters(
	'emoji_url',
	set_url_scheme( '//s.w.org/images/core/emoji/72x72/' )
)

Diese set_url_scheme(), durch die unsere WordPress.org-URL geschickt wird, macht was ganz Schlaues: Sie prüft, ob meine lokale Site SSL hat. 😳
Wenn ja, setzt sie das HTTPS-Protokoll vor die übergebene URL; wenn nein, verwendet sie HTTP.

Für den Fall der Emoji ist mir diese Logik irgendwie schleierhaft. Wozu muss WordPress wissen, ob meine lokale Site SSL verwendet, wenn die remote URL auf jeden Fall SSL hat?

Wie auch immer, habemus filterem, also lasst uns die URL filtern und verHTTPSen! Noch haben wir ja leider nicht alle SSL am Laufen …

Mini-Plugin für Sites ohne SSL

Eigentlich ist alles ganz klar:

  1. die vom Filter übergebene URL mit einem kleinen Plugin abfangen;
  2. vorne http ab- und https wieder dran schrauben;
  3. manipulierte URL dem Filter zurück geben—voilà!

Bloß (und jetzt wird’s ein bisschen paranoid, zugegeben, aber:) was wenn bei w.org mal das Zertifikat spinnt? HTTPS hat kein natürliches Fallback auf HTTP. Keine Emoji im Katastrophenfall?

Mehr als Fingerübung, denn aus echter Sorge habe ich mal eine Checkung hinzugefügt, ob das SSL unseres Emoji-Spenders wirklich funzt. Das prüfen wir natürlich nicht im Filter selber, sonst würden wir jedesmal, wenn unsere Site irgendwo ein Emoji platziert, eine extra Anfrage an s.w.org senden – und das würden die uns auf Dauer wahrscheinlich verübeln.

Besser: Einmal (1×) nachfragen, und auch höchstens einmal pro Stunde. Das sollte hoffentlich reichen. Transients ahoi!

Der Rest der Geschichte ist Code, genauer gesagt ein Mini-Plugin: Emoji Rocket 🚀. Bitte schön!

4 Antworten zu “Schnellere Emoji für WordPress (Mini-Plugin)

Schreibe einen Kommentar

Kommentieren ist ein Privileg, kein Recht. Sei anständig.

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