Ivan Akulov adalah Ahli Pengembang Google di teknologi web dan pendiri perusahaan kinerja PerfPerfPerf . Segera, di HolyJS 2019 Moscow, ia akan mengadakan lokakarya yang didedikasikan, anehnya, untuk masalah pencarian kinerja di Bereaksi, men-debug aplikasi yang lambat dan hal-hal runtime lainnya.
Untuk pembaca dan pengunjung HolyJS 2019 Moscow yang lebih dalam dalam topik ini, kami berdiskusi dengan Ivan:
- Masalah kinerja yang paling populer;
- Bagaimana mengukur kinerja dan apa masalahnya;
- Cara mengoptimalkan kinerja;
- Cari masalah kinerja di Bereaksi;
- Manfaat beralih ke HTTP / 2 dan HTTP / 3;
- Lebih baik menggunakan kerangka kerja kompak pada proyek-proyek baru;
- Tentang manfaat WebAssembly;
- Di mana mencari informasi kinerja yang berguna;
- Tentang apa bengkelnya dan siapa yang akan tertarik untuk datang ke sana (dan mengapa pergi ke bengkel sama sekali).
Pertanyaan diajukan oleh Dmitry Makhnev dan Artyom Kobzar dari komite program HolyJS.
Dmitry: Ceritakan beberapa hal tentang diri Anda.
Ivan: Saya Ivan Akulov, konsultan kinerja, Ahli Pengembang Google, melakukan agen konsultasi kinerja saya.
Dmitry: Anda mengatakan bahwa agen konsultan bukanlah pekerjaan utama. Tetapi pada dasarnya apa yang Anda lakukan?
Ivan: Waktu saya sekarang didistribusikan kira-kira sehingga saya setengah penuh dengan pekerjaan dengan satu klien lama. Saya bekerja dengan satu perusahaan Brasil, bersama-sama kita menciptakan platform pemasaran konten Wordpress, saya mengelola infrastruktur di sana dan sedikit pengembangan produk, dan semacam visi bersama.
Sisa waktu saya habiskan untuk konsultasi, pidato, artikel dan semua itu.
Dmitry: Apakah ada banyak permohonan untuk konsultasi kinerja? Bagaimana cara kerjanya?
Ivan: Secara umum, itu sangat tergantung pada bulan atau sesuatu seperti itu ...
Dmitry: Kapan astrolog mengumumkan bulan kinerja? :)
Ivan: Sebaliknya, ketika akuntan mengumumkan kuartal baru! (tertawa). Saya tidak aktif mencari klien sekarang, alasan utama adalah tidak ada waktu untuk ini sekarang, karena saya sudah sarat dengan apa yang saya miliki. Tetapi secara umum, semuanya terlihat seperti saya menulis beberapa artikel, berpidato, dan ketika bekerja dengan beberapa klien, mereka mengingat saya dan merekomendasikan saya yang baru. Kebanyakan orang datang berkat jaringan, dan cowok keren datang.
Artyom: Bagaimana Anda sampai pada tema kinerja sebelum Anda membuat perusahaan konsultan sendiri?
Ivan: Sebenarnya, semuanya dimulai dengan fakta bahwa kami pernah menulis ulang proyek lama di Epam selama setengah tahun menggunakan wepback. Ada proyek lama dengan banyak warisan, dengan kerangka front-end sendiri, setengahnya bekerja di tumpukan java. Dan karena kami menghabiskan setengah tahun membuat webpack relatif cepat, saya mendapatkan pengalaman dengan webpack. Dan pada saat itu saya bisa menulis webpack-config kompleksitas sedang, garis 20-40, secara harfiah dari memori, tanpa googling apa pun, tanpa mengintip dan bahkan tanpa menggunakan IntelliSense.
Dan saya menyadari bahwa pengalaman seperti itu dapat bermanfaat bagi orang lain, saya memutuskan untuk mencoba memulai semacam konsultasi di bidang webpack. Saya membuat pendaratan untuk diri saya sendiri, mempostingnya di suatu tempat, beberapa orang datang, saya bekerja dengan salah satu dari mereka. Dan entah bagaimana semuanya dimulai.
Dan kemudian, saya lancar mengalir dari kinerja terkait webpack untuk konsultasi kinerja secara umum.
Artyom: Apakah Anda berhasil meningkatkan kinerja perakitan pada proyek itu?
Ivan: Proyek itu tidak berhasil dengan baik, bukan pada akhirnya saya ingin melakukannya. Itu adalah hal yang terjadi ketika mereka datang pada saat saya benar-benar membutuhkan uang dan masih tidak mengerti bagaimana cara bernegosiasi, mengurus diri sendiri dan mempertimbangkan minat saya dalam negosiasi ini. Saya menyarankan beberapa harga tetap kecil dengan jumlah pekerjaan yang tidak aman, kami bekerja, saya membantu mereka, membuat beberapa keputusan yang sepertinya berhasil, dan memperbaiki kinerjanya.
Lalu ternyata ada bug dalam solusi ini, ternyata terlalu rumit dan bug aneh muncul dalam kasus tepi yang langka. Kami mulai memperbaikinya, saya memperbaiki satu, kedua, ketiga bug, semua ini berlangsung selama sebulan. Dan pada akhirnya, di beberapa titik, bug berhenti terjadi, tetapi orang-orang memutuskan untuk meminta saya untuk sesuatu yang lain, tetapi karena saya memiliki anggaran internal untuk ini, semuanya sudah selesai, saya hanya berkata: "Maaf, saya sudah dimuat, dan tidak Saya bisa membantu. "
Hasilnya, sejauh yang saya ketahui, dalam beberapa bulan mereka mengganti solusi ini dengan yang lain, yang tidak terlalu rumit dan bekerja dalam 100% kasus.
Sejujurnya, saya tidak mengenal diri saya sendiri ... Sepertinya saya datang dan membantu, dan keputusan akhir yang mereka buat terlahir dalam percakapan kami sebelumnya, tetapi saya tidak tahu seberapa banyak mereka membantu apa yang saya lakukan. Dan betapa puasnya mereka dengan ini semua. Singkatnya, itu tidak sesempurna yang saya inginkan.
Artyom: Dan berbicara tentang hari ini, apakah Anda entah bagaimana melacak klien masa lalu, bagaimana keadaan mereka di sana, apakah itu semua membantu?
Ivan: Ya, tentu saja. Saya secara bertahap mengembangkan beberapa pendekatan. Pertama, di akhir pekerjaan saya, saya mencoba untuk mendapatkan umpan balik publik dari setiap klien, yang dapat diposting di situs atau diposting di suatu tempat.
Kedua, saya mengembangkan pendekatan untuk menanyakan klien pada proses atau akhir pekerjaan pertanyaan "Bagaimana Anda puas dengan proses saat ini, alur kerja saat ini, sesuatu saat ini?" dengan opsi jawaban "lebih dari puas", "puas", "hampir puas", "tidak benar-benar puas".
Dan saya suka pertanyaan ini, karena memberikan jawaban spesifik, dan bukan skala konyol dari 1 hingga 5, yang semua orang rasakan dengan cara mereka sendiri. Sejauh ini, tidak ada klien yang menjawab "hampir puas" atau "tidak benar-benar puas". Puas, Senang, dan semacamnya.
Artyom: Apakah saya mengerti benar bahwa bidang keahlian Anda dalam kinerja terutama ditujukan pada sisi klien? Atau apakah Anda memiliki seluruh tumpukan web secara keseluruhan dipengaruhi oleh konsultasi?
Ivan: Ya, bidang keahlian terutama ditujukan pada tumpukan klien, dengan optimasi kinerja di backend atau dalam database, saya bekerja lebih sedikit. Namun dalam praktiknya, jika aplikasi web melambat, bahkan beberapa artikel atau penelitian, bahwa 80-90% kasus - justru melambat karena front-end.
Jika klien datang dan sesuatu melambat, dalam banyak kasus keahlian saya tepat.
Tentang masalah paling populer
Artyom: Dan apa yang terjadi ketika ada beberapa kasus tepi? Ketika kita memiliki masalah bukan dengan parsing JavaScript dan peluncurannya, tetapi masalah dengan transportasi. Ketika interaksi pertama ditugaskan ke klien, serta ke backend. Sangat norak bahwa gzip dibuat secara tidak benar; berputar terlalu lama. Apa yang Anda lakukan dalam kasus ini? Dan jika analisis Anda terutama di garis depan, bagaimana Anda menemukan kasus-kasus seperti itu?
Ivan: Ya, ini biasanya berarti waktu respons dari server menjadi terlalu lama. Jika saya perhatikan ini selama beberapa jenis audit, saya mencari di devtools, mencari di jaringan dan melihat bahwa waktu dari server adalah 800 ms - untuk menjadi gila, butuh waktu terlalu lama. Dan saya akan mencoba memahami bagaimana orang-orang memiliki server, apa yang mereka lakukan selama setiap jawaban. Jika ini JavaScript atau PHP, kemungkinan besar saya akan dapat mengatasinya dengan baik dan memperbaiki semuanya, jika beberapa bahasa lain yang saya tidak gunakan mungkin membutuhkan bantuan mereka.
Dmitry: Dapatkah Anda menyebutkan salah satu dari 5 masalah kinerja paling umum yang dihadapi dalam praktik?
Ivan: Saya akan mengikuti cara saya mengingat. Salah satu masalah umum yang terjadi bukan pada aplikasi web yang kompleks, tetapi pada situs sederhana adalah ketika pengembang atau klien meletakkan banyak skrip di dalam tag kepala tanpa atribut async atau defer , dan ini buruk karena browser tidak dapat mulai merender halaman sampai tidak akan memuat dan menjalankan skrip ini.
Dan jika ada server lambat atau skrip besar yang membutuhkan waktu lama untuk dieksekusi, maka orang yang menggunakan situs tersebut tidak akan melihat halaman sampai akhir eksekusi.
Masalah umum lainnya adalah skrip pihak ketiga. Saat ini saya sedang bekerja dengan klien yang saya bantu untuk meningkatkan skor mercusuar mereka. Awalnya, skor mercusuar yang mereka miliki adalah sekitar 35-40. Saya datang, melakukan segala macam hal yang berbeda, menghapus JavaScript yang tidak perlu, sumber daya pemblokiran render, dioptimalkan entah bagaimana ... Setelah semua yang saya lakukan, skornya hanya naik menjadi 55. Dan ternyata jika Anda menggunakan halaman yang dioptimalkan ini dan berkomentar satu komponen Bereaksi tunggal yang memuat semua analitik, skor mercusuar melompat di suatu tempat hingga 88-90 + poin. Ini terjadi karena ada begitu banyak JS yang menghapus metrik.
Dalam beberapa aplikasi web yang kompleks, topik yang sering muncul adalah ketika pengembang menginstal semacam perpustakaan besar dan bundel ke dalam bundel sepenuhnya, meskipun tidak digunakan sepenuhnya. Seringkali ini adalah Moment.js , di mana ada file pelokalan besar, 165 KB file pelokalan yang diperkecil yang hampir tidak diperlukan, atau lodash , di mana ada banyak metode, dan semuanya hanya menggunakan 10-20.
Dengan kinerja rendering, biasanya ada masalah yang sering terjadi ketika pengembang menutup beberapa jenis pengendali acara, misalnya, pada gulir acara, butuh 5-10 ms, dan setiap kali Anda mencoba menelusuri sesuatu, seluruh halaman tertinggal. Sekarang ini menjadi kurang, karena di Chrome yang sama [ditambahkan pendengar acara pasif] ( https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ).
Tentang cara mengukur kinerja
Dmitry: Dalam beberapa kasus, sebuah pertanyaan tentang Lighthouse muncul. Menurut pendapat saya, ketiganya berada di BeerJS Summit , dan ada laporan keren - (keseratus) dari Alexey Kalmakov . Tidak ada entri , tetapi saya melihat artikel serupa tentang Habré , dan hal-hal semacam itu sedikit mengganggu Mercusuar. Jika Anda menganggapnya murni sebagai alat untuk mengevaluasi pekerjaan seorang insinyur kinerja, Anda dapat melakukan beberapa trik di sana.
Apakah Anda memiliki alat, mungkin yang ditulis sendiri, yang dengannya Anda menilai dengan jelas apakah Anda berhasil atau tidak. Misalnya, Anda menandatangani kontrak dan Anda diberitahu bahwa Anda perlu membuat kinerja x2. Perangkat apa yang akan Anda gunakan untuk ini?
Ivan: Ya, pertama, jika kita menyimpulkan kontrak dan menyetujui x2, maka kita akan menyetujui beberapa jenis instrumen. Namun secara umum, selain Lighthouse, saya sangat suka WebPageTest . Ini adalah alat kinerja web canggih yang sangat keren yang memungkinkan Anda menguji aplikasi Anda dari lokasi sewenang-wenang nyata, misalnya, Brasil atau Australia, pada perangkat nyata, misalnya, perangkat yang sangat lemah, seperti Moto G.
Ini lebih keren daripada Mercusuar, karena ini mengemulasi semua ini, dan hanya setelah pengujian pada perangkat nyata Anda tahu bahwa situs ini render selama 15 detik. Manfaat kedua - ini memberi banyak metrik super rinci dari semua jenis grafik, seperti memuat. Saya menggunakannya secara teratur untuk melihat beberapa hal.
Dmitry: Sudahkah Anda menulis alat apa pun, misalnya, di atas Protokol Chrome DevTools ? Apa yang kurang dari alat?
Ivan: Saya menulis instrumen saya di atas Mercusuar. Untuk bekerja dengan salah satu klien, saya membutuhkan pengaturan yang akan memungkinkan saya untuk mengukur kinerja satu halaman dengan Mercusuar di lingkungan yang cukup stabil, anggap itu skor mercusuar dan salin ke meja. Ada masalah dengannya: Mercusuar di PageSpeed Insights tidak terlalu stabil. Jika Anda mengukur halaman yang sama tiga kali, Anda bisa mendapatkan tiga pengukuran berbeda. Selain itu, saya perlu mengukur bukan halaman yang siap dan dipublikasikan di jaringan, tetapi halaman lokal. Dan satu-satunya pilihan adalah menjalankan Lighthouse secara lokal, yang juga sangat mempengaruhi skor mercusuar, karena Skor mulai tergantung pada apa yang berfungsi pada laptop Anda. Misalnya, meluncurkan Docker, skor turun 2 kali.
Untuk kasus ini saya perlu mengukur Lighthouse dengan mudah. Saya menulis sebuah skrip yang menjalankan Lighthouse tiga kali, skor, mengambil nilai median tiga kali, dan melakukannya untuk banyak halaman dengan banyak pengaturan. Saya menyewa server DigitalOcean untuk ini dan menjalankan semua yang ada di sana untuk membuatnya terisolasi dari faktor eksternal.
Artyom: Anda menyebutkan kasus menarik tentang metrik Mercusuar yang berbeda. Ada artikel baru-baru ini, Pengantar 99 persentil untuk programmer , di mana mereka hanya menyimpulkan bahwa alat pembandingan modern dan, pada prinsipnya, pembandingan mikro saja tidak membuktikan apa-apa.
Dengan alat-alat modern, mungkin saya membuat patokan, Anda menulis, tulis Dima, dan mereka semua akan mengatakan hal-hal yang sama sekali berbeda. Dan sekarang di dunia tanpa pengetahuan yang kurang lebih mendalam dalam teori dan statistik, pembandingan tampaknya tidak masuk akal. Anda menyebut Lighthouse, tetapi apakah ada bukti yang Anda terima di benchmark, beberapa konfirmasi tambahan?
Dmitry: Mungkin mencampur Mercusuar dengan sesuatu? Anda menyebutkan WebPageTest. Kami mengambilnya, bahkan mungkin pengamatan dari Chrome DevTools, dan entah bagaimana mencampurnya?
Ivan: Sebenarnya, idealnya, jika ada sesuatu pada proyek yang memungkinkan Anda untuk melacak RUM (metrik pengguna nyata) - seberapa nyata situs memuat untuk beberapa pengguna, dan jika kami dapat meluncurkannya ke pengguna nyata dan melihat bagaimana itu bekerja untuk mereka - ini kasus yang sempurna.
Tetapi secara umum, ya, jika saya menggunakan beberapa jenis alat, saya benar-benar menjalankan lebih dari satu tes untuk mendapatkan nilai median, tetapi secara umum artikel tersebut memunculkan masalah nyata bahwa ada semacam persentil ke-99 pengguna yang memiliki segalanya sangat itu buruk dan kami tidak tahu apakah kami hanya menggunakan Lighthouse, tetapi ini tidak mengatakan bahwa Lighthouse tidak berguna, itu terus bekerja dan menunjukkan suhu rata-rata di rumah sakit. Jika secara keseluruhan kami telah meningkatkan kinerja, Lighthouse akan menunjukkannya.
Dmitry: Anda menyentuh metrik pengguna nyata. Saya baru saja bekerja di Odnoklassniki dan kami memiliki masalah dengan cara melacak ini, karena tidak jelas bagaimana melakukannya, dan volumenya besar. Kami menulis milik kami sendiri dan dikumpulkan dari pengguna, dan itu hanya semacam kekacauan. Dan jika itu masih semacam proyek rata-rata, apa yang bisa diambil untuk mengukur sisi pengguna? Hanya window.performance atau sesuatu yang direkomendasikan? Atau gunakan beberapa taktik rumit, menembaki akun pengguna nyata?
Ivan: Pertama-tama, mungkin ada perpustakaan atau layanan yang siap pakai yang memungkinkan Anda untuk mengkonfigurasi RUM. Misalnya, tambahkan satu baris ke halaman dan itu akan mulai melacak. Kedua, di peramban modern, sesuatu yang disebut PerformanceObserver telah muncul - ini adalah API yang mengukur semua jenis hal di peramban dan memungkinkan Anda untuk mengetahui metrik yang biasanya dipegang oleh peramban, termasuk cat pertama yang mengandung konten , cat pertama yang bermakna dan semua itu. Dan untuk mengetahui metrik ini, cukup beberapa baris kode saja, Anda tidak perlu menulis sesuatu yang terlalu rumit. Saya berlangganan acara, menerimanya dan mencaci maki itu.
Dmitry: Dan apa hal terpenting yang harus diperhatikan pertama-tama? Paint Pertama , waktu untuk interaktif , waktu ke byte pertama , sesuatu yang lain?
Ivan: Saya baru saja [ada laporan] ( https://www.youtube.com/watch?v=-H1l9XBXH6Q ) dan saya memberitahu Anda bahwa hal yang paling penting untuk dilihat adalah cat pertama yang bermakna dan waktu untuk interaktif. Dan mereka sama pentingnya dengan mereka menunjukkan apa yang pertama kali datang untuk pengguna. Dia datang entah untuk membaca atau melihat sesuatu, maka ini adalah cat pertama yang bermakna, atau untuk bekerja dengan aplikasi, maka sekarang saatnya untuk interaktif. Jika Anda membuat semacam halaman arahan atau situs berita, maka optimalkan cat pertama yang bermakna, dan jika Anda memiliki aplikasi yang kompleks, maka optimalkan cat pertama yang bermakna dan waktu untuk interaktif.
Artyom: Kami menyebutkan kasus paling populer dalam praktik Anda. Dan kasing mana yang paling langka atau paling menarik, di mana Anda harus menggali isi perutnya di suatu tempat?
Ivan: Saya pikir saya punya kasus yang agak menarik sekarang. Saat ini saya bekerja dengan Framer . Orang-orang ini memiliki alat desain yang modis, analog dengan Figma dan Sketsa . Dan saya membantu mereka meningkatkan kinerja runtime - ini umumnya merupakan zona yang sangat menarik bagi saya. Mereka menggunakan browser yang sangat spesifik. Browser pada awalnya tidak dirancang untuk menulis aplikasi yang sedemikian rumit, sehingga baik Figma maupun Framer mengimplementasikan kembali banyak browser itu sendiri. Dan ada banyak perkembangan mereka, yang tidak pada proyek lain, dan yang sangat menarik. Saya menikmati bekerja dengan semua ini. Ini benar-benar sesuatu yang menarik, sesuatu yang baru dan sangat keren.
Dmitry: Kami berbicara tentang nuansa browser dasar, dan sebelum beralih ke kerangka kerja, saya ingin belajar tentang pengoptimalan kinerja menggunakan arsitektur, beberapa struktur data. Apakah Anda harus mengubah sesuatu yang begitu teliti dalam aplikasi, misalnya, menambahkan daftar awalan untuk pencarian atau sesuatu yang lain yang tidak biasa untuk frontend? Apakah ini terjadi?
Ivan: Saya praktis tidak bekerja di tingkat struktur data atau kompleksitas algoritmik, karena banyak hal harus dilakukan agar aplikasi melambat dalam hal ini, dan bukan sesuatu yang lain. Jadi, mengenai potongan besar, saya sangat merekomendasikan kepada semua orang ketika membuat proyek baru atau jika proyek baru saja dimulai dan masih cukup kecil, lakukan pada kerangka kerja seperti Next.js atau Gatsby .
Baik itu dan yang lain adalah kerangka kerja untuk Bereaksi yang dibangun sehingga Anda cukup menulis aplikasi menggunakan sepasang pendekatan kerangka ini, dan secara otomatis menjadi cepat. Dan ini adalah kerangka kerja yang sangat populer, mereka melakukan pekerjaan mereka dengan sempurna, saya sendiri menggunakannya dalam proyek-proyek produksi saya dan sangat merekomendasikannya kepada semua orang.
Artem: Di sini baru-baru ini kami memiliki insiden yang terkait dengan bagaimana V8 deoptimized Bereaksi karena perangkat Number di dalam V8. Apakah Anda merasakan masalah ini atau apakah ada pencarian mengapa aplikasi melambat?
Ivan: Saya tidak merasa dan tidak membaca artikel ini tentang deoptimisasi. Apakah ada operasi khusus atau memperlambat keseluruhan Bereaksi secara keseluruhan?
Artyom: Secara umum, karena dalam Bereaksi, ada cap waktu di dalam FiberNode, dan pada awalnya diatur ke 0 dan mencegah ekstensi (preventExtension), dan untuk ini, satu bentuk dengan bilangan bulat kecil dialokasikan untuk mengoptimalkan operasi pada angka. Dan ketika stempel waktu diisi dengan nilai nyata, yang naik melampaui 128, ternyata perlu untuk mengubah struktur dari bilangan bulat kecil ke nomor tumpukan yang bisa berubah, dan sejak preventExtension dipanggil, bentuk yang sama sekali baru dibangun untuk setiap simpul serat. Dan ada puluhan dan ratusan ribu.
Ivan: Saya tidak memperhatikan hal ini, dan saya tidak akan menyadarinya, karena ketika saya melakukan debugging, saya tidak memiliki satu di memori saya bahwa operasi ini hanya memakan waktu 10 ms di React, dan itu akan memakan waktu 20. Saya hanya debud, saya menonton jejak kinerja Saya memilih beberapa hambatan di mana sesuatu melambat. Jika kinerja didistribusikan, ada beberapa kelambatan dalam V8 dan didistribusikan secara merata di seluruh aplikasi, maka jika saya tidak masuk ke debug yang sangat dalam, maka saya tidak akan menyadarinya.
Jika ini terjadi dalam satu operasi V8 yang tidak dioptimalkan dan butuh waktu lama, saya akan melihat dan masuk ke debugging yang mendalam.
Artyom: Apakah benar-benar ada masalah Bereaksi sendiri, atau kerangka kerja lain di mana Anda harus membuat masalah, untuk sampai ke dasar sesuatu?
Ivan: Menurut pendapat saya, saya melaporkan beberapa bug, tetapi saya tidak ingat detailnya ... Saya tidak berpikir apakah ini akan relevan dengan masalah ini, tetapi saya baru-baru ini menemukan kasus yang menarik ketika variabel css ternyata lebih lambat daripada perubahan aplikasi oleh React prop. Dan bagi saya rasanya aneh, karena kami dulu mengatakan bahwa css adalah supercepat, dan kemudian tiba-tiba bekerja jauh lebih lambat daripada Bereaksi.
Saya mencoba menambahkan artikel tentang ini, dan secara umum berfungsi seperti itu karena tidak ada optimasi di browser - jika Anda mengubah variabel css pada elemen yang memiliki banyak anak, maka browser, setidaknya Chrome, tidak ingat yang mana anak-anak menggunakan variabel ini dan ia pergi dan menghitung semua anak dan gaya untuk mereka. Jika ada banyak gaya dan node - ini adalah banyak waktu, dan jika Anda mengganti beberapa variabel dengan Bereaksi, maka mungkin perhitungan gaya tidak dapat terjadi dan semuanya akan terjadi dengan cepat.
Saya 80% yakin bahwa ini sesuai dengan apa yang saya mengerti dari kode V8, tapi saya bisa salah. Tapi ini adalah hal yang bisa didaftarkan dan diperbaiki di browser, tapi ini bukan microbug, mungkin ada banyak pekerjaan. Saya belum melaporkannya dan saya tidak tahu berapa banyak waktu yang dihabiskan untuk memperbaikinya jika saya memperbaikinya.
Artyom: Apakah Anda harus menonton bytecode yang dihasilkan? Dengan tampilan deoptimisasi yang sama, Anda menonton bytecode V8, dan apakah ada operasi tambahan yang dimasukkan?
Ivan: Tidak, saya mungkin tidak pernah melihat bytecode, tapi saya cukup belajar membaca JavaScript yang diperkecil. (tertawa)
Dmitry: Dan pada jawaban sebelumnya - apakah Anda entah bagaimana berkomunikasi dengan pengembang browser untuk mengklarifikasi hal-hal seperti itu? Dan jika demikian, bagaimana tanggapan mereka? Dan apakah mereka menjawab?
: 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 , , .
: , . , . , , ?
Ivan: Saya tidak memiliki begitu banyak bengkel dalam jumlah absolut, tetapi yang paling saya banggakan adalah bengkel webpack saya, yang saya lakukan sebagai pengantar webpack pada akhir 2017. Sayangnya, ini sudah ketinggalan zaman, tetapi ternyata keren, karena saya berencana untuk melakukan siaran online, tetapi hari itu saya mulai liar meninggalkan internet.
Saya mulai memimpin, setelah 10 menit saya jatuh, terhubung kembali, jatuh lagi dan saya harus segera membatalkan semuanya, meminta maaf dan mengatakan bahwa saya akan merekam semua materi di video dan meletakkannya seperti itu. Saya melakukan semuanya, ditata, ternyata serangkaian video seperti di egghead.io , dan dengan pengecualian masalah bahwa ada suara yang sangat tenang, karena tidak ada mikrofon normal. Saya mendengar banyak ulasan, yang sangat bagus dan itu sangat membantu orang.
Dmitry: Bagaimana menurut Anda, mengapa layak pergi ke bengkel? Misalnya, jika Anda pergi ke bengkel di peramban, saya sering mendengar bahwa orang ingin melihat bagaimana V8 dimusnahkan atau sesuatu yang lain. Dan di Barat, sebaliknya, jika Anda mengingat wawancara Michel Weststrate yang keren , ia berkata, “Saya akan belajar dari mereka. Jika saya tidak mengenal Docker sama sekali, maka saya pergi ke sana dan mendapatkan informasi dengan cepat. " Bagaimana Anda melihat lokakarya dan dalam hal apa Anda merekomendasikan menghadiri lokakarya Anda? Belajar, memperdalam pengetahuan, melihat nyali?
Ivan: Saya akan mengatakan ini - jika deskripsinya menarik bagi Anda, maka datanglah. Ketika saya melakukan lokakarya, saya selalu berusaha memberikan semacam dasar agar orang-orang yang datang dan bekerja dengannya untuk pertama kalinya tidak hilang. Saya bisa membayangkan bahwa beberapa orang yang bekerja di super maju datang untuk mendengarkan, mungkin awalnya membosankan. Mereka mungkin tidak tetap sampai akhir di mana topik lanjutan dapat dimunculkan. Di sisi lain, saya tidak bisa berjanji bahwa saya akan menunjukkan beberapa nyali, karena semua orang memiliki pemahaman yang berbeda tentang "nyali". Saya akan datang dan menunjukkan beberapa kasus super langka yang saya temui dalam pengalaman saya, dan orang lain dapat datang dan berharap bahwa saya akan memulai V8 atau mengkompilasi Chromium, tetapi saya tidak akan melakukannya.
Dmitry: Dan apa yang Anda sendiri, pada prinsipnya, biasanya harapkan dari lokakarya?
Ivan: Saya ingat saya hanya pergi ke beberapa bengkel dalam hidup saya. Kedua kali, itu adalah beberapa topik baru bagi saya, yang saya masih belum bisa mengetahuinya sendiri. Dan lokakarya adalah semacam pengantar bagi saya, dan itu sangat berguna.
Dalam lokakarya saya, saya tidak akan melakukan pengantar kinerja sama sekali dan dalam Bereaksi, saya berharap bahwa orang-orang yang datang akan mendengar sesuatu tentang itu, tetapi cobalah untuk membahas beberapa topik dasar dan menunjukkan beberapa debugging lanjutan sebanyak Saya kenal dia dan menemukan dia.
Dmitry: Apa yang Anda harapkan dari HolyJS secara keseluruhan? Mungkin saya memperhatikan beberapa laporan atau pembicara yang ingin saya ajak bicara?
Ivan: Saya belum merencanakan apa pun untuk diri saya sendiri lebih dari sebulan sebelumnya, jadi saya belum merencanakan apa pun. Ada persiapan, dan sisanya akan terjadi. (tertawa)
Dmitry: Itu saja. Terima kasih banyak untuk wawancara ini. Kami menunggu semua orang di bengkel Anda .