Artwork

Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen에서 제공하는 콘텐츠입니다. 에피소드, 그래픽, 팟캐스트 설명을 포함한 모든 팟캐스트 콘텐츠는 Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen 또는 해당 팟캐스트 플랫폼 파트너가 직접 업로드하고 제공합니다. 누군가가 귀하의 허락 없이 귀하의 저작물을 사용하고 있다고 생각되는 경우 여기에 설명된 절차를 따르실 수 있습니다 https://ko.player.fm/legal.
Player FM -팟 캐스트 앱
Player FM 앱으로 오프라인으로 전환하세요!

GST039 - Handgeklöppeltes HTML

1:58:38
 
공유
 

Manage episode 230257828 series 2497287
Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen에서 제공하는 콘텐츠입니다. 에피소드, 그래픽, 팟캐스트 설명을 포함한 모든 팟캐스트 콘텐츠는 Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen 또는 해당 팟캐스트 플랫폼 파트너가 직접 업로드하고 제공합니다. 누군가가 귀하의 허락 없이 귀하의 저작물을 사용하고 있다고 생각되는 경우 여기에 설명된 절차를 따르실 수 있습니다 https://ko.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

챕터

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 에피소드

Artwork
icon공유
 
Manage episode 230257828 series 2497287
Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen에서 제공하는 콘텐츠입니다. 에피소드, 그래픽, 팟캐스트 설명을 포함한 모든 팟캐스트 콘텐츠는 Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen 또는 해당 팟캐스트 플랫폼 파트너가 직접 업로드하고 제공합니다. 누군가가 귀하의 허락 없이 귀하의 저작물을 사용하고 있다고 생각되는 경우 여기에 설명된 절차를 따르실 수 있습니다 https://ko.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

챕터

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 에피소드

모든 에피소드

×
 
Loading …

플레이어 FM에 오신것을 환영합니다!

플레이어 FM은 웹에서 고품질 팟캐스트를 검색하여 지금 바로 즐길 수 있도록 합니다. 최고의 팟캐스트 앱이며 Android, iPhone 및 웹에서도 작동합니다. 장치 간 구독 동기화를 위해 가입하세요.

 

빠른 참조 가이드

탐색하는 동안 이 프로그램을 들어보세요.
재생