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 🚀

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.

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

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:

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!