Transcript

[0:00] Fetch Priority, das klingt nach Performance, das heißt, dann weiß ich, welcher Konfession man angehören muss, man muss Papst sein, also Performance Papst, eure Heiligkeit, erzählen Sie.
Request Idle Callback, das ist ja so eine API, die gibt es lange, lange, lange schon in Chrome.
Was man da machen kann, ist eben zu sagen, diesen Callback, führ den mal bitte aus, wenn du nichts mehr zu tun hast letztendlich, also wenn deine CPU Last gefallen ist.

[0:28] Music.

[0:55] Liebe Hörer und Hörerinnen, feiert am 07.01.
Von 15 bis 18 Uhr mit uns die 600. Podcast-Episode bei einem einzigartigen Online-Event.
Denn wir veranstalten eine Fishbowl-Diskussion.
Bei einer Fishbowl-Diskussion können einige Teilnehmer und Teilnehmerinnen im Kreis diskutieren, während andere im sogenannten äußeren Kreis zuhören und dann einsteigen können.
Wir freuen uns sehr auf diese interaktive und dynamische Form für einen Austausch zwischen uns Web-Devs.
Meldet euch über den Meetup-Link in den Shownotes an und seid Teil dieses spannenden Formats.
Wir freuen uns schon sehr auf euch und jetzt erstmal viel Spaß bei der folgenden Revision.

Revision 596: Neues in Safari, Teil 1 von 2

https://workingdraft.de/596/

[1:40] Revision 596. Wir sind heute zu zweit.
Da hätten wir einmal den Peter. Moin, moin.

Import Attributes

https://github.com/tc39/proposal-import-attributes

[1:50] Und ich bin der Shep, und das bedeutet, wir haben uns wieder irgendein schönes Dokument, irgendeine sozusagen denkanstoßende Liste gekrallt, an der wir uns entlanghangeln werden und über neue Webplattform-Features, sprechen werden. Ja, genau, die sind ja beim WebKit-Team irgendwann in den letzten Jahren aufgewacht und haben angefangen, Features rauszurendern, wie die Bekloppten.
Und ich finde das Format von denen immer so schön, dass die da in ihrem Blog immer so sagen, hier ist eine neue Version in regelmäßigen Abständen mit einer Liste drin, die zu ihren Issues auch führt, dass es auf GitHub und das ist einfach immer wieder ein super Anlass, um über neues Zeug zu reden.
Ja, genau, und da sind wir jetzt mal durchgegangen, also wir haben uns auch ein bisschen die die Technology Preview Release Notes angeguckt.
Da ist noch das eine oder andere Extra-Stück-Info, rausgepurzelt.

[2:44] Ja, womit wollen wir anfangen? Also, wir können ja einfach so durchgehen.
Im Grunde ist es größtenteils chronologisch, wie es im Blog drin ist.
Bei ein paar Sachen sind, glaub ich, unsere Stichpunkte nicht in der korrekten Reihenfolge. Aber es macht ja nichts.
Ja, vor allem ist es halt ein Browser. Ob's am Ende irgendwer unter der Hörerschaft benutzen kann, hängt ja von mehr als einem Browser-Up, nehm ich mal an, von daher. Ja.
Lass uns halt mal gucken, was es so Lustiges gibt da so in der Welt.
Soll ich anfangen zu quatschen? Ja, fang mal an.
Okay, Importattribute, ganz großartige Sache. Shep, was weißt du über Importattribute?
Ich benutze die nicht. Ich warte auch nicht drauf, dass es die gibt.
Weil meine Projekte einfach das nicht erfordern.
Aber ich glaube, das ist ja diese Annotation bei JavaScript-Imports, mit denen man dann andere File-Formate importieren kann.
Also beispielsweise JSON und ich glaube auch CSS.
Und um das eben überhaupt, also um dem Browser zu sagen, so hey, das ist eben jetzt kein JavaScript-Module.

[3:52] Benutzt man diese Import-Attribute.
Weil die Dateiendung alleine jetzt ja erstmal quasi auch nicht aussagekräftig ist und man dem Browser das eben mitteilen möchte, bevor der Content-Type, Also bevor er die Abfrage macht und dann erst über den Content-Type erfährt, worum es sich handelt.
Ganz genau. Ganz genau so ist das. Also im Prinzip kennt man das ja aus den Bundlern, aus WebKit und Konsorten.
Da konnte man ja schon immer Dinge importieren, die kein JavaScript waren, mit Import, Require, was auch immer.
Und dann hat der Bundler dafür gesorgt, dass die Dinge dann zur Kompilzeit als JSON oder CSS oder ähnliches interpretiert wurden.
Und das kann dann halt eben jetzt mit diesem Proposal Proposal für die Import-Attribute.

[4:34] Tatsächlich auch dann der Browser nativ.
Das ist jetzt sagen wir mal, wieder sehr kompliziert.
Wir erinnern uns ja sowieso generell an die Einführung von ECMAScript-Modulen, im Browser, wo es ja das Problem gab, okay, der Browser ist die eine Umgebung, wo die Module auf die eine Weise geladen werden müssen.
Module in Node.js haben ganz andere Anforderungen und dann gibt es ja diese seltsame Konstruktion, dass die da wieder im Prinzip die ECMAScript-Spezifikation, definieren, wie es High-Level-mäßig aussieht, was die Syntax ist und so die grobe Semantik, aber irgendwelche Lademechaniken und ähnliches, bleiben da außen vor.
Und das wird natürlich nicht einfacher, wenn du halt auch noch so Dinge einfügst wie unterschiedliche, sagen wir mal, Dateitypen, wo du irgendwie erwarten würdest, okay, JSON ist mehr oder minder universell, aber sowas wie CSS hat ja im Browser eine, sagen wir mal, große Bekanntheit, eine feste Bedeutung, jeder Browser kann das.
Aber wenn ich jetzt irgendwie so Node und BUN und Konsorten frage, haben die ja ein ganz ein ganz anderes Verhältnis zu CSS.

[5:26] Das heißt, da die einzelnen MIME-Types über JSON hinausgehen, was mit Sicherheit der Wichtigste ist, aber das sich irgendwie zu erarbeiten und da auch einen Umgang mit zu finden, ist sicherlich noch eine spannende Sache und deswegen ist das auch schon länger in der Mache und da wird länger drauf rumgekaut.
Nur, so langsam kommen halt die ersten Implementierungen.
Ja, ich find diese Import-Statements, also so jetzt so als kleine persönliche Meinungsäußerung, ich find die ja irgendwie sehr anstrengend, wie die so strukturiert sind.
Ich find auch, glaub ich, blöd, ich glaub, bei CommonJS ist das ja umgedreht, dass quasi der ...
Da sagst du ja, glaub ich, erst du importierst das, und dann bietet der Browser dir an, welche Exports da drin sind. Ich meine, so rum war's.

[6:09] Und bei Import geht das nicht, war das so?
Also, Covenger-S ist ja irgendwie mehr oder minder so ein Function Call, Require, was auch immer, und dann kriegst du ja dein Objekt oder was immer dein Export ist, daraus, das kannst du ja gegebenenfalls destructuren.
Und das ist ja bei den Import-Statements so anders nicht.
Es steht halt dann am Anfang statt Const ein Import, und dein Structuring ist mehr oder minder obligatorisch, und dann kommt der Pfad halt nach einem Keyword statt als String in einem Function Call.
So groß ist der Unterschied ja eigentlich nicht. Ja, ich kann das jetzt auch gar nicht mehr genau sagen. Irgendwie eine der beiden.
Ich dachte immer, die Import-Syntax, die nervt mich ein bisschen, weil die eben sozusagen falsch rum ist vom Gefühl her.
Also der Browser mir weniger vorschlagen kann, weil er erst zu spät erfährt, was ich überhaupt will.
Ja, klar, die Import-Syntax ist ganz gruselig, aber das ist halt auch ein Kind der Vergangenheit.
Man müsste dann irgendwann die ganzen Use-Cases aus AMD und CommonJS und ähnlichem Krempel unter einen Hut bringen und dann ist das, was da rauskommt, notwendigerweise viel zu kompliziert, klar? Ja.

[7:15] Aber ist halt eben so, hey, das ist aber nicht wirklich der Funfact über die Importattribute. Aha. Sondern? Ja.
Safari ist nicht der einzige, der das shippt, sondern ... Ah, ja, ich erinnere mich.
Ich war ja letztens bei dir in Essen bei dem Webworkern Ruhe. Genau.
Genau. Es kommt ... Ich erinnere mich. Genau, genau. Also, die Geschichte ist die, Chrome shippt das schon länger.
Und das Problem ist, die haben halt ein früheres Proposal geschippt.
Die Syntax jetzt ist, import irgendwas von irgendwas anderes.
Dann kommt die Syntaxergänzung. Man nimmt das with-Keyword, das jetzt ja nicht mehr in Modulen vom with-Statement besetzt ist, denn das with-Statement ist ja im StrictMode, also in Modulen, verboten. Also ist das Keyword frei geworden.
Das besetzt man jetzt. Sagt also, import irgendwas von Dateipfad, with, und dann kommt da eine Annotation hinter, die das Dateiformat beschreibt.
Und das würde im Fall von Jason einfach bedeuten, with in Schweifklammern, Type, Doppelpunkt, Jason, Schweifklammer zu.

