Artwork

Inhalt bereitgestellt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Player FM - Podcast-App
Gehen Sie mit der App Player FM offline!

GST039 - Handgeklöppeltes HTML

1:58:38
 
Teilen
 

Manage episode 230257828 series 2497287
Inhalt bereitgestellt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Wir sprachen mit Stefan Wintermeyer über Ruby/Rails, Phoenix und Webperformance.

Stefan Wintermeyer (00:00:00)

Phoenix und/oder Rails (00:04:00)

  • 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

Wenn die Website lahmt: Webperformance (00:40:40)

  • 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.

Vutuv: die Alternative zu Xing und LinkedIn (01:17:30)

  • 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
  continue reading

Kapitel

1. Stefan Wintermeyer (00:00:00)

2. Phoenix und/oder Rails (00:04:00)

3. Wenn die Website lahmt: Webperformance (00:40:40)

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

5. Vutuv: die Alternative zu Xing und LinkedIn (01:17:30)

42 Episoden

Artwork
iconTeilen
 
Manage episode 230257828 series 2497287
Inhalt bereitgestellt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Wir sprachen mit Stefan Wintermeyer über Ruby/Rails, Phoenix und Webperformance.

Stefan Wintermeyer (00:00:00)

Phoenix und/oder Rails (00:04:00)

  • 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

Wenn die Website lahmt: Webperformance (00:40:40)

  • 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.

Vutuv: die Alternative zu Xing und LinkedIn (01:17:30)

  • 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
  continue reading

Kapitel

1. Stefan Wintermeyer (00:00:00)

2. Phoenix und/oder Rails (00:04:00)

3. Wenn die Website lahmt: Webperformance (00:40:40)

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

5. Vutuv: die Alternative zu Xing und LinkedIn (01:17:30)

42 Episoden

Alle Folgen

×
 
Loading …

Willkommen auf Player FM!

Player FM scannt gerade das Web nach Podcasts mit hoher Qualität, die du genießen kannst. Es ist die beste Podcast-App und funktioniert auf Android, iPhone und im Web. Melde dich an, um Abos geräteübergreifend zu synchronisieren.

 

Kurzanleitung