In der dieswöchigen Zusammenfassung geht es darum, wie Apple Web Components einsetzt, wie Instagram Skripte sofort lädt und ein paar Gedanken zum Selbsthosten kritischer Ressourcen.
Apple setzt Web Components ein, die mit Stencil erstellt wurden
Die neue Apple Music Web-App (Beta) verwendet ein JavaScript-Framework (Ember.js), aber auch Standard-Web-Komponenten wie <apple-music-video-player></apple-music-video-player>, die mit Stencil, einem Compiler für Web-Komponenten, erstellt wurden.
Stencil ist ein Build-Tool, das Standard-Web-Komponenten mit minimalem Overhead generiert und Kernfunktionen wie Templating, Zustandsverwaltung und Routing sowie Leistungsfunktionen wie Code-Splitting und Lazy-Loading bietet.
Apple hat fast 50 Web-Komponenten in Produktion gebracht, die eine wichtige App antreiben, auf die ein erhebliches Umsatz- und strategischer Wert entfällt. Man kann nicht mehr mit gerader Miene sagen, dass "niemand Web-Komponenten verwendet" oder dass sie "Probleme lösen, die nicht existieren oder bereits besser im Userland gelöst wurden".
(via Max Lynch)
Instagram nutzt Chunked Transfer Encoding und Progressive HTML-Rendering
Instagrams Website verwendet HTTP Chunked Transfer Encoding, um den Inhalt des HTML-Dokuments an den Browser zu streamen, sobald jeder Teil der Seite auf dem Server generiert wird.
Wir können den HTML-
-Code fast sofort an den Browser senden … Dies ermöglicht es dem Browser, mit dem Herunterladen von Skripten und Stylesheets zu beginnen, während der Server mit der Generierung der dynamischen Daten im Rest der Seite beschäftigt ist.
Sie verwenden diese Technik auch, um JSON-Daten in <script>-Elementen an die Seite zu senden. Das Client-Skript wartet auf diese Daten (mithilfe von Promise), anstatt sie über XHR anzufordern.
(via Glenn Conner)
Erwägen Sie das Selbsthosting Ihrer kritischen Ressourcen
Ein Abschnitt der Website der University of Notre Dame lud früher jQuery von Googles CDN, was zu sehr langen Ladezeiten (über 100 Sekunden) führen konnte, wenn die Website von China aus besucht wurde. Dieses Problem wurde durch das Selbsthosting von jQuery behoben.
(via Erik Runyon)
Lesen Sie noch mehr Nachrichten in meiner wöchentlichen Sonntagsausgabe. Besuchen Sie webplatform.news für weitere Informationen.
Ist es nicht wahrscheinlicher, dass Google in China blockiert wird? Diese lange Vorlaufzeit könnte ein Ladefehler sein. 90 Sekunden scheinen ein Standard-Timeout zu sein.
Ich habe tatsächlich ein wenig gegoogelt… https://edjiang.com/how-googles-cdn-prevents-your-site-from-loading-in-china-67504845cd04
Vielleicht könnten Browser erkennen, dass die Anfrage aufgrund von Zensur nicht durchgeht, und Maßnahmen ergreifen, um zu verhindern, dass das Rendering so lange blockiert wird. Oder sie könnten unterschiedliche Timeouts haben, je nachdem, ob die Ressource Render-blocking ist.
Dass die gesamte Seite über 90 Sekunden lang nicht gerendert wird, weil ein einzelnes Skript vom ISP blockiert wird, ist etwas, wogegen Browser wahrscheinlich irgendwie absichern sollten.
Nicht alle Ressourcen von Google werden in China blockiert. Aber ich würde annehmen, dass sie überwacht wurden. Wenn es blockiert wäre, würde es niemals geladen werden und eine 404-Fehlermeldung usw. ausgeben.