[8:14] Und das Schöne mit Chrome ist, als sie es geschippt haben, haben sie halt noch eine ältere Version der Spezifikationen verwendet, wo das Ding nicht Import Attributes hieß, sondern Import Assertions, und das Keyword nach dem normalen Modulimport war nicht With, sondern Assert.
Und jetzt hat sich die Spezifikation geändert, in Chrome ist das Zeug aber schon so lange geschippt, und es gibt einen nicht-insignifikanten Teil von Webseiten, die das schon benutzen.
Und jetzt werden sie sich halt eben in der Situation wiederfinden, Das ist jedenfalls Stand der Diskussion, der entsprechende Issue ist in den Shownotes verlinkt.
Dass sie sozusagen mit einem Feature, das noch gar nicht fertig ist, das befindet sich jetzt in Stage 3 und einige Mutige, also Safari und Chrome, shitten das jetzt, aber sie haben bereits jetzt ein Legacy-Problem, weil sie halt diese Assert-Syntax in die Welt getragen haben und werden wahrscheinlich bis ans Ende aller Tage das Assert-Keyword als Alias für das With-Keyword in dieser Modul-Attributsyntax.

[9:09] Weiter supporten müssen. Was ich ja ganz ganz großartig finde, als Beispiel für, wie sehr man den Geist bei Webstandards einfach nicht wieder in die Flasche zurückbekommt.

[9:20] Ja, wobei, ich glaub, das Chrome-Team, das hat ja so für sich bestimmte Metriken, dass, also so, wenn unter so und so viel Prozent von Webseiten irgendwas benutzen, dann ist es okay, auch was zu deprecaten.
Das haben die auch schon gemacht. Aber wahrscheinlich ist die Prozentzahl einfach zu hoch, ja.
Ja, man muss ja bedenken, wenn du Chrome bist, ist Prozent deiner Nutzerschaft, egal wie viele Nulls nach dem Komma noch kommen, bevor eine Nichtnull kommt, immer noch sehr, sehr viel.
Und speziell jetzt bei Chrome, das beinhaltet ja alles Mögliche, Chrome-spezifische Apps, möglicherweise irgendwelche andere Krempel, der sozusagen Chromium einfach mitschippt, so was elektronenmäßig ist.
Also das ist ja endlos viel, was ja auch für die teilweise äußerst schwer wahrzunehmen ist.
Also was immer die ja messen, an aktiven Nutzern, ist ja wirklich so ein unteres Limit und nicht irgendwie eine realistische Schätzung oder gar ein oberes Limit.
Und was hätte dagegen gesprochen, ist einfach bei dann sozusagen, wissend, dass das eben so ist, also analog zu hier den Mootools-Fails und der Reaktion darauf, eben zu sagen, okay, dann lass uns einfach bei Assert bleiben.
Also warum haben die das nicht gemacht?
Daran erinnere ich mich jetzt grade nicht genau, was das war.

[10:37] La la la, scroll. Linz. Ich erinnere mich grad nicht, was die Motivation für den Wechsel war.
Andererseits, ich meine, wir reden davon, dass das damals halt irgendwie so Stage 2 war. Und in Stage 2 ist halt die Sündschaks einfach mal nicht festgenagelt, sondern wirklich nur eine Diskussionsgrundlage.

[10:54] Insofern, ja, wäre es halt irgendwie sozusagen auch falsch, zu einem Zeitpunkt, was wie Sündschaks nicht festgenagelt ist.
Sagen wir mal so, ist halt so ein bisschen, wenn ich jetzt wirklich Spezifikationsschreiberin bin, ist das ja wirklich deren Problem.
Möglicherweise habe ich halt eben, kriege ich meinen Paycheck von Google, Okay, sicherlich.
Aber andererseits arbeite ich mich jetzt hier durch diesen Prozess durch, der ja wohl definiert ist und der ja auch so mit gutem Grund ist, wie er ist.
Ja, ein bisschen ist das so. Es würde sozusagen das Verhalten belohnen.
Wer immer zuerst was shippt durch die normative Kraft des Faktischen, schafft halt dann die Standards.
Was halt zu einem gewissen Grad irgendwie so ist, aber sonst auch echt ein bisschen ... Also, ganz so einfach ist es ja nicht.
Ich habe letztens mal probiert, tatsächlich, ich mache jetzt nächste Woche einen Workshop, wo ich so auf so einer Java-Konferenz bin und ich mir so die zum Ziel gesetzt habe, ich will so, ich habe das so ein Zero-to-Hero-Workshop genannt.

[11:48] Wo ich wirklich so die ganzen Backendler mal wirklich so up to speed bringen möchte und ich habe überlegt, was ist der sinnvollste Ansatz dafür und du könntest natürlich einfach mit denen hingehen und sagen, hier das ist Next.js, das ist React, das ist so der kürzeste, direkteste Weg für dich eine moderne Web-App zu bauen.
Und ich dachte mir, wäre ja eigentlich viel spannender, sozusagen zu erklären, warum man überhaupt bei so was wie Next.js und React landet.
Man kann das ja finden, wie man will, aber es ist ja sozusagen eine Abfolge von Überlegungen und Entscheidungen, die einen von HTML-Seite mit ein bisschen Skript und ein bisschen CSS dahinführen.
Und sozusagen diesen Weg einfach mal zu skizzieren und zu erzählen, warum die Welt sich in der Konfiguration befindet, wo man so eine Webseite baut, ist ja vielleicht der wertvollere Ansatz.
Und deswegen mache ich das so. Und zu dem Zweck habe ich mal probiert, mir so im Prinzip so Web-Technologie so quasi wie einen Staatsaufbau vorzustellen.

[12:38] Also wer macht die Gesetze, wer hat Vorschlagsrecht, Veto-Recht und so Gedöns.
Und hab halt dann mal versucht, so ein ähnliches Ding, wie man das ja aus Schulbüchern und Ähnlichem kennt, mal versuchen so aufzumalen.
Und es ist halt wirklich irgendwie so ein komisches Hybrid-Regime, wo irgendwie alles so ein bisschen reinregiert und so.
Aber du hast halt alle möglichen, sagen wir mal, Mächte, die da irgendwie so reinwirken.
Halt eben Browser einerseits, Standards andererseits, aber du kannst halt eben auch Mutools programmieren und dann sagen, hier so, jetzt bin ich hier mein kleiner Fürst und hab dir mal so gesagt, wo es lang geht oder wo es definitiv nicht lang geht.

[13:13] Und deswegen ist das halt immer so, glaube ich, auch einfach nicht sinnvoll, darüber so klar nachzudenken, irgendwie so, warum hat man es nicht anders gemacht?
Naja, weil sich halt eben sozusagen die Kräfte zu diesem Zeitpunkt, und als die Entscheidung getroffen wurde, in einer Konfiguration befanden, wo das nicht stattgefunden hat.
Deal with it, weil der Geist geht eh nicht wieder in die Flasche.
Abputzen, weitermachen, würde ich sagen. Ja. Aber ist ein guter Ansatz.
Also, ich bin gespannt. Vielleicht kannst du da noch mal in einer zukünftigen Episode ein wenig erzählen, wie du das sozusagen, diese Geschichte ausrollst.
Oh, ich bin auch sehr gespannt, wie ich die ausrollen werde.
Weil ich hab die ja im Prinzip im Kopf.
Und ich werd die nicht in Slides verpacken, dann wird das bloß zu langweilig.
Ich glaub, ich mach das, was ich bei solchen Beispielen immer mache, nämlich ich bau halt einfach ne Webseite mit nem Suchformular drin.
Und daran kannst du ja alles entlang erzählen. Dann hast du ja, so, HTML und Semantik kannst du daran erzählen, Barrierefreiheit kannst du daran erzählen, Styling kannst du daran erzählen, Herausforderungen von Styling kannst du daran erzählen, also, warum kann ich den Button nicht in die richtige Schrift versetzen? Ja, okay, geht, nicht ganz so einfach.
Und das kannst du dann ja auch mit React bauen, das kannst du dann serverseitig rendern, das kannst du dann mit einem relativ simplen Bildprozess ja auch machen.
So viel Next.js krieg ich auch noch hin, dass ich das damit rausrendere.
Und du kannst es sozusagen einfach immer so durchmutieren und jeden Folgeschritt mit einer vorherigen Geschichte so motivieren.
Und das heißt, ich glaub, ich mach halt irgendwie so zehn Slides mit meinen wichtigsten Bildern, unter anderem halt eben diesem Schaubild.
Und der Rest wird gelivecoded, und dann schauen wir mal.

[14:41] Ja, naja, es liegt halt, ich würde sagen, es ist ja auch viel einfach, dass das.

[14:49] Ja, Leute ankamen, Dinge noch irgendwie in einer gewissen Art und Weise verbessert haben gegenüber dem, wie vorher Webseiten gebaut wurden.
Und diese Dinge ja dann sozusagen fester Bestandteil, also quasi feste Grundanforderungen dann werden mit der Zeit, dass man das, also das auf jeden Fall in der Art und Weise haben möchte.
Und so steigert sich dann natürlich, steigen sich die Ansprüche und die Komplexität.
Und dann irgendwann kann man gar nicht umhin, als eben Schützenhilfe in ...
Ja, Frameworks und Tools zu suchen.
Na ja, oder du integrierst das halt in deine Realität rein. Weil ab einem gewissen Punkt, einem gewissen Abstraktionslevel spielen die Dinge auch jenseits von Tools keine Rolle mehr.
Also, du hast ja wirklich teilweise absolute Konstruktionen da im Browser.
Aber wenn's dann wirklich hart auf hart kommt und du ein Problem lösen willst, spielt das wirklich eine Rolle.
Also ich fühle mich da ja immer so erinnert an, ich habe ja nichts mit Computern gelernt, ich habe ja Geschichte und Film studiert und da erinnere ich mich natürlich an das Heilige Römische Reich und das Fürstbistum Osnabrück, wo irgendwie so 30-jähriger, Krieg war und die Katholen und die Evangelen haben sich gegenseitig die Hölle heiß gemacht und dann hat man sich beim westfälischen Frieden dann irgendwie darauf geeinigt, wie es jetzt läuft und hat dann halt irgendwie so aufgeteilt hier die Katholen, da die Evangelen, Blakicks.

