Tampilan mendalam pada browser web modern (bagian 2)

Mariko Kosaka

Yang terjadi di navigasi

Ini adalah bagian 2 dari seri blog yang terdiri dari 4 bagian yang membahas cara kerja bagian dalam Chrome. Di postingan sebelumnya, kita telah melihat cara berbagai proses dan rangkaian pesan menangani berbagai bagian browser. Dalam postingan ini, kami akan mempelajari lebih dalam cara setiap proses dan thread berkomunikasi untuk menampilkan situs.

Mari kita lihat kasus penggunaan sederhana penjelajahan web: Anda mengetik URL ke browser, lalu browser mengambil data dari internet dan menampilkan sebuah halaman. Dalam postingan ini, kita akan fokus pada bagian tempat pengguna meminta situs dan browser bersiap merender halaman - juga dikenal sebagai navigasi.

Dimulai dengan proses browser

Proses browser
Gambar 1: UI Browser di bagian atas, diagram proses browser dengan UI, jaringan, dan thread penyimpanan di dalamnya di bagian bawah

Seperti yang telah kita bahas di bagian 1: CPU, GPU, Memori, dan arsitektur multiproses, semua hal di luar tab ditangani oleh proses browser. Proses browser memiliki thread seperti UI thread yang menggambar tombol dan kolom input browser, thread jaringan yang berhubungan dengan tumpukan jaringan untuk menerima data dari internet, thread penyimpanan yang mengontrol akses ke file, dan lainnya. Saat mengetik URL di kolom URL, input Anda akan ditangani oleh UI thread proses browser.

Navigasi sederhana

Langkah 1: Menangani input

Saat pengguna mulai mengetik di kolom URL, UI thread pertama yang bertanya adalah "Apakah ini kueri penelusuran atau URL?". Di Chrome, kolom URL juga merupakan kolom input penelusuran, sehingga UI thread perlu mengurai dan memutuskan apakah akan mengirimkan Anda ke mesin telusur, atau ke situs yang Anda minta.

Menangani input pengguna
Gambar 1: UI Thread yang menanyakan apakah inputnya adalah kueri penelusuran atau URL

Langkah 2: Mulai navigasi

Saat pengguna menekan enter, UI thread memulai panggilan jaringan untuk mendapatkan konten situs. Indikator lingkaran berputar pemuatan ditampilkan di pojok tab dan thread jaringan melewati protokol yang sesuai, seperti pencarian DNS dan pembuatan Koneksi TLS untuk permintaan.

Mulai navigasi
Gambar 2: UI thread yang berkomunikasi dengan thread jaringan untuk membuka mysite.com

Pada tahap ini, thread jaringan mungkin menerima header pengalihan server seperti HTTP 301. Dalam hal ini, thread jaringan berkomunikasi dengan UI thread yang diminta oleh server untuk pengalihan. Lalu, permintaan URL lain akan dimulai.

Langkah 3: Baca respons

Respons HTTP
Gambar 3: header respons yang berisi Jenis Konten dan payload yang merupakan data sebenarnya

Setelah isi respons (payload) mulai masuk, thread jaringan akan melihat beberapa byte pertama dari streaming jika perlu. Header Jenis Konten respons harus menyatakan jenis data yang dimaksud, tetapi karena mungkin tidak ada atau salah, sniffing Jenis MIME dilakukan di sini. Ini adalah "bisnis yang rumit" seperti yang dijelaskan di kode sumber. Anda dapat membaca komentar untuk melihat bagaimana browser yang berbeda memperlakukan pasangan tipe konten/payload.

Jika responsnya adalah file HTML, maka langkah berikutnya adalah meneruskan data ke proses perender, tetapi jika berupa file zip atau file lainnya, berarti itu adalah permintaan download sehingga mereka harus meneruskan data ke pengelola download.

Penyadapan jenis MIME
Gambar 4: Thread jaringan yang menanyakan apakah data respons adalah HTML dari situs yang aman

Di sinilah pemeriksaan SafeBrowsing juga dilakukan. Jika domain dan data respons tampaknya cocok dengan situs berbahaya yang diketahui, thread jaringan akan memperingatkan untuk menampilkan halaman peringatan. Selain itu, pemeriksaan Cross Origin Lead Blocking (CORB) dilakukan untuk memastikan data lintas situs yang sensitif tidak sampai ke proses perender.

