Ivan Akulov ist ein Google Developer Expert für Webtechnologien und der Gründer des Performance-Unternehmens PerfPerfPerf . Sehr bald, auf der HolyJS 2019 in Moskau, wird er seltsamerweise einen Workshop abhalten, der sich der Leistung widmet - Probleme in React finden, langsame Anwendungen und andere Laufzeit-Dinge debuggen.
Um die Leser und Besucher von HolyJS 2019 Moskau besser in das Thema einzutauchen, haben wir mit Ivan Folgendes besprochen:
- Die beliebtesten Leistungsprobleme;
- Wie man die Leistung misst und was das Problem sein kann;
- So optimieren Sie die Leistung;
- Suchen Sie in React nach Leistungsproblemen.
- Die Vorteile des Wechsels zu HTTP / 2 und HTTP / 3;
- Es ist besser, bei neuen Projekten ein kompaktes Framework zu verwenden.
- Informationen zu den Vorteilen von WebAssembly;
- Wo kann man nach nützlichen Leistungsinformationen suchen?
- Worum geht es in seinem Workshop und wer wird daran interessiert sein, dorthin zu kommen (und warum überhaupt zu Workshops gehen).
Fragen stellen Dmitry Makhnev und Artyom Kobzar vom HolyJS-Programmkomitee.
Dmitry: Erzähl mir ein paar Worte über dich.
Ivan: Ich bin Ivan Akulov, Leistungsberater, Google Developer Expert, der meine Leistungsberatungsagentur leitet.
Dmitry: Sie sagen, dass eine Beratungsagentur nicht die Hauptaufgabe ist. Aber was machst du eigentlich?
Ivan: Meine Zeit ist jetzt ungefähr so verteilt, dass ich halb mit der Arbeit mit einem alten Kunden beladen bin. Ich arbeite mit einem brasilianischen Unternehmen zusammen, zusammen erstellen wir eine Wordpress-Content-Marketing-Plattform, ich verwalte die Infrastruktur dort und ein bisschen Produktentwicklung und eine Art gemeinsame Vision.
Den Rest der Zeit widme ich mich Beratung, Reden, Artikeln und all dem.
Dmitry: Gibt es viele Appelle für Leistungsberatung? Wie funktioniert es überhaupt?
Ivan: Im Allgemeinen hängt es sehr stark vom Monat oder so etwas ab ...
Dmitry: Wann geben Astrologen den Monat der Aufführung bekannt? :)
Ivan: Eher, wenn die Buchhalter ein neues Quartal ankündigen! (lacht) Ich suche momentan nicht aktiv nach Kunden, der Hauptgrund ist, dass dafür jetzt keine Zeit ist, weil ich bereits mit dem geladen bin, was ich habe. Aber im Allgemeinen sieht alles so aus, als würde ich einige Artikel schreiben, einige Reden halten und bei der Arbeit mit einigen Kunden erinnern sie sich an mich und empfehlen mir neue. Meistens kommen Leute dank des Netzwerks und ziemlich coole Typen kommen.
Artyom: Wie sind Sie überhaupt zum Performance-Thema gekommen, bevor Sie Ihre eigene Beratungsfirma gegründet haben?
Ivan: Eigentlich fing alles damit an, dass wir einmal ein altes Projekt in Epam für ein halbes Jahr auf Wepback umgeschrieben haben. Es gab ein altes Projekt mit einer Reihe von Legacy-Inhalten und einem eigenen Front-End-Framework, von denen die Hälfte im Java-Stack funktionierte. Und da wir ein halbes Jahr damit verbracht haben, Webpack relativ schnell zu erstellen, habe ich Erfahrung mit Webpack gesammelt. Und zu dieser Zeit konnte ich eine Webpack-Konfiguration mittlerer Komplexität schreiben, Zeilen von 20 bis 40, buchstäblich aus dem Speicher, ohne etwas zu googeln, ohne zu gucken und sogar ohne IntelliSense zu verwenden.
Und ich erkannte, dass eine solche Erfahrung für jemand anderen nützlich sein könnte. Ich beschloss, eine Art Beratung im Bereich Webpack zu starten. Ich machte eine Landung für mich selbst, postete sie irgendwo, ein paar Leute kamen, ich arbeitete mit einem von ihnen. Und irgendwie fing alles an.
Und später wechselte ich reibungslos von der Leistung im Zusammenhang mit dem Webpack zur Leistungsberatung im Allgemeinen.
Artyom: Haben Sie es geschafft, die Montageleistung bei diesem Projekt zu verbessern?
Ivan: Dieses Projekt hat nicht perfekt geklappt, nicht so, wie ich es am Ende gerne hätte. Es war so eine Sache, dass die Jungs zu einer Zeit kamen, als ich wirklich Geld brauchte und immer noch nicht verstand, wie man verhandelt, auf mich selbst aufpasst und meine Interessen bei diesen Verhandlungen berücksichtigt. Ich schlug einen kleinen Festpreis mit einer ungesicherten Menge an Arbeit vor, wir arbeiteten, ich half ihnen, traf eine Entscheidung, die zu funktionieren schien, und legte die Leistung fest.
Dann stellte sich heraus, dass diese Lösung Fehler enthielt. Es stellte sich heraus, dass sie überkompliziert war und in seltenen Fällen seltsame Fehler auftraten. Wir haben angefangen, das Problem zu beheben. Ich habe einen, zweiten und dritten Fehler behoben. Das alles dauerte einen Monat. Und am Ende hörten die Fehler irgendwann auf, aber die Jungs beschlossen, mich um etwas anderes zu bitten, aber da ich ein internes Budget dafür habe, ist es komplett vorbei. Ich sagte nur: "Entschuldigung, ich bin bereits geladen und nicht Ich kann helfen. "
Soweit ich herausgefunden habe, haben sie diese Lösung in ein paar Monaten durch eine andere, weniger komplizierte ersetzt und in 100% der Fälle funktioniert.
Um ehrlich zu sein, ich kenne mich selbst nicht ... Es scheint, dass ich gekommen bin und geholfen habe, und die endgültige Entscheidung, die sie getroffen haben, wurde in unseren früheren Gesprächen getroffen, aber ich weiß nicht, wie sehr sie mir geholfen haben, was ich getan habe. Und wie zufrieden sie damit waren. Kurz gesagt, es war nicht so perfekt, wie ich es gerne hätte.
Artyom: Und wenn Sie von heute sprechen, verfolgen Sie irgendwie vergangene Kunden, wie geht es ihnen dort, hat das alles geholfen?
Ivan: Ja auf jeden Fall. Ich entwickelte nach und nach einige Ansätze. Erstens versuche ich am Ende meiner Arbeit, von jedem Kunden ein öffentliches Feedback zu erhalten, das auf der Website oder irgendwo veröffentlicht werden kann.
Zweitens habe ich einen Ansatz entwickelt, um Kunden am Prozess oder am Ende eines Jobs die Frage zu stellen: „Wie sind Sie mit dem aktuellen Prozess, dem aktuellen Workflow und dem aktuellen Etwas zufrieden?“ mit den Antwortoptionen "mehr als zufrieden", "zufrieden", "fast zufrieden", "nicht wirklich zufrieden".
Und ich mag diese Frage, weil sie spezifische Antworten gibt und keine dumme Skala von 1 bis 5, die jeder auf seine Weise wahrnimmt. Bisher hat keiner der Kunden mit „fast zufrieden“ oder „nicht wirklich zufrieden“ geantwortet. Es war zufrieden, glücklich und so ähnlich.
Artyom: Verstehe ich richtig, dass sich Ihr Fachgebiet für Leistung hauptsächlich an den Kunden richtet? Oder haben Sie den gesamten Webstack als Ganzes von den Konsultationen betroffen?
Ivan: Ja, das Fachgebiet richtet sich hauptsächlich an den Client-Stack, mit der Leistungsoptimierung im Backend oder in den Datenbanken habe ich viel weniger gearbeitet. In der Praxis verlangsamen sich jedoch 80-90% der Fälle, wenn sich eine Webanwendung verlangsamt, selbst in einigen Artikeln oder Studien - genau aufgrund des Frontends.
Wenn ein Kunde hereinkommt und etwas langsamer wird, ist mein Fachwissen in den meisten Fällen genau richtig.
Über die beliebtesten Themen
Artyom: Und was passiert, wenn es einige Randfälle gibt? Wenn wir ein Problem haben, nicht beim Parsen von JavaScript und dessen Start, sondern beim Transport. Wenn die erste Interaktion sowohl dem Client als auch dem Backend zugewiesen wird. Es ist kitschig, dass gzip falsch eingerichtet wurde und sich zu lange dreht. Was machen Sie in diesen Fällen? Und wenn Ihre Analyse hauptsächlich an vorderster Front steht, wie finden Sie solche Fälle?
Ivan: Nun, das bedeutet normalerweise, dass die Antwortzeit vom Server zu lang wird. Wenn ich dies während einer Art Audit bemerke, schaue ich in devtools, schaue im Netzwerk und sehe, dass die Zeit vom Server 800 ms beträgt - um verrückt zu werden, dauert es zu lange. Und ich werde versuchen zu verstehen, wie die Jungs einen Server haben, was sie bei jeder Antwort tun. Wenn dies JavaScript oder PHP ist, kann ich es höchstwahrscheinlich gut herausfinden und alles reparieren, wenn eine andere Sprache, mit der ich nicht gearbeitet habe, möglicherweise ihre Hilfe benötigt.
Dmitry: Können Sie eines der fünf häufigsten Leistungsprobleme nennen, die in der Praxis auftreten?
Ivan: Ich werde dem Weg folgen, an den ich mich erinnere. Eines der häufigsten Probleme, das nicht in komplexen Webanwendungen, sondern auf einfachen Websites auftritt, besteht darin, dass ein Entwickler oder Client viele Skripte ohne asynchrone oder verzögerte Attribute in das Head-Tag einfügt. Dies ist schlecht, da der Browser die Seite erst rendern kann lädt diese Skripte nicht und führt sie nicht aus.
Und wenn es einen langsamen Server oder ein großes Skript gibt, dessen Ausführung lange dauert, wird die Seite, die die Site verwendet, die Seite erst am Ende der Ausführung sehen.
Ein weiteres häufiges Problem sind Skripte von Drittanbietern. Ich arbeite derzeit mit einem Kunden zusammen, dem ich dabei helfe, seine Leuchtturm-Punktzahl zu verbessern. Anfangs hatten sie einen Leuchtturm-Score von 35-40. Ich bin gekommen, habe alle möglichen Dinge getan, unnötiges JavaScript gelöscht, Ressourcen zum Rendern blockiert, irgendwie optimiert ... Nach all dem, was ich getan habe, ist die Punktzahl nur irgendwo auf 55 angewachsen. Und es stellte sich heraus, dass, wenn Sie mit dieser optimierten Seite eine einzelne React-Komponente auskommentieren, die alle Analysen lädt, die Leuchtturm-Punktzahl irgendwo auf 88-90 + Punkte springt. Dies geschieht, weil es so viele JS gibt, die Metriken entfernen.
In einigen komplexen Webanwendungen ist ein häufiges Thema, wenn Entwickler eine große Bibliothek installieren und diese vollständig in das Bundle bündeln, obwohl sie nicht vollständig verwendet wird. Oft ist dies Moment.js , in dem es riesige Lokalisierungsdateien gibt, 165 KB minimierte Lokalisierungsdateien, die fast niemand benötigt, oder lodash , in denen es viele Methoden gibt und alle nur 10-20 verwenden.
Bei der Renderleistung gab es häufig ein Problem, wenn Entwickler eine Art Ereignishandler auflegten, z. B. bei einem Ereignisscroll, es dauerte 5 bis 10 ms, und jedes Mal, wenn Sie versuchten, durch etwas zu scrollen, blieb die gesamte Seite zurück. Jetzt ist dies weniger geworden, weil im selben Chrome [passive Ereignis-Listener hinzugefügt] ( https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ).
Informationen zum Messen der Leistung
Dmitry: Im Laufe der Fälle tauchte eine Frage zu Lighthouse auf. Meiner Meinung nach waren alle drei auf dem BeerJS-Gipfel und es gab einen coolen Bericht - (Hundertstel) von Alexey Kalmakov . Es gibt keinen Eintrag , aber ich habe einen ähnlichen Artikel über Habré gesehen , und solche Dinge sind ein kleiner Kompromiss für Lighthouse. Wenn Sie es nur als Werkzeug zur Bewertung der Arbeit eines Performance-Ingenieurs verwenden, können Sie dort einige Tricks ausführen.
Haben Sie Werkzeuge, vielleicht sogar selbst geschriebene, mit denen Sie klar beurteilen können, ob Sie erfolgreich waren oder nicht? Zum Beispiel unterschreiben Sie einen Vertrag und es wird Ihnen gesagt, dass Sie Leistung x2 machen müssen. Welches Toolset werden Sie dafür verwenden?
Ivan: Nun, erstens, wenn wir einen Vertrag abschließen und uns auf x2 einigen, werden wir uns auf eine Art Instrument einigen. Aber im Allgemeinen mag ich neben Lighthouse auch WebPageTest . Dies ist ein sehr cooles Tool für die erweiterte Webleistung, mit dem Sie Ihre Anwendung von einem beliebigen beliebigen Ort aus, beispielsweise in Brasilien oder Australien, auf einem realen, beispielsweise sehr schwachen Gerät wie Moto G testen können .
Dies ist cooler als Lighthouse, da es all dies emuliert. Erst nach Tests auf einem realen Gerät wissen Sie, dass die Site 15 Sekunden lang gerendert wird. Der zweite Vorteil: Es bietet eine Reihe sehr detaillierter Metriken für alle Arten von Diagrammen, z. B. das Laden. Ich benutze es regelmäßig, um mir einige Dinge anzusehen.
Dmitry: Haben Sie eines Ihrer Tools beispielsweise über das Chrome DevTools-Protokoll geschrieben ? Was fehlt Ihnen an Werkzeugen?
Ivan: Ich habe mein Instrument auf Lighthouse geschrieben. Um mit einem der Clients arbeiten zu können, benötigte ich ein Setup, mit dem ich die Leistung einer Seite mit dem Leuchtturm in einer relativ stabilen Umgebung messen, als Leuchtturm-Punktzahl betrachten und in die Tabelle kopieren konnte. Bei ihm gibt es ein Problem: Der Leuchtturm in PageSpeed Insights ist nicht sehr stabil. Wenn Sie dieselbe Seite dreimal messen, können Sie drei verschiedene Messungen erhalten. Außerdem musste ich nicht die Seiten messen, die bereit und im Netzwerk veröffentlicht waren, sondern die lokale. Und die einzige Möglichkeit besteht darin, Lighthouse lokal auszuführen, was sich auch stark auf die Leuchtturm-Punktzahl auswirkt, da Die Punktzahl hängt davon ab, was auf Ihrem Laptop funktioniert. Beispiel: Docker gestartet, fiel die Punktzahl zweimal.
Für diesen Fall musste ich Lighthouse vorhersehbar messen. Ich schrieb ein Skript, das Lighthouse dreimal ausführte, eine Punktzahl, nahm den Medianwert der drei Male und tat es für viele Seiten mit vielen Setups. Ich habe dafür einen DigitalOcean-Server gemietet und dort alles ausgeführt, um ihn so weit wie möglich von externen Faktoren zu isolieren.
Artyom: Sie haben einen interessanten Fall über verschiedene Lighthouse-Metriken erwähnt. Es gab kürzlich einen Artikel, Eine Einführung in 99 Perzentile für Programmierer , in dem sie gerade zu dem Schluss kamen, dass moderne Benchmarking-Tools und im Prinzip Mikro-Benchmarking allein nichts beweisen.
Mit modernen Werkzeugen kann sich herausstellen, dass ich einen Benchmark erstellt habe, Sie haben geschrieben, Dima hat geschrieben, und alle werden ganz andere Dinge sagen. Und jetzt, in einer Welt ohne mehr oder weniger tiefes Wissen in Theorie und Statistik, erscheint Benchmarking nicht sehr plausibel. Sie haben Lighthouse erwähnt, aber gibt es Hinweise, die Sie im Benchmark erhalten haben, eine zusätzliche Bestätigung?
Dmitry: Vielleicht Leuchtturm mit etwas mischen? Sie haben WebPageTest erwähnt. Wir nehmen sie, vielleicht sogar Beobachtungen von Chrome DevTools, und mischen sie irgendwie?
Ivan: Eigentlich im Idealfall, wenn es irgendetwas in einem Projekt gibt, mit dem Sie RUM (Real User Metrics) verfolgen können - wie real die Site für einige Benutzer geladen wird und ob wir sie für echte Benutzer bereitstellen und sehen können, wie es hat für sie funktioniert - es ist der perfekte Fall.
Aber im Allgemeinen, ja, wenn ich ein Tool verwende, führe ich wirklich mehr als einen Test durch, um den Medianwert zu erhalten, aber im Allgemeinen wirft der Artikel das eigentliche Problem auf, dass es eine Art 99. Perzentil von Benutzern gibt, die alles sehr haben Es ist schlecht und wir wissen nicht, ob wir nur Lighthouse verwenden. Dies bedeutet jedoch nicht, dass Lighthouse nutzlos ist. Es funktioniert weiterhin und zeigt die durchschnittliche Temperatur im Krankenhaus an. Wenn wir insgesamt die Leistung verbessert haben, wird Lighthouse dies zeigen.
Dmitry: Sie haben echte Benutzerkennzahlen angesprochen. Ich habe gerade bei Odnoklassniki gearbeitet und wir hatten Probleme damit, dies zu verfolgen, da nicht klar ist, wie es geht, und die Volumina groß sind. Wir haben unsere eigenen geschrieben und von Benutzern gesammelt, und es war nur eine Art Chaos. Und wenn es sich immer noch um ein durchschnittliches Projekt handelt, was kann auf der Benutzerseite gemessen werden? Nur window.performance oder etwas anderes empfohlen? Oder eine knifflige Taktik anwenden, um echte Benutzerkonten zu beschießen?
Ivan: Zunächst einmal gibt es wahrscheinlich vorgefertigte Bibliotheken oder Dienste, mit denen Sie RUM konfigurieren können. Fügen Sie der Seite beispielsweise eine Zeile hinzu, und die Verfolgung beginnt. Zweitens ist in modernen Browsern so etwas wie PerformanceObserver aufgetaucht - dies ist eine API, die alle möglichen Dinge in Browsern misst und es Ihnen ermöglicht, die Metriken herauszufinden, die der Browser normalerweise enthält, einschließlich des ersten inhaltlichen Malens , des ersten aussagekräftigen Malens und all dem. Und um diese Metrik herauszufinden, reichen nur ein paar Codezeilen aus. Sie müssen nichts überkompliziertes schreiben. Ich habe die Ereignisse abonniert, erhalten und getadelt.
Dmitry: Und worauf ist es am wichtigsten, zuerst zu achten? First Paint , Zeit für Interaktivität , Zeit für das erste Byte , etwas anderes?
Ivan: Ich habe gerade darüber [es gibt einen Bericht] ( https://www.youtube.com/watch?v=-H1l9XBXH6Q ) und ich sage Ihnen, dass die wichtigsten Dinge, die Sie sich ansehen müssen, die erste sinnvolle Farbe und die Zeit für die Interaktion sind. Und sie sind genauso wichtig, wie sie genau zeigen, wofür der Benutzer zuerst gekommen ist. Er kam entweder, um etwas zu lesen oder zu sehen, dann ist dies die erste sinnvolle Farbe, oder um mit der Anwendung zu arbeiten, dann ist es Zeit für Interaktivität. Wenn Sie eine Art Landing Page oder News-Site erstellen, optimieren Sie die erste aussagekräftige Farbe. Wenn Sie eine komplexe Anwendung haben, optimieren Sie die erste aussagekräftige Farbe und die Zeit für die Interaktion.
Artyom: Wir haben die beliebtesten Fälle in Ihrer Praxis erwähnt. Und welche Fälle sind die seltensten oder interessantesten, in denen man sich irgendwo in den Bauch graben musste?
Ivan: Ich denke, ich habe jetzt einen ziemlich interessanten Fall. Ich arbeite zurzeit mit Framer . Diese Jungs haben ein modisches Design- Tool , ein Analogon zu Figma und Sketch . Und ich helfe ihnen dabei, die Laufzeitleistung zu verbessern - dies ist im Allgemeinen eine sehr interessante Zone für mich. Sie verwenden den Browser super spezifisch. Browser waren ursprünglich nicht für das Schreiben derart komplexer Anwendungen konzipiert, daher implementieren sowohl Figma als auch Framer viele Browserteile selbst neu. Und es gibt viele ihrer Entwicklungen, die sich nicht auf andere Projekte beziehen und die sehr interessant sind. Ich arbeite gerne mit all dem. Das ist wirklich etwas Interessantes, etwas Neues und sehr Cooles.
Dmitry: Wir haben über die wichtigsten Nuancen des Browsers gesprochen, und bevor ich zu den Frameworks übergehe, möchte ich etwas über die Leistungsoptimierung mithilfe der Architektur und einiger Datenstrukturen lernen. Mussten Sie etwas so Gründliches in der Anwendung ändern, zum Beispiel eine Präfixliste für die Suche hinzufügen oder etwas anderes, das für das Frontend nicht sehr üblich ist? Passiert das?
Ivan: Ich habe praktisch nicht auf der Ebene der Datenstrukturen oder der algorithmischen Komplexität gearbeitet, da viele Dinge getan werden müssen, damit die Anwendung dies verlangsamt, und nicht etwas anderes. In Bezug auf große Teile kann ich es jedem empfehlen, wenn Sie ein neues Projekt erstellen oder wenn das Projekt gerade erst begonnen hat und es noch recht klein ist, tun Sie es in einem Framework wie Next.js oder Gatsby .
Sowohl das als auch das andere ist ein Framework für React, das so aufgebaut ist, dass Sie einfach eine Anwendung mit zwei Ansätzen dieses Frameworks geschrieben haben, und es wurde automatisch schnell. Und das sind sehr beliebte Frameworks, sie machen ihre Arbeit perfekt, ich selbst benutze sie in meinen Produktionsprojekten und kann sie jedem nur empfehlen.
Artem: Gerade hier hatten wir kürzlich einen Vorfall im Zusammenhang mit der Deoptimierung der Reaktion des V8 aufgrund des Number-Geräts im V8. Haben Sie dieses Problem gespürt oder wurde gesucht, warum die Anwendung langsamer wird?
Ivan: Ich habe diesen Artikel über Deoptimierung nicht gefühlt und nicht gelesen. Gab es eine bestimmte Operation oder verlangsamte sich die gesamte Reaktion insgesamt?
Artyom: Im Allgemeinen gibt es in React einen Zeitstempel in FiberNode, der ursprünglich auf 0 gesetzt und die Erweiterung verhindert wurde (PreventExtension). Dazu wurde eine Form mit einer kleinen Ganzzahl zugewiesen, um Operationen für Zahlen zu optimieren. Und als sich der Zeitstempel mit dem realen Wert füllte, der über 128 hinaus stieg, stellte sich heraus, dass die Struktur von einer kleinen Ganzzahl in eine veränderbare Heap-Nummer geändert werden musste, und da PreventExtension aufgerufen wurde, wurden für jeden Faserknoten völlig neue Formen erstellt. Und es gibt Zehntausende und Hunderttausende.
Ivan: Ich habe das nicht bemerkt, und ich hätte es kaum bemerkt, denn wenn ich debugge, habe ich keine in meinem Gedächtnis, dass dieser Vorgang in React nur 10 ms und 20 Minuten dauern sollte. Ich debudiere nur, ich beobachte die Leistungsverfolgung. Ich wähle einen Engpass aus, bei dem sich etwas verlangsamt. Wenn die Leistung verteilt ist, gibt es in V8 einige Verzögerungen, die gleichmäßig in der gesamten Anwendung verteilt sind. Wenn ich dann nicht zu sehr tiefen Debugs gehe, werde ich es nicht bemerken.
Wenn dies in einem deoptimierten V8-Vorgang geschieht und es lange dauert, werde ich es bemerken und mich eingehend mit dem Debuggen befassen.
Artyom: Gab es wirklich ein Problem mit React selbst oder mit anderen Frameworks, bei denen Sie ein Problem erstellen mussten, um etwas auf den Grund zu gehen?
Ivan: Meiner Meinung nach habe ich einige Fehler gemeldet, aber ich erinnere mich nicht an die Details ... Ich glaube nicht, ob dies für dieses Problem relevant wäre, aber ich bin kürzlich auf einen interessanten Fall gestoßen, als sich herausstellte, dass CSS-Variablen langsamer sind als das Ändern von Anwendungen durch React Prop. Und für mich fühlt es sich seltsam an, weil wir immer gesagt haben, dass CSS superschnell ist und dann plötzlich viel langsamer funktioniert als React.
Ich versuche, einen Artikel darüber hinzuzufügen, und im Allgemeinen funktioniert dies so, da es in Browsern keine Optimierung gibt. Wenn Sie die CSS-Variable für ein Element mit vielen untergeordneten Elementen ändern, merkt sich der Browser, zumindest Chrome, nicht, welche Kinder verwenden diese Variable und sie berechnet alle Kinder und Stile für sie. Wenn es viele Stile und Knoten gibt - es ist viel Zeit, und wenn Sie eine Variable durch React ersetzen, kann es sein, dass die Berechnung von Stilen nicht erfolgt und alles schnell geht.
Ich bin zu 80% sicher, dass dies so ist, wie ich es aus dem V8-Code verstanden habe, aber ich kann mich irren. Aber dies ist eine Sache, die in Browsern registriert und repariert werden könnte, aber dies ist kein Mikrobug, vielleicht gibt es viel Arbeit. Ich habe es noch nicht gemeldet und weiß nicht, wie viel Zeit für die Reparatur aufgewendet wird, wenn ich es repariere.
Artyom: Mussten Sie den resultierenden Bytecode beobachten? Mit den gleichen Ansichten der Deoptimierung beobachten Sie den V8-Bytecode, und gibt es zusätzliche Operationen, die eingefügt werden?
Ivan: Nein, ich habe mich wahrscheinlich noch nie mit Bytecode befasst, aber ich habe ziemlich gut gelernt, minimiertes JavaScript zu lesen. (lacht)
Dmitry: Und zur vorherigen Antwort: Kommunizieren Sie irgendwie mit Browser-Entwicklern, um solche Dinge zu klären? Und wenn ja, wie reagieren sie? Und antworten sie?
: GDE (Google Developer Expert), Google- Slack-, Google-, Chrome. - , . , . . .
: ! .
: , Google, GDE ().
: :)
: , , , .
: , Moment.js. , , Day.js -, bundlephobia . , , , Angular, .
, , , , , , , , . ? , issue , ? , ?
: … . - , , . - , , userspace- .
, .
, , , - . webpack - . React, , API Preact , Inferno .
: ? , , , , Vue.js, , , . -?
: , . , , Angular, Angular. Angular, , . … , , . - Ext JS .
, . , . , .
WebAssembly
: , - JS, , high computation . WebAssembly, computational ?
: , WebAssembly - , .
: , , WASM. Figma, Blazor, C# WebAssembly, - . ?
: , - WebAssembly . , c WebAssembly , . .
: ?
: , . -, JavaScript - , WebAssembly , , 10 .
, , JavaScript, C++ Rust — WebAssembly . , , .
: . scroll, , . - - ? , Chrome iOS - ChromeOS - , - ? , , «.»?
: , performance IE11. , - , , IE11. , . IE11.
. «.» Chrome iOS , «.» Chromium, Chrome iOS — WebKit, iOS
: , … ()
HTTP/3
: , , . . HTTP/2, HTTP/3, QUIC . , : HTTP/2 , ?
, HTTP/3 ?
: HTTP/3 ?
: , Chrome , cURL, .
: , . , , , , HTTP/3 . Google , HTTP/3, , HTTP/3.
, , HTTP/2 , , , 2-3 , , HTTP/2 . HTTP/3 . , - , .
: , , ? , , - ?
: -, Twitter, (, []( https://twitter.com/slightlylate ), []( https://twitter.com/zachleat ), []( https://twitter.com/csswizardry ), []( https://twitter.com/igrigorik ), []( https://twitter.com/philwalton )). - Google GDE , - - performance-. .
, Calibre ( performance-) Perf.email , performance-.
: GDE! , - , . , , , ? , .
: , Service License Agreement , 95% . , performance . Juliarderity , , , . , .
: « », , . ? React, Angular .. — framework-specific , , ? TC39?
: (). , — , — .
: ?
: - . proposal, , . proposal, - . — .
: , RSS? - .
: RSS.
: , Habr, « Chrome», RSS . RSS , .
: , -, , , DevTool-, , - , , , .
: , ?
: Twitter, , -, Twitter, 20-30 . , « @vkozula ?».
, « , ». - . . , . , . Facebook- , - 50 , , .
: jsunderhood - ?
: underhood. - , . underhood, — jsunderhood 2017 , , , , , , .
: , , HolyJS jsunderhood, .. . ? , ?
: , , . , , , … , , . 10—20 .
: , ?
: , , , , , , , , . , , , Twitter , , . - Twitter Telegram , , .
Artyom: Wenn wir zu einer anderen Aktivität übergehen, die Sie nicht erwähnt haben. Sie leiten Workshops, Sie scheinen viel Erfahrung damit zu haben. Welche öffentlichen Workshops halten Sie für gut, die einen Blick wert sind, und glauben Sie selbst, dass sie die Inhalte als Ganzes erfolgreich präsentiert haben und die Besucher zufrieden waren?
Ivan: Ich hatte nicht so viele Workshops in absoluter Menge, aber was mich am meisten stolz macht, ist mein Webpack-Workshop , den ich Ende 2017 als Einführung in Webpack durchgeführt habe. Leider ist es bereits veraltet, aber es stellte sich als cool heraus, weil ich vorhatte, eine Online-Sendung durchzuführen, aber an diesem Tag begann ich, dem Internet wild hinterherzuhinken.
Ich fing an zu führen, nach 10 Minuten fiel ich ab, stellte die Verbindung wieder her, fiel wieder ab und ich musste dringend alles abbrechen, mich entschuldigen und sagen, dass ich das gesamte Material auf Video aufnehmen und alles so platzieren würde. Ich habe alles gemacht, es rausgebracht , es hat sich eine Reihe von Videos wie auf egghead.io herausgestellt , und mit Ausnahme des Problems, dass es einen sehr leisen Ton gab, weil es kein normales Mikrofon gab. Ich habe viele Bewertungen gehört, was sehr gut war und den Leuten wirklich geholfen hat.
Dmitry: Was denkst du, warum lohnt es sich, Workshops zu besuchen? Wenn Sie zum Beispiel mit einem Browser zu einem Workshop gegangen sind, höre ich oft, dass die Leute sehen wollen, wie der V8 entkernt ist oder etwas anderes. Und im Westen hingegen, wenn Sie sich an das coole Interview mit Michel Weststrate erinnern, sagte er: „Ich werde von ihnen lernen. Wenn ich Docker überhaupt nicht kenne, gehe ich dorthin und erhalte schnell Informationen. " Wie sehen Sie Workshops und in welchen Fällen empfehlen Sie die Teilnahme an Ihren Workshops? Lernen, Wissen vertiefen, Mut sehen?
Ivan: Ich würde das sagen - wenn Ihnen die Beschreibung interessant erscheint, dann kommen Sie. Wenn ich Workshops mache, versuche ich immer, eine Grundlage zu geben, damit die Leute, die zum ersten Mal damit arbeiten, nicht verloren gehen. Ich kann mir vorstellen, dass einige der Jungs, die in Super Advanced arbeiten, gekommen sind, um zuzuhören, vielleicht ist der Anfang langweilig. Sie bleiben möglicherweise nicht bis zum Ende, an dem ein fortgeschrittenes Thema angesprochen werden kann. Andererseits kann ich nicht versprechen, dass ich etwas Mut zeigen werde, da alle Menschen ein anderes Verständnis von „Mut“ haben. Ich werde kommen und einige super seltene Fälle zeigen, auf die ich in meiner Erfahrung gestoßen bin, und jemand anderes kann kommen und hoffen, dass ich den V8 debütiere oder Chromium kompiliere, aber ich werde es nicht tun.
Dmitry: Und was erwarten Sie selbst im Prinzip normalerweise von einem Workshop?
Ivan: Ich erinnere mich, dass ich in meinem Leben nur ein paar Workshops besucht habe. Beide Male war es ein neues Thema für mich, das ich immer noch nicht selbst herausfinden konnte. Und die Workshops waren eine Art Einführung für mich und es war super nützlich.
In meinem Workshop werde ich keine Einführung in die Performance geben und in React erwarte ich, dass die Leute, die kommen, um etwas darüber zu hören, aber ich versuche, einige grundlegende Themen zu behandeln und ein fortgeschrittenes Debugging zu zeigen Ich kenne ihn und bin auf ihn gestoßen.
Dmitry: Was erwarten Sie von HolyJS insgesamt? Vielleicht habe ich einige Berichte oder Redner bemerkt, mit denen ich gerne sprechen würde?
Ivan: Ich plane nichts mehr als einen Monat im Voraus für mich, also habe ich noch nichts geplant. Es gibt Vorbereitungen, und der Rest wird passieren. (lacht)
Dmitry: Das ist alles. Vielen Dank für das Interview. Wir warten auf alle in Ihrer Werkstatt .