Nachdem mir am ersten Tag das Play Framework vorgestellt, Dank des Vortrages von Wesley Hales Lust auf HTML5 und JS gemacht wurde und wir zwischendurch erfahren konnten, dass auch Antwerpen unter der Woche ein Nachtleben hat, habe ich mir am zweiten Tag einen Vortrag zum Java Social JSR und dazu, wie man Webseiten schneller macht, angeschaut. Was ich dabei lernte, wird in dem folgenden Blogbeitrag vorgestellt.

Java Social JSR, it’s alive

Im Vortrag wurde von Antoine Sabot-Durand und Werner Keil eine Implementierung des Java Social JSR vorgestellt – Agorava. Mir selbst stellte sich dabei sofort die Frage, warum ich einen JSR dafür brauche. Social Media-Dienste stellen in der Regel eine schöne REST und JSON API zur Verfügung. Daher kommt natürlich die Frage auf, wozu ein Java Social JSR?

Ziel ist, generische Services für Social Media bereitzustellen, die ermöglichen, sich gegen den Dienst zu identifizieren und Nachrichten zu posten. Die aktuelle Implementierung unterstützt dabei Facebook, Twitter und Linkedin. Zusätzlich dazu wird mit dem SocialMediaXModel eine API zur Verfügung gestellt, mit der man eigene Social-Media-Dienste anbinden kann. Die Entwickler planen auch eine Anbindung von Github, Stackoverflow und Foursquare.

Präsentiert wurde die Implementierung am Besipiel Socializer, das es z.B. ermöglicht, sich mit mehreren Twitter-Accounts und Facebook gleichzeitig anzumelden. Interessant ist auch, dass sie mit ihrer API nicht das Ziel verfolgen, ein neues TweetDeck oder einen Social Media-Client zu Implementieren – es geht ihnen in erster Linie um die Verbreitung von Daten.

Mit dem SocialMediaApiHub ermöglichen sie generische Funktionalitäten über verschiedene Social-Media-Dienste hinweg. Dies wird durch mehrere Sessions erreicht.

Okay, das war der erste Teil der dreistündigen Session. Im zweiten Teil wurde es sehr technisch, und anhand von Klassendiagrammen und Code Snippets wurde auf die Implementierung der java social api eingegangen. Ja, das ist vielleicht nicht das, was man erwartet, wenn man in eine Session dazu geht, aber für mich als alten CDI-Freund war es ein schönes Praxisbeispiel, wie man die Werkzeuge von CDI in der Praxis einsetzen kann. Nebenbei haben sie auch die Funktionalität genutzt, sich eine eigene CDI-Extension zu schreiben.

Faster Websites: Crash Course on Frontend Performance

Was Ilya Grigorik in diesem Slot veranstaltete, war wirklich großes Kino. Und ich sage das als jemand, der nicht zu den Google-Fanboys gehört.

Was machte den Vortrag so außergewöhnlich? Die Herangehensweise. Ilya hatte den Vortrag in drei Teile aufgeteilt:

1. The problem
2. Browser architecture and the hood
3. Best practices with context

Zunächst ging er auf das (in vielen Vorträgen zu diesem Thema) erwähnte Web Search Delay Experiment ein. Hier wurden Webseiten von Amazon, Google etc. bewusst verlangsamt, um zu ermitteln, ab wann das Ganze den Nutzer nervt. Fakt dazu, man sollte unter 250ms bleiben, damit der Nutzer etwas als schnell empfindet. Alles, was länger als eine Sekunde dauert, führt beim Nutzer zum Kontextwechsel.

Kann ich damit nun zum Fachbereich rennen und sagen, wir brauchen Unmassen an Geld, um unsere Webseite schneller zu machen? Nein. Ähnlich dem Ansatz den Wesley Hales und auch mein Kollege Olli Ochs fahren, rät Ilya dazu, Web Performance nicht als technische Metrik zu sehen, sondern als Business-Metrik. Performante Webseiten führen zu mehr Umsatz und das muss man dem Fachbereich auch entsprechend verkaufen.