[16:02] Und man hat teilweise auch absurde Situationen sich gebastelt, wie irgendwie im Fürstbistum Osnabrück, wo, wenn ich mich recht erinnere, das einfach so geregelt wurde, dass man sie nicht einigen konnte. Was wird es denn jetzt?
Und dann haben sie einfach das durchgewechselt. Dann ist halt der Chef so lange Kartone, bis einer abtritt und dann kommt dann halt ein anderer hin und dann wechseln die halt so durch.
Was halt irgendwie schon ein relativ absurdes Implementierungsdetail ist.
Andererseits, wenn du da der Nachbar von dem Laden bist und du willst da irgendwie einfach mit denen ein Deal machen, warum auch immer, ist dir ja das Detail letztlich egal, sondern da sitzt halt einer, der hat was zu melden und dann verhandelst und findest dich damit ab.
Dann ist es mal einfacher, mal schwieriger, je nachdem, welchem Team du jetzt so angehörst. Aber es ist nicht so wichtig, warum das so ist, sondern es ist eben so.
Dann findest du dich damit ab. So sehe ich sehr viele von diesen Macken in Webstandards drin.
Shep, fühlst du dich in deinem JavaScript-Alltag von Null und Undefined, was ja wirklich so das Fürstbistum Osnabrück von JavaScript ist, fühlst du dich davon irritiert oder ist das in dich reinintegriert?
Das ist in mich reinintegriert. Und, na ja, genau, es ist halt einfach viel so, ist so, okay, wundert mich jetzt einfach nicht mehr, weitermachen.
Genau, so. Und genau da werden wir halt eben auch landen mit vielen, vielen anderen Sachen.
Einziger Unterschied ist halt eben, da kann man sich halt wunderbar drüber lustig machen, wenn man so was hat wie eben unser Meetup da letzte Woche.

[17:25] Okay, nächster Punkt, Fetch Priority.

Priority Hints

https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchPriority

[17:30] Fetch Priority, das klingt nach Performance, das heißt, dann weiß ich, welcher Konfession man angehören muss.
Man muss Papst sein, also Performance-Papst. Performance-Papst, genau.
Fetch Priority, denke ich, sollten alle kennen.
Haben wir auch schon ein paar Mal besprochen. Der Browser hat halt intern eine Prioritäten-Reihenfolge, wie er bestimmte Typen von Ressourcen abfrühstückt. Und wenn man eben da ein wenig micro-manage-end Einfluss nehmen möchte drauf, zum Beispiel das Hero-Build hoch priorisieren und andere Bilder auf der Seite, die nicht lazy sind, aber halt trotzdem nicht so wichtig, dann runter priorisieren möchte, dann ist Fetch Priority als HTML-Attribut oder auch als Fetch-Option, das Mittel der Wahl.

[18:28] Okay, ich bin sicher, ich hätte dich das schon mal gefragt. Gibt es da nicht, wenn ich mir das so vorstelle, und ich setze da irgendjemanden dran, der oder die nicht so wahnsinnig viel Plan hat.
Oder man wird von jemandem durch die Gegend kommandiert, der oder die nicht so wahnsinnig viel Plan hat.
Ist da nicht die Gefahr des Anwenderfehlers relativ hoch?
Ja, ja, doch. Genauso am besten ist also so ein bisschen, das ist ja so ein bisschen wie mit Aria.
Also die erste Regel von Aria ist benutze kein Aria.
Und so ist das hier auch. Also die Browser sind ja schon, die haben ja schon gute Gründe, warum sie bestimmte Ressourcen mit bestimmten Prioritäten laden.
Und am Ende ist der Outcome eigentlich immer der ideale.
Aber, genau, manchmal gibt es eben Personen, die das anders sehen.
Und dann kann man da noch ein bisschen feintunen. Aber wenn man jetzt zum Beispiel hingeht und auf alles Fetch Priority High setzen würde, dann wäre am Ende eben so ...
Dann würde nichts mehr priorisiert geladen.

[19:37] Ich glaub, weniger schlimm ist es, wenn man die Fetch Priority runtersetzt.
Ich glaub, das ist dann weniger destruktiv.
Genau, also das sollte man eben dann wirklich sehr, sehr, sehr, ähm, begrenzt einsetzen. Also ...
Ich würde jetzt sagen, also am allermeisten Sinn macht es halt wirklich für das Hero-Build.

[19:59] Weil das eben einzahlt auf Largest Contentful Paint und das ist eben ein Core Web Vital und das ist dann SEO-relevant und das ist eben dann deswegen ein Ding, wo SEO und Geschäftsführung die ganze Zeit auf die Füße treten.

[20:17] Bei der Fetch-API, da wüsste ich jetzt ehrlich gesagt nicht, warum ich das da benutzen wollte, auch wenn das da unterstützt wird.
Also fällt mir jetzt kein Newscase ein, aber es geht.
Naja, also ich meine, du musst ja deine API-Calls nicht mit GraphQL sozusagen zentralisiert abwickeln, sondern ich erinnere mich an eine Zeit, als die Zukunft dezentral war.
Also würdest du vielleicht sieben Requests auf einmal losschicken, Wofür ja du als jetzt Frontendler vielleicht auch gar nichts kannst, sondern Backend ist halt so, musst du dich mit abfinden.
Und vielleicht gibt es da ja auch Wichtigere und weniger Wichtige drunter.

[20:53] Ja, vielleicht, aber ich meine, wenn du jetzt chronologisch nach einem unwichtigeren kommst und dann Fetch Priority High machst, dann sind die anderen Requests ja schon raus.
Also genau, du bestimmst ja im Prinzip mit deinem Code, wann Requests rausgehen und wann nicht.
Ja. Und beim Parsen, da sortiert der Browser diese, also der stellt ja diese Reihenfolge zusammen und da würde man mit eben Fetch Priority Einfluss nehmen können und sagen so, hey, vielleicht ist dieses Script hier gar nicht so wichtig, wie du denkst, und dieses Bild ist dann in diesem einen Fall eben wichtiger.
Wir sortieren die, oder ich deklariere das quasi, ich geb dir das Zeichen, dass das eben sozusagen andersrum zu abzuarbeiten ist.
Aber wenn ich den Code schreibe, dann denke ich, dann wird das ja sowieso, also dann hab ich ja quasi schon durch das, welchen Request ich in meinem Script zuerst reinschreibe, dadurch schon die Reihenfolge beeinflusst.
Und der Server wird jetzt nix schneller zurückschicken, nur weil ich Fetch Priority setze, weil das im Endeffekt ja nur eine Browsergeschichte ist.
Ja, aber könnte man sich nicht irgendwie eine Art Framework vorstellen, wo man sozusagen als Nutzerinnen-Nutzer einfach nur sagt, ich deklariere jetzt, diese und jenen Ressourcen zu brauchen.
Und dann gibt's halt irgendwie ein Scheduling-Batching-Mechanismus.

[22:15] Der das dann irgendwie, die Bounds zusammenfasst oder so. Also, ich kann mir Szenarien vorstellen, wo das eine Rolle spielt.
Die Frage ist, ob man in dem Fall selber die Fetch-Priority setzt. Aber nun ja.

[22:27] Da können wir auch an unsere Hörerschaft die Frage weitergeben.
Ich weiß nicht, habt ihr das schon mal benutzt? Und wenn ja, wo?
Also, so ein richtig plausibler Grund fällt mir da jetzt irgendwie nicht ein.
Aber ich hab auch nicht nach einem plausiblen Grund tatsächlich aktiv gesucht.
Also, ich hab das nur so wahrgenommen, dass das eben auch geht in der Fetch-API.
Aber so warum, wieso, keine Ahnung. Ja, ich meine, ich klicke mich jetzt gerade durch die Spezifikationen.
Es ist ja schon, sagen wir mal, konzeptionell der Gestalt, dass Konzepte wie, also so was wie Fetch ist ja irgendwo zentral definiert und andere Spezifikationen beziehen sich darauf, sei es der HTML-Standard oder sei es halt tatsächlich der Standard für die Fetch-API.
Aber die basieren ja darauf. Und sozusagen scheint das ja ein dort an der Fetch-API, sozusagen am Fetch-Konzept angesiedeltes Ding zu sein, das dann auf die anderen runtervererbt wird.
Und das könnte halt tatsächlich auch so zu einem gewissen Grad warum nicht sein.
Es könnte ja auch sein, dass du irgendwie, keine Ahnung, Seite lädt, dein blockierendes Script macht einen Fetch-Request.
Dann spielt das ja sozusagen in der gleichen Liga wie dein Hero-Image.
Und vielleicht ist ja sozusagen dein Ziel, dann den Fetch-Request runterzuregeln.
Das kann ja auch was sein.
Ja, das könnte sein, ja. Gut möglich.

Window.requestIdleCallback()

https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback

[23:42] Genau, dann haben wir Request Idle Callback. Das ist ja so eine API, die gibt's lange, lange, lange schon in Chrome.
Ich dachte, dass es das schon vorher in Safari gegeben hat, aber dem ist nicht so. Ich weiß wohl, dass Chrome lange der einzige Browser war, der das unterstützt hat.
Aber ich dachte, Safari kann das schon. Anscheinend ist das aber nicht der Fall gewesen. Jetzt ist es hinzugefügt worden.
Und genau, was man da machen kann, ist eben zu sagen, hier diesen Callback für den mal bitte aus, wenn deine, wenn du nichts mehr zu tun hast letztendlich, also wenn deine CPU-Last gefallen ist.
Und man kann zusätzlich dann aber auch noch sagen, so, aber wenn du, wenn das innerhalb der nächsten 10 Sekunden oder sowas eben nicht der Fall ist, dann bitte führ das halt trotzdem aus.
Falls man mal irgendwie ein sehr, wenn man so ein schwachbrüstiges Device hat, das eigentlich im Grunde daueraus gelastet ist mit allem, dann würde das ja nie in diesen Idle-Modus gelangen.

[24:48] Genau. Also für so Dinge wie, tja, wann würde man das nutzen?
Für irgendwelche ... äh, semipriorisierte manuelle Clean-up-Logik.
So was in der Richtung. Das sollte also schon irgendwie so alle Zeit mal laufen.
Und wenn's öfter passiert und grad nix Wichtigeres ansteht, kann's auch eher laufen, schadet nicht, so was in der Richtung.
Ja, also, ich rappe da auch manchmal so Third-Party-Skripte rein.

[25:13] Also, dass ich halt quasi sage, die bitte erst mal quasi ...
Dann lad die noch nicht. Kümmer dich erst mal um die wichtigen Dinge.
Und dann, wenn du sozusagen ins Idle reinfällst, dann kannst du die quasi dir reinziehen und dich wieder beschäftigen damit.
Okay, also, wenn ich jetzt die spanische Performance-Inquisition wäre, würde ich natürlich fragen, warum unwichtige Verparty-Skripte überhaupt geladen werden müssen.
Oder sagen wir mal, für das initiale Nutzerlebnis nicht wichtige.
Also, das kann ja so was sein wie, also genau, Analytics, würde ich sagen.
Also, genau, also aus Analytics-Betreiber-Sicht.

[25:50] Möchtest du natürlich immer sofort geladen werden, damit du ja überhaupt kein Event und keinen Pageview verpasst und so weiter.
Das, in bestimmten Kontexten ist das vielleicht auch wichtig, aber in den meisten Kontexten, würde ich sagen, ist das okay, das später nachzuschieben, dann, wenn jemand sofort irgendwie weiter klickt, dann hat man halt mal ein Pageview verpasst.
Aber ich glaube, dass sich an den grundsätzlichen Erkenntnissen jetzt nicht nicht wesentliche Dinge ändern.
Oder halt... Ich meine, es ist halt schon der Check, dass der Checkout-Button, zeitnah funktioniert, wichtiger als, dass du misst, ob da jemand auf weiter klickt.
Genau. Also bei der Rheinischen Post zum Beispiel, da ist es schon sehr wichtig, dass die eben jeden Seitenbesuch mitbekommen, weil das ist dann ...
Also, messen tun die das dann noch zusätzlich über hier VG Word.
Aber so die Zahlen müssen auch dann in Analytics stimmen, damit man weiß, wo man steht.
Denn das ist ja quasi die Reach, die Publikationsreichweite.
Und die entscheidet dann darüber, wie viel Werbung, wie viel Geld man dafür nehmen kann und so weiter und so fort.
Die haben ja keinen Checkout-Button, für die ist ja tatsächlich das die Businessmetrik-Punkt.

[27:02] Zumindest aus Sicht der Publikation ist das für die das Wichtigste.
Und da ist der Benutzer dann vielleicht, also der muss da ein bisschen zurückstecken, weil der kriegt ja quasi für kostenlos Artikel.
Und das muss er dann eben in Kauf nehmen, dass so ein Skript relativ frühzeitig lädt.
Oder es gibt auch so Dinge wie vielleicht Hotjar, was ein gutes Tool ist, mit dem man gucken kann, worauf klicken Menschen am meisten und dann so Heatmaps bauen kann.
Oder man kann auch irgendwie so Screen Recordings dann machen, wenn's irgendwie Probleme gibt.
Und dann kann man die replayen und so und sehen, was hat denn die Person eigentlich, also wie ... Was hat die denn gemacht auf der Seite, dass dieses Problem dann am Ende aufgetreten ist?
Weil das ist auch manchmal schwer rauszukriegen. So, was haben sie denn gemacht? Nix.
Ich hab nix gemacht, und es ging nicht.
Also so quasi ein Stacktrace der Klicks und Eingaben auf der Seite. Genau.
Aber auch das, das ist jetzt nichts, was sofort da sein muss, finde ich.

[28:15] Ja, und ich würd auch sagen, alles, was so dekorativen Charakter hat, oder? Ich könnt mir halt gut vorstellen, das Skript, das das Sündagshighlighting macht.
Wichtig ist, dass das Zeug erst mal gerendert wird, und wenn dann hinterher ein paar Buchstaben rot und grün werden, ist das von eher nachgelagerter Wichtigkeit.
Vielleicht wär das ja auch ein Kandidat.
Sicherlich besser, als da blockierend auf dem Dom rumzuprügeln.
Genau, ist halt die Frage, je mehr auf dem Dom rumprügelnde Dinge gleichzeitig sind, desto mehr zieht sich dann irgendwie sozusagen die Gesamtfertigstellung nach hinten.
Also manchmal ist es ja auch dann tatsächlich gar nicht so förderlich, diese ganzen Sachen nicht blockierend, asynchron, dann quasi immer mehr von diesen Prozessen parallel zu starten, weil am Ende brauchen die halt alle länger.
Und dann, also bin ich dann manchmal ein Fan von blockierend und sequenziell, aber dass eben so die wichtigen Sachen so zuerst die vollen Ressourcen genießen und bekommen und dann eben mit Request-Idle-Callback.

[29:15] Das ist dann quasi nochmal eine extreme Version von einem Defer oder sowas.
Ja, aber ich meine, das wäre ja zumindest etwas, also klar, es wäre gut, wenn man das alles gleich behandeln könnte, aber es stellt sich natürlich auch bei jedem gegebenen Projekt die Frage, na danach, was lässt sich denn überhaupt rauslösen?
Also was ist überhaupt tatsächlich meine Vanövriermasse? Wenn man wirklich alles unter Kontrolle hat, klar, kann das im Prinzip jedes Skript sein, aber wenn man sich in so einem großen Ding bewegt, wo irgendwie alle möglichen Stakeholder in unterschiedlichen Komplexitätsschichten, die ja auch unterschiedliche Abstraktionsniveaus bereitstellen.

[29:47] Ist dann halt eben wirklich die Frage, was ist da überhaupt an manövrierbarem Zeug da?
Was ich halt in dem Kontext super fände, wäre, wenn man irgendwie so Request Idle Callbacks so hätte, also vielleicht, dass man dem dann irgendwie so eine Art Generator geben könnte, von wegen, es sollten irgendwie relativ zeitnah diese Dinge passieren, so eins, zwei, drei, und nicht einfach nur so eine Funktion, Mhm.
Sodass man das so portioniert ausführen kann. Ja.
Also, kriegt man natürlich irgendwie mit vertretbarem Aufwand gebastelt.
Aber gerade bei so was ... Du könntest ja einen Generator bauen, und der yieldet immer, also bei Request Idle Callback.
Ja, klar. Und theoretisch müsste er dann, in dem Moment, wo er yieldet und einen neuen Task startet, dann ist der Rechner auch nicht mehr idle, dann kann auch der Nächste theoretisch ...
Nicht mehr so geyieldet werden erst mal. Ja, ja, klar. Aber du müsstest halt eben so eine Runtime bauen.
Mhm. Also, wo ich auch denke, eigentlich müsste ja so was, eine Generator-Runtime.

[30:45] Eigentlich auch mehr oder minder so ein Browser-Primitive sein.
Denk ich mir halt eben. Weil ich meine, wir haben ja sowieso eine offizielle ... Async-Await ist ja nichts anderes als das.
Konsumiert die Dinger, packt die Promises aus und macht dann mit Next weiter, wenn das Promise Ergebnis oder Fehler geliefert hat. Und das lässt sich ja generalisieren.
Du kannst ja sozusagen sagen, mach weiter, wenn.
Und das könnte ja sein ein Timeout, ein Request-Animation-Frame oder eben ein Idle-Callback.
Und das sind auch nur 20 Zeilen, die man bauen muss, aber es sind halt immer die gleichen 20 Zeilen. Warum gibt's das nicht irgendwie in Fertig-Eingebaut?
Ja, geb ich dir recht. Liegt aber wahrscheinlich einfach daran, dass die, also Request-Idle-Callback, gab's ja, glaub ich, noch bevor es dieses, bevor es Promises gab. Also so alt ist das, glaub ich, schon.
Ja, aber das macht ja nix. Was ich ja wirklich nur haben möchte, ist ja eine native Funktion, der ich sagen kann, erster Parameter Generator, zweiter Parameter ist sozusagen die Interleaving-Funktion.
Mhm. Ne? Und dann ist das ja einfach nur so ein Bing-Bong-Switchen-auf.

