28. Dezember 2016

GST039 - Handgeklöppeltes HTML

Audio herunterladen: MP3 | AAC | OGG | OPUS

Phoenix ist ein von Railsentwicklern in Elixir programmiertes Framework http://www.phoenixframework.org/
läuft auf BEAM (Virtuelle Maschine von Erlang)
"10x schneller als Rails"
- Exkurs: typische Probleme in Railsprojekten:
- Railskonventionen werden nicht konsequent genug umgesetzt
- häufig Zoo an Tools (Memcache, Queue....) in größeren Railsprojekten
- Deployment
Phoenix ist weniger stringent als Rails z.B. bei Namenskonventionen
kontinuierliches Deployment ist einfach: self-contained Packages werden erzeugt
kein Allheilmittel: mit einem schlagkräftigen Team von Rails-Entwicklern und Hardware kann man auch gute Software entwickeln
Verfügbarkeit Rails-Entwickler vs. Phoenix-Entwickler
Rails ist nach wie vor nett (ActiveRecord, Scaffolding, schnelles Prototyping mit SQLite)
Einstieg in Phoenix kann noch einfacher werden
Tipp zum Scaffolding in Rails: nutzen, aber Templates anpassen. Bringt Geschwindigkeit, für Knowhow-Transfer, um Fehler zu vermeiden

Stefans Schwerpunkt ist Backend/Webperformance
trifft oft auf Cache-Probleme
Moderner Browser macht beim Tippen von URL bereits DNS-Lookup und ggf. wird TCP-Verbindung geöffnet
TCP startet mit kleinen Datenmengen, die bei erfolgreicher Zustellung exponentiell anwachsen ("slow-start Algorithmus", https://en.wikipedia.org/wiki/TCP_congestion_control#Slow_start)
Durchschnittliche Website hat heute eine Größe von 2 MB (https://www.wired.com/2016/04/average-webpage-now-size-original-doom/)
Ping Deutschland <> Sidney = 1 Sekunde, Ping nach USA 200 - 300 ms
Seite sollte < 2 Sekunden brauchen, 1 Sekunde ist Goldklasse, 1 Sekunde schnellere Website => 5 Prozent bessere Conversion
Tracking-Pixel/Scripts bremsen Seiten aus
Performance-Probleme durch Twitter Bootstrap mit jQuery
Zu technischen Herausforderungen beim Performancetuning kommen häufig "politische" Probleme (z.B. Gesichtsverlust bei anderen Abteilungen, wenn man Probleme zugibt)

Stefans Tipps für mehr Performance (00:59:14)

http://www.webpagetest.org/ ausprobieren
Buch von Ilya Grigorik lesen, gibt es auch klassisch als Buch https://hpbn.co/
Mit https://kraken.io/ alle Bilder optimieren
aktuell wird häufig HTTP/2 eingesetzt, funktioniert aber de facto nicht. Grund: Chrome akzeptiert HTTP/2 von Debian und anderen Distributionen nicht (wegen verwendete Kryptobibliotheken). Lösung: Backport benutzen.
mod_pagespeed für Apache analysiert Content und generiert optimierten Content (z.B. Minifizierung, Bilder resizen) - Ansatz hat für Stefan nicht funktioniert: https://developers.google.com/speed/pagespeed/module/
nur das CSS laden, das man auch wirklich braucht
Google schickt Header von Ergebnisseiten los, bevor Server Ergebnisse generiert hat, Ergebnisse werden übertragen, sobald sie fertig sind.

https://www.vutuv.de/
Mission: "Xing & LinkedIn in Gut"
Ziel: soll auch mit geringer Bandbreite/teurem Internetzugang funktionieren - unter 28k Datenvolumen für "above the fold"
"above the fold" soll so schnell wie möglich sein ("above the fold" = Titelbild der Zeitung oberhalb des Knicks)
Hintergrund für "Schmalspuransatz": z.B. in Simbabwe kostet ein LinkedIn-Profil-Aufruf mehr als 50 Cent
benutzt kein JavaScript und kein CSS-Framework
HTML-Code wird ebenfalls auf Kompression hin optimiert (!)
verwendet Phoenix (siehe oben)
Bilder werden für "above the fold" als base64-String eingebettet, um TCP-Slow-Start-Pakete optimal auszunutzen
Vutuv ist jetzt Teil von Free Basics von Facebook - Programm, das 1 Milliarde Menschen kostenlosen Zugang zu grundlegenden Diensten für Entwicklungsländer (https://developers.facebook.com/docs/internet-org)
Code ist open-source (https://github.com/vutuv/vutuv) unter MIT-Lizenz
Pull Requests sind willkommen