Langkah 4: Temukan proses perender

Setelah semua pemeriksaan selesai dan Thread jaringan yakin bahwa browser harus membuka situs yang diminta, thread Jaringan akan memberi tahu UI thread bahwa data sudah siap. UI thread kemudian menemukan proses perender untuk melanjutkan rendering halaman web.

Menemukan proses perender
Gambar 5: Thread jaringan memberi tahu UI thread untuk menemukan Proses Perender

Karena permintaan jaringan dapat memerlukan waktu beberapa ratus milidetik untuk mendapatkan respons kembali, pengoptimalan untuk mempercepat proses ini diterapkan. Saat UI thread mengirimkan permintaan URL ke rangkaian pesan jaringan pada langkah 2, UI thread sudah mengetahui situs mana yang dituju. UI thread mencoba menemukan atau memulai proses perender secara proaktif secara paralel dengan permintaan jaringan. Dengan demikian, jika semuanya berjalan sesuai harapan, proses perender sudah berada dalam posisi standby saat thread jaringan menerima data. Proses standby ini mungkin tidak digunakan jika navigasi mengalihkan lintas situs, sehingga proses yang berbeda mungkin diperlukan.

Langkah 5: Commit navigasi

Setelah data dan proses perender siap, IPC akan dikirim dari proses browser ke proses perender untuk menjalankan navigasi. Kode ini juga meneruskan aliran data sehingga proses perender dapat terus menerima data HTML. Setelah proses browser mendengar konfirmasi bahwa commit telah terjadi dalam proses perender, navigasi selesai dan fase pemuatan dokumen dimulai.

Pada tahap ini, kolom URL diperbarui dan indikator keamanan serta UI setelan situs mencerminkan informasi situs halaman baru. Histori sesi untuk tab akan diperbarui sehingga tombol kembali/maju akan menelusuri situs yang baru dibuka. Untuk memudahkan pemulihan tab/sesi saat Anda menutup tab atau jendela, histori sesi akan disimpan di disk.

Commit navigasi
Gambar 6: IPC antara proses browser dan perender, yang meminta untuk merender halaman

Langkah Tambahan: Pemuatan awal selesai

Setelah navigasi di-commit, proses perender akan melanjutkan pemuatan resource dan merender halaman. Kami akan membahas detail tentang apa yang terjadi pada tahap ini di postingan berikutnya. Setelah proses rendering "selesai", perender akan mengirimkan IPC kembali ke proses browser (ini terjadi setelah semua peristiwa onload diaktifkan pada semua frame di halaman dan telah selesai dieksekusi). Pada tahap ini, UI thread menghentikan indikator lingkaran berputar pemuatan di tab.

Saya bilang "finishes", karena JavaScript sisi klien masih bisa memuat resource tambahan dan merender tampilan baru setelah ini.

Halaman selesai dimuat
Gambar 7: IPC dari perender ke proses browser untuk memberi tahu bahwa halaman telah "dimuat"

Navigasi yang sederhana telah selesai! Namun, apa yang terjadi jika pengguna menempatkan URL berbeda ke kolom URL? Nah, proses browser melalui langkah yang sama untuk menavigasi ke situs yang berbeda. Namun, sebelum dapat melakukannya, Cloud Firestore perlu memeriksa dengan situs yang saat ini dirender apakah peduli dengan peristiwa beforeunload.

beforeunload dapat membuat notifikasi "Keluar dari situs ini?" saat Anda mencoba keluar atau menutup tab. Segala sesuatu di dalam tab, termasuk kode JavaScript Anda, ditangani oleh proses perender, sehingga proses browser harus memeriksa proses perender saat ini saat permintaan navigasi baru masuk.

pengendali peristiwa beforeunload
Gambar 8: IPC dari proses browser ke proses perender yang memberi tahu bahwa proses akan membuka situs yang berbeda