[31:45] Mhm. Im Prinzip, was du beschrieben hast. Du musst ja im Prinzip nur sagen, mache wat, dann kriegst du Next, dann irgendeine Aktion starten, eine asynchrone Callback reinstecken, wenn der Callback feuert, wieder Next machen.
Ja, es ist ja wahrlich nicht so kompliziert zu schreiben, nur im Detail halt eben dann doch von wegen hier, Garbage Collection und was nicht alles.
Und es ist halt eben immer das Gleiche.
Und ich muss halt immer, wenn ich davon rede, weil ich davon halt ein tendenziell eher großer Fan bin für so Scheduling von langlaufenden blockierenden Operationen, muss ich den Leuten das halt jedes Mal von vorne erklären, statt denen einfach zu sagen, hier hast du Funktion, schmeißt die beiden Dinger rein und dann kannst du so Kram machen.

[32:24] Du kannst halt so interleaven mit einem Request-Animation-Frame.
Und dann kannst du halt so Sachen machen wie einen Fortschrittsbalken bauen mit so Abbrechen-Button.
Normale Menschen in den Wahnsinn treibt, dass das nicht geht.
Du kannst nicht zwei Sekunden rechnen und einen Abbrechenbutton haben.
Da gibt's dann noch die IsInputPending API, die übrigens von Facebook beigesteuert wurde.
IsInputPending? Genau, wo du quasi abfragen kannst in deiner Loop, ob grade ein Input, also, wenn jemand den Button drückt, dann ist dieser State auf True gesetzt.
Und dann kannst du quasi sagen, aha, okay, Also der Input ist sozusagen angefordert oder gemacht.
Und jetzt ... Und dann kannst du eben darauf reagieren und vielleicht deine Loop erst mal unterbrechen.
Ja, das ist eine ... Das kommt dem, was ich grade so skizziert habe, sehr nahe.
Aber wenn keiner inputtet, wird halt mein Fortschrittsbecken auch nicht animiert.

[33:22] Hm ... Naja, doch, das wär dann ... Im Grunde hast du ... Du hättest eine Loop, wo du quasi immer ein Prozent hochzählst. und diesen Fortschrittsbalken weiter animierst.
Und in der Loop würdest du aber, ist Input pending, abfragen.
Und wenn dem so wäre, oder meinst du, dass während der Input abgearbeitet wird, dann der auch nicht weitergerendert wird?
Na, mein Fortschritt, mein Szenario ist kein Input. Ich drücke auf Go.
Mhm. Es laufen zwei Sekunden lang synchrone Operationen ab, und dann ist es irgendwann fertig.
Ich würde gerne über diesen Zeitraum die Möglichkeit haben, dass jemand auf den Abbrechen-Button drücken kann, was diese API mir bieten würde.
Aber wenn niemand drückt, weil ich die User-Experience habe, dass der Fortschrittsbalken sich langsam füllt.
Aber das könntest du ja dann haben, oder? Was spricht dagegen?
Wenn ich einfach in einem Loop dauernd sage, jetzt wird der Fortschrittsbalken einen Pixel größer, aber dazwischen rendert niemals jemand einen Frame, weil ich ja dann direkt den nächsten Teil-Task mache von meinem zweisekündigen Gesamtberechnungsprozess.
Ich brauche ja irgendwo die asynchrone Atempause.
Okay, verstehe ja. Da hast du wohl recht, genau, weil man dann quasi der weiß ich nicht, der Stack wird, kommt quasi nicht zu einem Ende und darum kommt auch kein Rendervorgang statt.

[34:38] Genau und deshalb, es gibt noch was anderes Neues, ich glaube, das ist in einem Origin Trial drin.
Da kannst du tatsächlich, da gibt es, was war das denn?
Da gucke ich jetzt direkt mal rein. Du googlest, erwähne ich mal kurz, Origin Trial ist ja im Prinzip ein Feature-Fleck auf einer Pro-URL-White-Listing-Basis, für Chrome, wo sie so ihre ganz abgefahrenen Experimente starten.

[35:09] Und das beschreibt es, glaube ich. Genau, Scheduler Yield ist das, glaube ich. Da kannst du...
Provides a method for yielding control to the browser which can be used to break up long tasks to improve responsiveness. Ja, perfekt.
Hast du schon gefunden? Ja, ich lese es gerade. Oh, das passt.
Gut, perfekt. Mein Wunsch wurde erfüllt. Läuft. Ich werde meinen Grimm-Mode zu einstellen.
Ich habe noch eine Sache hier gesehen, die wahrscheinlich auch damit zu tun hat, und zwar äh, was war das hier?
Äh, warte mal, das war irgendwas mit... Also es hatte was mit Pressure zu tun, und ich hatte den Eindruck, das hat was damit zu tun, wie sehr der Browser gerade irgendwie, werkeln muss, aber vielleicht habt ihr es am Anfang gesehen, und dann... Ah, Compute Pressure.
Genau. Warum ist das eben weg gewesen?
The Compute Pressure API offers high-level states das die Druck auf das System darstellt.
Es ermöglicht der Implementation, die richtigen unterliegenden Hardware-Metriken, zu nutzen, um zu sichern, dass der Nutzer die Vorteile aller Prozesskraften hat.

[36:21] Ah, okay. Ist mir jetzt aber auch neu. Äh, ja.
Kann ich jetzt auch nicht so unmittelbar in etwas überführen, was ich machen möchte?
Vielleicht kann man da irgendwie so was machen wie, äh, keine Ahnung, mit was hab ich, mit was für einem Gerät hab ich's zu tun?
Ist das vielleicht irgendwie, ist das CPU-Constraint, kann ich dann vielleicht irgendwie mehr auf die GPU auslagern oder so was in der Art?
Genau, ich lese die Interface-Definition, so ein bisschen wie eine Art Observer, also ein Mutation-Intersection-Observer, also von der API her.
Und das würde ja sozusagen im Prinzip zu dem passen, was du da sagst.
Du kriegst Informationen darüber, wie deine Berechnung gerade so vor sich geht und kannst dann sozusagen On-the-Fly-Modifikationen anbringen.

[37:06] Scheduler austauschen und sowas in der Richtung. Ja. Du kannst dich ja vielleicht entscheiden, dass so ein Interleaving, wie wir das mit dem Scheduler Healed gerade besprochen haben, komplett unnötig ist, weil die Berechnung zwar aufwendig ist, aber da irgendwie der fetteste Rechner hinter ist, der damit immer in einer halben Millisekunde fertig ist, dann kannst du dir halt eben das Interleaving ersparen, was ja unterm Strich alles länger macht, nur halt sich schneller anfühlen lässt.
Ja. Unter der Voraussetzung, dass es so langsam ist, dass man überhaupt den Einsteller wahrnehmen kann.
Genau, du brauchst das Interleaving ja im Grunde, also es ist ja nur sozusagen eine Verlegenheitslösung, weil du anderweitig keine Indikatoren hast, dass jetzt gerade tatsächlich der User oder die Userin was, oder andere Tasks anstehen.
Und so öffnest du einfach ein bisschen Raum.
Aber wenn nichts anderes anstünde, dann verlierst du Zeit.
Machst du ja im Prinzip beim inkrementellen Rendering im Browser auch, ne halbfertige Webseite anzuzeigen, wo irgendwie die Fonts noch nachlädt und das Hero-Image noch nicht da ist, weil die Fetch-Priority nicht richtig gesetzt ist, ist ja auch objektiv langsamer und verschwendet mehr CPU-Umdrehungen als einfach zu sagen, weißer Bildschirm, bis es da ist.
Aber fühlt sich halt nicht so an. dann ist es halt eben auch egal, ob es schneller ist oder nicht. Ja.

[38:19] Genau, dann haben wir als nächstes hier, das kann man vielleicht zusammenfassen

Preload Hints für responsive Bilder und ES Modules

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload

[38:22] mit, also Link Rel Module Preload wird unterstützt, das nehme ich mal hier von unten raus und packe das hier mit dazu.
Also sozusagen das extra für JavaScript-Modules umbenannte Preload.

[38:42] Warum das umbenannt wurde, I don't know, wahrscheinlich weil ich glaube es ist, wie ist das?

[38:51] Naja genau, es sind halt eben keine JavaScript, wobei man könnte ja auch link rel preload as module machen, aber hat man nicht.
Deswegen ist es link rel module preload und ich glaube, das hat schon irgendeinen guten Grund, den ich aber jetzt irgendwie nicht erklären kann. Ich bedanke mich.

[39:08] Das unterstützt der Safari auf jeden Fall. Und was er auch unterstützt, ist, responsivee Bilder zu preloaden, was der Chrome auch schon relativ lange kann, was aber so latent unterdokumentiert ist.
Mhm. Du nimmst im Prinzip den Link Rel Preload as Image, wie der sozusagen spezifiziert ist.
Aber dann kannst du, statt eben href anzugeben, dann gibst du an Image, Source, Set und Image Sizes als Attribute.
Also so wie man das vielleicht dann wiederum von genau responsiven Bildern kennt.
Und da packst du dann exakt das Gleiche rein, was du in deinem responsiven Bild, mag aber auch drinstehen hast, bei Source, Set und Sizes.
Und dann kann der Browser eben auch diese responsiven Bilder nach den gleichen Regeln auswürfeln und preloaden. Okay, das ist natürlich nicht verkehrt.
Ich habe derweil mal gelesen, warum Module-Preload und nicht normales Preload.
Module-Preload, weil tatsächlich das Preloaden von Modules einerseits anders gestaltet werden muss, weil die Modul-Scripts was anderes mit dem Cross-Origin-Attribut, machen, unter anderem. Okay.