Nachdem man seinen Fachbereich ggf. überzeugt hat, muss man sich dem Problem widmen, warum die eigene Webseite überhaupt langsam ist. In der Regel steigen die üblichen Vorträge jetzt gleich bei Punkt drei von Ilyas Vortrag ein. Im Gegensatz dazu erklärt er den Zuhörern, wie das Web rein technisch funktioniert und wo man zuerst ansetzen sollte, bevor man sich an den auszuliefernden Code wagt.

Nach dem wir gelernt haben, wie das Leben eines HTTP-Requests verläuft, gibt er den ersten Tipp. Der DNS-Provider spielt eine wesentliche Rolle für die Performance einer Webseite – dort allein können schon 300 bis 400 ms verloren gehen.

Einen Ansatz, der auch zur Optimierung beitragen soll, ist das Öffnen von mehreren TCP-Verbindungen. Klingt ja erstmal gut. Interessant ist aber, dass die Verbindungen dank des TCP slow start erst einmal mit geringerer Kapazität aufgemacht werden und sich dann erst langsam hochschrauben. Ergo: offene TCP Verbindungen weiter nutzen und nicht mehrere aufmachen.

Ein konkreter Tipp für diejenigen unter uns die auf ihrem Linux-Server Root-Rechte haben: auf Lunix ab 2.6.33 updaten, dann erhöht sich der CWND (congestion window size) von 3 auf 10.

Ursache des Problems ist also nicht nur die Qualität unserer Webseiten, sondern auch, wie wir sie bereitstellen. Dass auch HTTP dazu beiträgt, dass wir noch ein paar Einschränkungen haben, zeigt er mit der Vorstellung von SPDY und HTTP 2.0.

Aktuell bedienen wir uns u.a. den folgenden Workarounds, um das Web schneller zu machen:

• wir konkatenieren Dateien
• Spriting von Bildern
• Domain sharding
• Ressource inlining

Mit SPDY könnten wir uns den Spaß sparen, doch um gleich frühzeitig ein wenig die Euphorie zu bremsen. SPDY wird aktuell nur von wenigen Browsern unterstützt. Aber auch dafür ist eine Lösung in Sicht.

SPDY macht u.a. Folgendes:

• nutzt nur eine TCP-Verbindung
• ein Request gleicht einem Stream
• Streams werden multiplext
• Streams können priorisiert werden

Mit SPDY können auch aktive Server-Pushs angestoßen werden und Informationen, die immer mitgesendet werden, wie z.B. der Header einer Seite, können gecached werden.

Alles toll, nur schade, dass es nicht von allen Browsern unterstützt wird. Doch eine Lösung ist in Aussicht: SPDY wird als Basis für den neuen HTTP 2.0-Standard genommen. D.h., all das wird kommen; wir müssen uns nur noch ein wenig gedulden.

Was nun die Browser-Architektur angeht, möchte ich hier nicht weiter ausholen. Wer noch mehr dazu wissen möchte, schaut sich am besten die Folien von Ilya zum Vortrag an.

Nachdem dann eine Stunde Werbung für Google Analytics gemacht wurde, kam er zu Punkt Drei seines Vortrages, den best practices für performate Webseiten – und das sind u.a. die folgenden:

• DNS Lookup
• Redirects vermeiden
• Weniger HTTP-Requests
• CDN einsetzen
• GZIP einsetzen
• Bilder optimieren
• Expires Headers nutzen
• ETags hinzufügen
• CSS am Anfang der Seite einbinden
• Skripte asynchron laden, wo möglich
• Skripte am Ende laden
• Minfizieren und Konkatenieren
• Auf 60 Frames per second achten
• PageSpeed Insights nutzen

Fazit

Die zwei Tage der Devoxx University Days haben sich für mich auf jeden Fall gelohnt. Ich habe gelernt, dass Cookies nicht per se böse sind, dass HTML5 und JS nach wie vor rocken, und dass man wie so oft auch beim Thema Web Perfomance unter die Haube schauen muss, um wirklich etwas zu erreichen.

Was die Devoxx angeht, werde ich definitiv versuchen, nächstes Jahr ein Ticket für die ganze Veranstaltung zu ergattern. Hochkarätige Sprecher, aktuelle Java-Themen und Vorträge in Kinosälen haben mich überzeugt.