Jika navigasi dimulai dari proses perender (seperti pengguna mengklik link atau JavaScript sisi klien telah menjalankan window.location = "https://newsite.com"), proses perender akan memeriksa pengendali beforeunload terlebih dahulu. Kemudian, browser akan melewati proses yang sama seperti navigasi yang dimulai oleh proses browser. Satu-satunya perbedaan adalah permintaan navigasi dimulai dari proses perender ke proses browser.

Saat navigasi baru dibuat ke situs yang berbeda dengan situs yang saat ini dirender, proses render terpisah dipanggil untuk menangani navigasi baru sementara proses render saat ini disimpan untuk menangani peristiwa seperti unload. Untuk mengetahui informasi selengkapnya, lihat ringkasan status siklus proses halaman dan cara mengaitkan peristiwa dengan Page Lifecycle API.

navigasi baru dan hapus muatan
Gambar 9: 2 IPC dari proses browser ke proses perender baru yang meminta untuk merender halaman dan memberi tahu proses perender lama untuk menghapus muatan

Jika Service Worker

Satu perubahan terbaru pada proses navigasi ini adalah pengenalan pekerja layanan. Pekerja layanan adalah cara untuk menulis proxy jaringan dalam kode aplikasi Anda; memungkinkan developer web memiliki kontrol lebih besar atas apa yang di-cache secara lokal dan kapan harus mendapatkan data baru dari jaringan. Jika pekerja layanan disetel untuk memuat halaman dari cache, tidak perlu meminta data dari jaringan.

Bagian penting yang harus diingat adalah pekerja layanan adalah kode JavaScript yang berjalan dalam proses perender. Namun, saat permintaan navigasi masuk, bagaimana proses browser mengetahui bahwa situs memiliki pekerja layanan?

Pencarian cakupan pekerja layanan
Gambar 10: thread jaringan dalam proses browser mencari cakupan pekerja layanan

Saat pekerja layanan didaftarkan, cakupan pekerja layanan disimpan sebagai referensi (Anda dapat membaca lebih lanjut tentang cakupan dalam artikel Siklus Proses Pekerja Layanan). Saat navigasi terjadi, thread jaringan akan memeriksa domain terhadap cakupan pekerja layanan terdaftar, jika pekerja layanan didaftarkan untuk URL tersebut, UI thread akan menemukan proses perender untuk mengeksekusi kode pekerja layanan. Pekerja layanan dapat memuat data dari cache, sehingga tidak perlu lagi meminta data dari jaringan, atau dapat meminta resource baru dari jaringan.

navigasi pekerja layanan
Gambar 11: UI thread dalam proses browser memulai proses perender untuk menangani pekerja layanan; thread pekerja dalam proses perender kemudian meminta data dari jaringan

Anda dapat melihat perjalanan dua arah antara proses browser dan proses perender ini dapat mengakibatkan penundaan jika pekerja layanan akhirnya memutuskan untuk meminta data dari jaringan. Pramuat Navigasi adalah mekanisme untuk mempercepat proses ini dengan memuat resource secara paralel dengan startup pekerja layanan. Protokol ini menandai permintaan ini dengan header, yang memungkinkan server memutuskan untuk mengirim konten yang berbeda untuk permintaan ini; misalnya, hanya memperbarui data, bukan dokumen lengkap.

Pramuat navigasi
Gambar 12: UI thread dalam proses browser memulai proses perender untuk menangani pekerja layanan sekaligus memulai permintaan jaringan secara paralel

Rangkuman

Dalam postingan ini, kita melihat apa yang terjadi selama navigasi dan bagaimana kode aplikasi web Anda, seperti header respons dan JavaScript sisi klien, berinteraksi dengan browser. Dengan mengetahui langkah-langkah yang dilakukan browser untuk mendapatkan data dari jaringan, Anda akan lebih mudah memahami mengapa API seperti pramuat navigasi dikembangkan. Pada postingan berikutnya, kita akan mempelajari cara browser mengevaluasi HTML/CSS/JavaScript untuk merender halaman.

Apakah Anda menikmati postingan itu? Jika ada pertanyaan atau saran untuk postingan mendatang, kami ingin mendengar pendapat Anda di bagian komentar di bawah atau @kosamari di Twitter.

Berikutnya: Cara kerja bagian dalam Proses Perender