[40:29] Und die Module haben ja anders als andere Ressourcen, die du preladest, haben ja eine bestimmte Art und Weise, wie sie ihre Dependencies deklarieren.
Nämlich halt eben mit dieser Import-Export-Syntax, die ja statisch analysierbar ist.
Und dann muss ja auch entschieden werden, dann muss ja dem Browser die Gelegenheit gegeben werden, beim Preloaden eines Scripts, damit das funktioniert, auch die Dependencies mit zu preloaden.
Aber das bedeutet halt eben, dass diese Ressource auf eine bestimmte Art und Weise analysiert werden muss, damit man die Dependencies ermitteln kann. Mhm.
Trotzdem bleibt die Frage, warum konnte das ein S-Module nicht irgendwie bewerkstelligen?
Aber es ist halt S. Also, manchmal ... Das S-Attribut ist tatsächlich so stehende Syntax.
Das gibt's schon. Genau.
Damit sagst du dem Browser, was für ein Nusshussentyp das ist, der da gerade geladen werden muss. Man könnte auch das Cross-Origin-Attribut draufsetzen.

[41:30] Okay, warte mal kurz.
Ich verstehe das schon richtig, dass es ein Attribut namens es gibt, ein HTML Attribut oder spinn ich? Ist das ein globales?
Warum finde ich das nicht in den Spezifikationen?
Bei Link, bei dem Link Element, beim Link Element? Link oder generell noch.
MDN Link Preload erst mal hier zack von MDN müsste ich doch dann.
Zur Speck kommen.
Es nahm was Potential Destination for Preload Request.
For real Preload und Real Module Preload. Aha, du kannst also es mit Modul Preload verwenden.

[42:21] Aber warum? Das sind doch eh nur Modules, da brauche ich das ja wieder nicht.
Also, wenn ich schon Rell Module Preload sage, dann habe ich das ja schon so dermaßen spezifisch, da brauche ich ja dann keine anderen Infos mehr eigentlich.
Nee, nee, nee, eine Destination.
Oder ist es dann die Annotation, dann wiederum diese, also das, was wir eingangs gesprochen hatten, dass du die Möglichkeit dann auch wiederum hast in HTML?
Na, die Idee ist so, wie ich das jetzt sehe, also wie gesagt, man hat ja vorhin gemerkt, das mit dem S-Attribut hatte ich jetzt gerade nicht so auf dem Zettel, weil ich ja nicht wirklich im Alltag mit echten Projekten Performanceoptimierung mache, aber ich lese jetzt gerade hier so, dass es, dass das, was in das S-Attribut reingeschrieben wird, eine in Spezifikationssprech Potential Destination ist und eine Potential Destination ist eine Destination und diese Destination lese ich jetzt eher so von der Auflistung der möglichen Strings, dass das so eine Art, sagen wir mal, Use-Case ist.

[43:18] Und, ähm, dieses Preload versus Module Preload, das Module Preload, mehr so eine Art Mimetype-Angabe über das zu Preloadende ist, wohingegen die Destination in S ja auch eine Information sein kann, so was wie, keine Ahnung, du bist ein Script, oder du bist ein Shared Worker, oder du bist ein Audio Worklet oder dererlei Gestalten.
Und dann werden die vielleicht sozusagen anders auch behandelt dafür, ob die am Ende in einem Shared Worker zum Beispiel landen, was ja vielleicht wegen mehreren, sagen wir mal, offenen Tabs, wo sich dann der Shared Worker da drin befinden muss und wo das dann verschiedene Instanzen der gleichen Webseite, des gleichen Origins sich irgendwie teilen, dass das irgendwie anders gehandhabt werden muss oder anders gesandboxed werden muss, wenn das irgendwie in so ein Worklet reinkommt.
Dass das sozusagen dafür die interne Parallelisierung und das Abfrühstücken von wegen, was lade ich jetzt wie, gebraucht wird und dass die Anweisung halt eben mit dem Script-Preload, Nee, Module Preload, der Gestalt ist von wegen guck rein nach den Dependencies und die Destination halt eben ist.
Und das ist jetzt für dieses Audio Worklet, pass mal auf, dass du dein Cross-Origin, und Konsorten richtig einstellst. So lese ich das.

[44:27] Der ganze Preload-Kram ist halt wirklich echt, glaub ich, so ein sehr, sehr eigenes Universum.
Ja. Ich hab da ja wirklich, was ja sicherlich der Performance-Papst sehr gut findet, ziemlich viel Respekt vor.
Und wird das ja wirklich nur anfassen, wenn ich feststelle, okay, mit irgendwie einfach mach weniger Ressourcen oder mach kleiner oder so komme ich nicht weiter, dann erst würde ich das anrühren.
Weil ich glaube, da kann man sehr viel auch wieder kaputt machen, wenn man es falsch macht.

[44:53] Genau, also eigentlich ist es, also der Hauptzweck ist auch wieder, äh, den Largest Contentful Paint zu optimieren.
Also das, und das ist eben das Hero Build und die Fonts. Ich glaube, das sind so die, eigentlich die zwei Sachen, für die man sowas und auch Fetch Priority eigentlich nur verwenden wollen würde.
Fonts sind eher hochpriorisiert, also da braucht man dann Fetch Priority nicht.
Aber für das Build schon, äh, Build auch nicht lazy machen, weil dann hat man sowieso verloren, weil der Browser das erst lädt, wenn er das Layout gemacht hat und dann merkt, dass es im Viewport ist.
Also genau. Und das sind aber so. Und für eigentlich im Grunde muss man es nicht für mehr Dinge benutzen.
Und bei den Fonts ist es halt auch wichtig, die zu preloaden, weil die zu entdecken eben auch wieder erfordert, das Style Sheet zu parsen etc.
Pp. Und dafür geht einfach sehr viel Zeit.
In Anführungszeichen hab jetzt hier so Air Quotes gemacht, weil einfach ein anderer Parser für notwendig ist.
Das kann der eben der dumme, kleine, aber schnelle Ressourcenscanner nicht.
Das kann nur der quasi der große, ausgewachsene Parser.
Und genau, Fonts können ja auch, haben ja auch einen Impact auf Largest Contentful Paint, wenn ihr zum Beispiel quasi nicht sehr viel Text auf der Seite habt, dann kann es eben sein, gerade auf Mobile passiert das schon mal schnell, dass.

[46:12] Der größte, das größte Element, das gepaintet wird auf einen Schlag eben eins ist mit einem großen Textblock drin und gar nicht vielleicht ein Bild, weil auf Mobile wird das Bild natürlich klein gedrückt und dann ist dessen quasi Oberfläche slash Quadratmeterzahl, wie auch immer, oft kleiner als eben von einem großen Textabsatz.
Und zwei noch ganz ketzerische Fragen. Das Problem besteht ja dann beim Largest Contentful Also für ein spezifisches Problem beim Erstladen der Seite, weil Browser Cache.
Also, ne, nur noch mal eben zum Moderieren dessen, okay, ich pack da jetzt trotzdem überall was drauf. Ja, ist auf jeden Fall ein sehr guter Ansatz, um kätzerisch zu fragen.
Ja, aber nee, pass auf, das Kätzerische kommt jetzt.
Warum inline ich nicht, dass Hero-Image-Space 64 codiert?

[47:11] Mh ... Kannst du ... Kannst du machen. Kannst du im Grunde machen, ja.
Ähm ... Kannst du aber nicht immer. Ja, also oft hast du ein CDN irgendwo liegen.
Und du hast natürlich auch ein Problem, weil du ja responsivee Bilder haben willst.
Letztlich ist das ja ein ganzer Strauß von Ressourcen, die du theoretisch auch alle inleihen könntest.
Aber in dem Moment explodiert dir dein HTML einfach.
Und bei Fonts, die sind halt auch relativ groß. Und das ist halt dann eben auch vielleicht ... na ja.
Dann willst du ja auch so Subsetting und Gedöns machen, ne?
Ja, genau. Also, könntest du machen, hat man ja früher gemacht.
Also, ich glaube, Base64-Codieren ist halt nicht so mega, mega effizient.
Das ist ein bisschen das Problem einerseits. Genau, andererseits generell die Größe.
Aber wo das, das hatte ich auch schon mal erzählt, wo ich das schon gemacht habe, ist das Style-Sheet zu inlinen.
Einfach weil der Web-Server.

[48:14] Sich, weil der eben einfach, äh, sich streng an die Reihenfolge gehalten hat, erst das HTML komplett schickt an den Client und dann die nächste Ressource.
Und, ähm, ich dann kein progressiv gerendertes HTML hatte.
Und damit, ähm, weil das Style Sheet eben erst dann hinterherkam.
Und da das Problem hab ich, oder konnte ich auch nur lösen, indem ich dann das Style Sheet eben geinlined habe. Und auch das kritische JavaScript.
Hm. Aber nur noch mal so zum Kontext.
Das ist halt wirklich schon so am äußersten Limit dessen rumoperieren, wo jetzt schon wirklich alle Kompressionen angeschaltet ist. Ja, klar.
Genau, also das muss man natürlich schon vorher alles gemacht haben.
Idealerweise. Ja, natürlich.
Okay, gut. Das mit den Responsive Images ist eine sehr gute Antwort.
Dann geh ich mal zurück in meinen ...
I show my way out. Ja, in meinen Ketzer-Turm, da so in Kerka.
Ich weiß selbst, wo die Ketten sind, keine Sorge, ich mach das schon. Ich war hier schon mal.

HTTP Early Hints

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103

[49:16] Genau, dann hab ich noch reinsortiert, also darunter sortiert, weil das thematisch passt, Support für HTTP Early Hints.
Also, das ist im Grunde das Gleiche.
Man kann auch über HTTP, also, man kann ja über HTTP Header, kann man ja auch diese ganzen Link-Angaben.

[49:36] Sozusagen ausgeben. Das heißt, sie kommen dann sozusagen noch früher, weil sie jetzt sogar noch vor dem HTML überhaupt kommen.
Das heißt, man muss es dann nicht mehr in den Head reinschreiben.
Genau, und diese Early Hints sind im Prinzip ein Konzept für, also ist auch nicht für jeden geeignet.
Also ich brauche es zum Beispiel nicht bei meinen Projekten.
Aber es gibt Seiten, die zum Beispiel, um zusammengebaut zu werden, erstmal Datenbankabfragen machen müssen oder APIs befragen müssen.
Oder auf jeden Fall, also man kann noch nicht sofort das Ergebnis schicken, weil es noch nicht feststeht.
Und dann kann man eben Early-Hints schon mal schicken. Das ist also quasi so ein HTTP-Header-Schnipsel, den man schon mal vorab schickt.
Und dann hat der Browser, kann er sich den angucken und schon mal damit arbeiten.
Und da stecken dann eben die Hints drin.
Und dann verliert man keine Zeit. Also dann ist alles schon vorbereitet.
Bis dann im Grunde der, das echte, das fertige Dokument mit dann seinen üblichen HTTP-Headern hinterherkommt.
Also im Prinzip HTTP-Header, die vor den üblichen HTTP-Headern noch schon vorab geschickt werden. Okay.
Du hast gesagt, Webseiten, die dieses und jenes machen, kannst du mir doch mal den Use-Case dafür konstruieren?

[50:53] Naja, wenn du eine Webseite hast, die dynamisch berechnet wird, möglicherweise, die... As in WordPress.
Vielleicht, erst in WordPress, richtig, könnte man sagen.
Und, ähm, es gibt natürlich auch die Möglichkeit, also, es gibt ja dieses Early Flushing, dass man quasi sagt, ich nehm den Headbereich meines HTMLs, der ist eh immer gleich.
Wobei das ja dann vielleicht schon mit dem Title dann so ein bisschen problematisch wird. Aber dann vielleicht, sagen wir mal, den oberen Teil des Head und der Title kommt dann erst hinterher.
Den kann ich flushen. In PHP gibt's ja dann auch die Möglichkeit, diese Buffer zu flaschen, und dann wird das quasi schon mal so als Fragment geschickt.
Und so ein ähnlichen Character-Data haben halt die HTTP-Early-Hints, nur dass sie eben sich nicht ... Und dass sie nicht im HTML leben, sondern wirklich in der Browser-Server-Kommunikation.

[51:50] Also in den Metadaten sozusagen des Requests.
Okay, also sozusagen vor dem eigentlichen Request ... Also vor dem eigentlichen Header kommen noch andere Header, Das ist so, als würde vor der eigentlichen Seite mit meinem PHP-Krempel erst mal der Head rausgerendert werden. Also, gechunkt quasi.
Genau, ja. Richtig.
Okay, das klingt jetzt wirklich ein bisschen nach Space Age.
Ja. Was ich glaube, auch wenn man CDNs benutzt, also die üblichen Cloudflare, Fastly und Co., dann ist es so, dass die, glaub ich, sogar automatisch, wenn man solche Angaben im HTML hat, Und das Übersetzen in HTTP-Early-Hints, also, die schaden ja auch nicht.
Also, man kann das machen, sie bringen halt nicht immer was.
Ähm, genau, aber wenn man solche Services nutzt, dann wird das automatisch transformiert.
Und dann ist es ja auch nicht so Space-Age, also aus Nutzerinnen-Sicht, weil ich benutze halt den Service, der macht das automatisch, ich merk nix, und für die ist es halt einfach das Business. Macht ja durchaus Sinn.
Aber wenn ich jetzt wirklich mein eigenes WordPress pflege, klein sind, wie sie sein können.
Und das letzte Performance-Feature des Safari ist, dass er jetzt auch Preconnect unterstützt, wo du quasi sagen kannst, hey, ich werde später Ressourcen von asset.webseite.com, benutzen.

[53:14] Das weißt du jetzt noch nicht, aber du kannst schon mal preconnecten und dann machst du vielleicht den TLS-Handshake und so alles, was so Zeit kostet bei so Verbindungsaufbau.
Und später geht's dann direkt los.
Also wo ich dann schon sozusagen weiß, mit welchen CDNs ich alle reden werde, obwohl ich mit denen noch nicht geredet habe.
Aber spätestens wenn jemand das Mausrad bedient wird, wird das aktiv werden.
Genau, da kann man auch, also ich finde es auch nicht schlimm, da das eine oder andere Pre-Connection mehr rein zu machen.
Also weil manchmal ist es halt dieses CDN, manchmal ein anderes.
Und vielleicht nutzt man die auch nicht alle auf jeder Seite und dennoch habe ich dann so die üblichen Verdächtigen, die pre-connecte ich dann einfach und dann ist es auch gut.

[54:03] Ja, ich nehme an, solche Informationen, wenn sowas wie DNS da einmal aufgelöst ist, merkt sich der Browser auch in irgendeiner Weise über eine Session hinweg.
Also irgendwie, ich habe meine Startseite, da kann ich ja schon mal zu allem pre-connecten, was man dann auch auf der genannten Kontaktunterseite sieht.
Auch wenn da niemand hinklickt, sollte es dazu kommen, ist kein Schaden, wenn ich auf der Startseite schon mal gesagt habe, Das sind alle CDNs und Konsorten, mit denen man gegebenenfalls mal reden muss, weil der Browser sich das merkt, und das nicht Verschwendung ist.
Genau, also das ist auch tatsächlich so, also man muss auch immer unterscheiden.
Viele, also der Dinge, über die wir sprechen, sind weniger relevant natürlich bei wiederholten Besuchen.
Das ist auch tatsächlich so, dass der Chrome-Browser, also wenn du da oben in die Omnibox zum Beispiel was eingibst, dann, und das deutet schon, also per Autovervollständigung darauf hin, dass du vielleicht irgendwie workingdraft.de, lädst, dann guckt der halt intern nach was zu welchen anderen host musste ich mich da connecten und macht das auch schon tatsächlich in der zeit im hintergrund aber es ist halt dennoch so dass also dass auf vielen seiten die leute nicht wiederkehrend sind also Also es sind weniger wiederkehrende Leute als man gemeinhin denkt.
Und dann, was so das ganze Preloaden und so angeht, da könnte man ja auch sagen, gut, das ist dann ja einmal im Cache und dann ist gut.
Aber heutzutage deployed man ja auch 38.000 Mal pro Minute.
Und dann sind ja quasi die Ressourcen auch immer alle.

[55:33] Werden ausgetauscht. Und das heißt also, selbst Leute, die regelmäßig auf eine Seite kommen, Also im Fall von Preconnects jetzt weniger, aber was so das Preloaden und was so Caching angeht und so, die kann man eigentlich so betrachten, als wenn die erstmalige Besucher sind.
Unter der Voraussetzung halt, dass du tatsächlich dieses ...
Deployment-Muster so in der Form hast, ne? Ja.
Also, ich hab da ja immer so ein bisschen Fürchtung davor, dass ich irgendwie in meiner eigenen Echo-Kammer sitze, wo ich lauter mit so permanent Deployern sitze.
Mhm. Wo es ja auch möglicherweise andere Existenzformen der Webentwicklung da draußen gibt. Ja, gibt es.
Aber in dem Projekt, in dem ich bin, ist es schon so, dass die Ressourcen nicht übermäßig lange stabil bleiben.
Das ist klar. Und das ist ja auch oft so. Und ist ja auch alles in Ordnung so, nur ich finde das halt immer wichtig, bei den neuen Features dazu zu sagen, weil ich meine, du kannst ja mit dem Text-Stack, wie er sich heute, wie er sich gestern, wie er sich vorgestern dargestellt hat, problemlos eine Webseite hinbauen.

[56:34] Und Preconnect ist ja tatsächlich dann eine Optimierung, erstens, auf die man auch verzichten kann, gegebenenfalls, wo man sich jetzt nicht unter Druck gesetzt fühlen muss, von wegen, oh Gott, oh Gott, ich muss jetzt aber.
Und zum anderen, wo es ja teilweise auch wirklich spezielle Use-Cases und bestimmte Voraussetzungen gebunden ist.
Gerade so bei Performance habe ich halt, also das kennst du besser als ich, aber ich habe halt immer so ein bisschen, ehe ich darüber den Mund aufmache, echt immer sehr viel Sorge genau einzuschränken, unter welchen Umständen das für was gut ist, weil da, glaube ich, die Cargo-Kult-Gefahr relativ hoch ist, dass die Leute dann das am Ende verwenden.
Also Beschwörungsformeln, es geht nicht offensichtlich kaputt, es macht nicht offensichtlich was schlechter, aber auch kleine Sachen wie HTML-Attribute, türmen sich halt eben auf und dann machen die am Ende gegebenenfalls nicht das, was man meint, oder das ist nicht wirklich hilfreich, es ist sogar schädlich, aber ganz marginal.
Also dass ich immer sehr viel Sorge habe, das zu kontextualisieren deswegen. Ja.

[57:25] Nee, also da hast du recht. Ähm, ich glaube, na ja, vielleicht letztlich muss man ja auch damit irgendwie mal rumhantieren, um so auch ein Gefühl dafür zu kriegen, wann die gut sind, wann nicht.
Mhm. Ich sag mal so, die beste Regel ist vielleicht, einfach diese Dinge nicht zu benutzen. und aber...

[57:48] Klar, go for it, wenn du mal Lust hast. Und dann kann er ja auch die Dinge immer noch mal korrigieren.
Das sowieso, ne? Nur wichtig halt eben, wenn's schnell werden soll, guck mal, ob dein JPEG wirklich so klein ist, wie du meinst.
Ja, und ich glaube so, am Ende ist auch immer ein Blick auf so was wie einen Webpagetest-Wasserfall, das ist immer so, find ich, der Ausgangspunkt, um zu den richtigen Schlüssen zu kommen, welche dieser Maßnahmen man denn eigentlich ergreifen muss.
Weil man da ganz klar sieht, wann was passiert, und was irgendwie miteinander verkettet ist.
Und, ähm, genau, und dann kann man eben darüber nachdenken, wie man diesen Wasserfall dann eben sozusagen etwas umsortiert bekommt.
Entweder umsortiert oder halt erst mal feststellen, hab ich ein Problem, und wenn ja, wo ist es? Also, tut's mein Treeshaking überhaupt?
Ja. So, oh nee, das JavaScript ist irgendwie zwei Megabyte groß.
Vielleicht guck ich da mal zuerst hin. Ja.
Klar. Ja, also, back to the basics. Und wenn da alles durch ist, dann ran an die Preconnects, Preloads, REL, Module-Preloads.
Und was es dann noch alles Schönes in der Safari-Technology-Preview-Edition.

[58:55] 178, gab.

[58:58] Genau, vielleicht darf ich noch eine Sache zu Preload sagen, und zwar, was man manchmal vergisst.
Manchmal schreibt man den Host rein, zu dem man sich preconnecten möchte.
Aber wichtig ist eben auch, das Protokoll reinzusetzen. Denn wenn das nicht drin ist, dann wird auch nicht preconnected. Und weil, wenn HTTP drinsteht, dann ist klar, dass kein TLS-Handshake nötig ist.
Und wenn HTTPS drinsteht, dann muss der eben auch gemacht werden.
Und der Browser macht eben nichts, wenn ich jetzt nur Webseite.com, eingebe an der Stelle als Wert. Da muss schon HTTPS://webseite.com, drinstehen. Okay, das ist natürlich auch nicht unsichtig.
Genau. Was hältst du davon, wenn wir hier den Cut machen? weil ich glaube, der wäre, glaube ich, nicht schlecht.
Als nächstes Thema hätten wir nämlich die Cookie Store API. Und wir haben noch so ein paar andere Sachen.
Ein paar andere Sachen. Unser Google Doc hat, also wir haben jetzt ungefähr ein Drittel davon durch.
Genau, also uns geht das ja immer so anscheinend. Also es entgleist immer.
Und die Cookie Store API, ich glaube, dass die auch so ein Kandidat ist für ausgeschweiftere Philosophien darüber.

[1:00:10] Deswegen würde ich vorschlagen, dass es jetzt so mit diesem…, Also ich hab das nicht so geplant, aber mit diesem Performance-Block, dass das irgendwie eine runde Sache ist und dass wir uns vielleicht dann einfach einen anderen Termin suchen, wo wir weitermachen. Würde ich vorschlagen.
Und dann starten wir da mit der Cookie-Store-API.
Genau, und lustigen HTML-Features.

[1:00:33] Cool, machen wir. Genau, wann das sein wird, ihr kennt das, ist nicht immer klar. Denn, denn, denn ...
Als nächstes, dann haben wir wieder Gäste. Wir müssen dann mal gucken, wo wir dann wieder eine Lücke haben.
Und dann, genau, dann zicken wir uns da rein.
Dann sliden wir da in diese Lücke und schließen unsere Lücken im Know-how der Diskussion.
Indem wir Sendungslücken schließen, schließen wir unsere Know-how-Lücken, schließen wir die Kuppel über die Illusion, dass der Working Draft in organisierter Form streng geplant entsteht. Natürlich.
Immer. Das tut er. Genau. Kleiner Funfact.
Der eine oder andere oder die eine oder andere hat's bestimmt auch auf Social Media gelesen.
Ich war jetzt auf der Border None in Nürnberg und hab endlich mal die Vanessa getroffen, in echt.
Also jetzt nach drei Jahren und 150 Episoden, an denen wir alle gewerkelt haben, doch so schnell. Genau.
Also, bei dir ging's schneller. Ich glaub, bei dir waren's zwei Jahre oder anderthalb.
Ich glaub, wir sind uns auch schon mal vorher auf irgendeiner Software- und Supportveranstaltung über den Weg gelaufen.

[1:01:49] Meinst du? Aber da haben wir noch keinen Podcast zusammen gehabt wahrscheinlich. Ich glaube ...
Nee, nee, ich mein nicht du und die Vanessa, ich meine uns, also du und ich.
Ach, das war ja noch prä-Working Draft, oder?
Nee, nee, das war schon in Working Draft, aber das war noch zu einer Zeit, wo wir noch ... Das heißt also, ich hab die Vanessa auch erkannt. Ja.
Und bei dir, genau, wusste ich gar nicht, wie du aussiehst, weil du hattest damals auch nur dein P auf rot, weißes P auf rotem Grund, Avatar.
Ja. Also, man hatte keinen Anhaltspunkt.
Und, ja, das war sehr spannend.
Mhm. Vanessa war auch cool. Aber, genau, ich wusste, wie sie ungefähr aussieht.
Und du hast bestätigen können, dass Rodney, die älteren Zuhörerinnen und Zuhörer, erinnern sich noch, dass der noch lebt und dass es dem gut geht.
Ja, genau. Der hat auch einen echt super Vortrag gemacht. Es war eh eine tolle Konferenz und Rodney hat überhaupt nicht über Programmieren gesprochen, sondern über seinen...

[1:02:52] Programmieren tut er ja immer noch, aber er fliegt auch seit vier Jahren mit dem Paraglider und hat einen Vortrag darüber gehalten.
Und es war richtig cool.
Generell ein cooles Konzept, eine Konferenz zu machen und zehn Jahre später einfach alle wieder einzuladen.
Also schon ziemlich hammer.
Ja, hat mir gut gefallen. Ich glaub, hat allen super gefallen.
Und es ist toll aufgegangen, das Konzept. Es hätte ja auch in die Hose gehen können.
Aber irgendwie hat alles zueinander gepasst. In zehn Jahren kann eine ganze Menge Blödsinn passieren.
Da kann man auch größere Shifts hinlegen als Rodneys.
So, ich flieg jetzt, und die können sich mit der Net alleine streiten.
Ich hab Wichtigeres zu tun. Ja.
Man kann auch zu anderen Schlüssen kommen über Gott und die Welt.
Und die sind dann etwas kontroverser und weniger gut, in das Kleid einer Konferenz zu quetschen.
Ja, so ist es auch.

[1:03:51] All right. Dann ... ... würd ich sagen, haben wir doch einen schönen ersten von ... was weiß ich, von vielen Teilen eingetütet. Von N.
Das kann man nicht sagen. Das Problem ist, die werden ihren dämlichen Safari weiterentwickeln.
Wer weiß, ob wir schneller sind, Sendungen aufzunehmen, als die da drin sind, auf den Deploy-Knopf zu drücken.
Ja, das stimmt. Es kann schon sein, wir haben ja ein bisschen Backlog.
Die eine oder der andere hat es vielleicht gemerkt, dass wir zum Beispiel ein bisschen hinterherhängen, aber wir haben quasi ein Backlog, das aber wahrscheinlich über Weihnachten abgearbeitet wird.
Also vermutlich ist Safari 17.2 raus, wenn diese Folge rauskommt.
Und dann gibt's sogar noch weitere Features, die wir hier gar nicht, von denen wir noch gar nichts ahnen.
Hey, wir sind so schnell, wie wir können. Ja.

[1:04:45] All right, dann vielen Dank. Dir einen schönen Start in die Woche.
Danke, danke, ebenso. Erfolg bei deinen nächsten Erklärbeaturen.
Die werden nicht so wild wie die letzten, von daher sollte der Erfolg sicher sein, mich kann nichts aufhalten. Sehr gut. Außer an Husten vielleicht.
Husten, ich dachte jetzt mehr so an andere große systemische Dinger.
Die auch mit Rot und Weißen auswürfen über die Schienenstränge dieser Republik zu tun haben.
Vielleicht können die mich ja aufhalten, aber ich habe nicht vor, danach zu geben.
Sehr gut. Dann telefonieren wir uns einfach irgendwann wieder zusammen, wenn es passt. Und releasen, sobald es geht.
So machen wir das. So machen wir das. Danke schön fürs Zuhören, genau, Input wie immer in unserem Slack. Bis dann, tschüss.

[1:05:32] Music.

[1:05:36] Untertitel von Stephanie Geiges.

Revision 596: Neues in Safari, Teil 1 von 2

Optimierung der Webseitenperformance und neue Webstandards werden diskutiert. Themen: Fetch Priority, Request Idle Callback, Backend-Workshops, Leistungssteigerung, zukünftige Gäste und Safari-Versionen.

Chapters

Long Summary

Brief Summary

Tags

Transcript

Revision 596: Neues in Safari, Teil 1 von 2

https://workingdraft.de/596/

Import Attributes

https://github.com/tc39/proposal-import-attributes

Priority Hints

https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchPriority

Window.requestIdleCallback()

https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback

Preload Hints für responsive Bilder und ES Modules

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload

HTTP Early Hints

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103