Yang terjadi dalam navigasi
Artikel ini merupakan bagian 2 dari 4 bagian rangkaian blog yang membahas cara kerja bagian dalam Chrome. Di postingan sebelumnya, kita telah melihat betapa berbedanya proses dan utas menangani berbagai bagian dari sebuah {i>browser<i}. Dalam postingan ini, kami menggali lebih dalam bagaimana setiap proses dan utas berkomunikasi untuk menampilkan situs web.
Mari kita lihat kasus penggunaan sederhana penjelajahan web: Anda mengetik URL ke dalam browser, lalu browser mengambil data dari internet dan menampilkan sebuah halaman. Dalam postingan ini, kita akan fokus pada bagian di mana pengguna meminta situs dan browser bersiap merender halaman - juga dikenal sebagai navigasi.
Proses ini dimulai dengan proses browser
Seperti yang telah kita bahas bagian 1: CPU, GPU, Memori, dan arsitektur multiproses, segala sesuatu di luar tab ditangani oleh proses {i>browser<i}. Proses browser memiliki utas seperti thread UI yang menggambar tombol dan bidang input dari {i>browser<i}, thread jaringan yang berhubungan dengan tumpukan jaringan untuk menerima data dari internet, thread penyimpanan yang mengontrol akses ke file dan lainnya. Saat Anda mengetik URL pada alamat input ditangani oleh thread UI proses browser.
Navigasi yang sederhana
Langkah 1: Menangani input
Saat pengguna mulai mengetik di kolom URL, hal pertama yang ditanyakan oleh UI thread 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.
Langkah 2: Mulai navigasi
Saat pengguna menekan enter, UI thread akan memulai panggilan jaringan untuk mendapatkan konten situs. Memuat indikator lingkaran berputar ditampilkan di sudut tab, dan {i>thread <i}jaringan melewati protokol yang sesuai seperti pencarian DNS dan membuat Koneksi TLS untuk permintaan.
Pada tahap ini, thread jaringan mungkin menerima header pengalihan server seperti HTTP 301. Dalam kasus tersebut, thread jaringan berkomunikasi dengan UI thread bahwa server meminta pengalihan. Lalu: akan dimulai permintaan URL lainnya.
Langkah 3: Baca respons
Setelah isi respons ({i>payload<i}) mulai masuk, thread jaringan melihat beberapa byte pertama dari streaming jika diperlukan. {i>Header<i} Content-Type respons harus memutuskan jenis data itu, tetapi karena data itu mungkin hilang atau salah, Penyadapan Jenis MIME dilakukan di sini. Ini "bisnis yang rumit" seperti yang dikomentari dalam kode sumber. Anda dapat membaca komentar untuk melihat bagaimana browser yang berbeda memperlakukan pasangan jenis konten/payload.
Jika responsnya adalah file HTML, langkah berikutnya adalah meneruskan data ke perender tetapi jika itu adalah file {i>zip<i} atau beberapa file lain maka itu berarti itu adalah permintaan unduh jadi mereka harus meneruskan data ke pengelola download.
Di sinilah pemeriksaan SafeBrowsing juga dilakukan. Jika domain dan data respons tampak cocok dengan situs berbahaya yang dikenal, thread jaringan peringatan untuk menampilkan halaman peringatan. Selain itu, Cross Origin Read Blocking (CORB) dilakukan untuk memastikan data lintas situs yang sensitif data 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 memberi tahu thread UI bahwa data sudah siap. UI thread kemudian menemukan perender untuk melanjutkan proses perenderan halaman web.
Karena permintaan jaringan memerlukan waktu beberapa ratus milidetik untuk mendapatkan respons, pengoptimalan untuk mempercepat proses ini akan diterapkan. Saat UI thread mengirim permintaan URL ke thread jaringan di langkah 2, ia sudah mengetahui situs mana yang mereka kunjungi. UI thread mencoba secara proaktif menemukan atau memulai proses perender secara paralel dengan permintaan jaringan. Dengan begini, jika semuanya berjalan seperti yang diharapkan, proses perender sudah berada dalam posisi standby ketika thread jaringan menerima data. Proses standby ini mungkin tidak akan digunakan jika navigasi mengalihkan lintas situs, dalam hal ini mungkin diperlukan proses yang berbeda.
Langkah 5: Commit navigasi
Setelah data dan proses perender sudah siap, IPC dikirim dari proses browser ke proses perender untuk melakukan navigasi. Fungsi ini juga meneruskan aliran data sehingga perender lain dapat terus menerima data HTML. Setelah proses browser mendengar konfirmasi bahwa commit terjadi di proses perender, navigasi telah selesai, dan fase pemuatan dokumen dimulai.
Pada tahap ini, kolom URL akan diperbarui dan indikator keamanan serta UI setelan situs mencerminkan informasi situs halaman baru. Histori sesi untuk tab akan diperbarui agar dapat diarahkan ke alur maju/mundur akan berjalan pada situs yang baru saja dinavigasi. Untuk memfasilitasi pemulihan tab/sesi saat Anda menutup tab atau jendela, riwayat sesi akan disimpan di {i>disk<i}.
Langkah Tambahan: Pemuatan awal selesai
Setelah navigasi di-commit, proses perender akan melanjutkan pemuatan resource dan merender
kami. Kita akan membahas detail tentang apa yang terjadi pada tahap ini di postingan berikutnya. Setelah perender
proses "penyelesaian" {i>rendering<i}, ia mengirim IPC kembali ke proses {i>browser<i} (ini setelah semua
Peristiwa onload telah diaktifkan pada semua frame di halaman dan telah selesai dieksekusi). Pada tahap ini,
UI thread menghentikan indikator lingkaran berputar pemuatan pada tab.
Saya mengatakan "finishes", karena JavaScript sisi klien masih dapat dimuat sumber daya tambahan dan merender tampilan baru setelah titik ini.
Membuka situs lain
Navigasi sederhana telah selesai! Namun apa yang terjadi jika pengguna menempatkan URL berbeda ke kolom URL
lagi? Nah, proses {i>browser<i} akan melalui langkah yang sama
untuk menavigasi ke situs yang berbeda.
Namun, sebelum dapat melakukannya, situs perlu memeriksa
situs yang dirender saat ini apakah
Peristiwa beforeunload.
beforeunload dapat membuat "Keluar dari situs ini?" notifikasi saat Anda mencoba membuka atau menutup tab.
Segala sesuatu di dalam tab termasuk kode JavaScript Anda ditangani oleh proses perender, jadi
proses browser harus memeriksa proses perender saat ini
ketika permintaan navigasi baru masuk.
Jika navigasi dimulai dari proses perender (seperti pengguna mengeklik tautan atau
JavaScript sisi klien telah menjalankan window.location = "https://newsite.com") proses perender
pertama-tama memeriksa pengendali beforeunload. Kemudian, melewati proses yang sama
seperti proses {i>browser<i}
memulai navigasi. Satu-satunya perbedaan adalah permintaan navigasi dimulai dari
proses perender ke proses browser.
Saat navigasi baru dilakukan ke situs yang berbeda dengan situs yang saat ini dirender, render terpisah
proses 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 bagaimana Anda dapat
terhubung ke peristiwa dengan
Page Lifecycle API.
Jika terjadi Service Worker
Satu perubahan terbaru pada proses navigasi ini adalah diperkenalkannya pekerja layanan. Pekerja layanan adalah cara untuk menulis {i>proxy<i} jaringan di kode aplikasi Anda; yang memungkinkan pengembang web memiliki kontrol lebih besar atas apa yang {i>cache<i} secara lokal dan kapan harus mendapatkan data baru dari jaringan. Jika pekerja layanan disetel untuk memuat halaman dari cache, tidak perlu lagi meminta data dari jaringan.
Bagian penting yang perlu diingat adalah bahwa pekerja layanan adalah kode JavaScript yang berjalan di perender {i>checkout<i}. Tetapi ketika permintaan navigasi masuk, bagaimana proses {i>browser<i} mengetahui bahwa situs itu memiliki pekerja layanan?
Saat pekerja layanan terdaftar, cakupan pekerja layanan akan disimpan sebagai referensi (Anda dapat membaca lebih lanjut tentang ruang lingkup di Artikel Siklus Proses Service Worker). Saat navigasi terjadi, thread jaringan akan memeriksa domain terhadap pekerja layanan terdaftar cakupan, jika pekerja layanan didaftarkan untuk URL tersebut, thread UI akan menemukan proses perender di untuk mengeksekusi kode pekerja layanan. Pekerja layanan dapat memuat data dari cache, menghilangkan kebutuhan untuk meminta data dari jaringan, atau meminta sumber daya baru dari jaringan.
Pramuat Navigasi
Anda dapat melihat proses dua arah antara proses browser dan proses perender ini dapat mengakibatkan keterlambatan jika pekerja layanan akhirnya memutuskan untuk meminta data dari jaringan. Pramuat Navigasi adalah mekanisme untuk mempercepatnya dengan memuat resource secara paralel dengan startup pekerja layanan. Menandai permintaan ini dengan {i>header<i}, memungkinkan server untuk memutuskan untuk mengirim konten yang berbeda permintaan tersebut; misalnya, hanya memperbarui data bukan satu dokumen lengkap.
Penutup
Dalam posting ini, kita melihat apa yang terjadi selama navigasi dan bagaimana kode aplikasi web Anda sebagai header respons dan JavaScript sisi klien berinteraksi dengan browser. Mengetahui langkah-langkah browser lakukan untuk mendapatkan data dari jaringan, memudahkan pemahaman mengapa API seperti navigasi pramuat dikembangkan. Di postingan berikutnya, kita akan mempelajari cara browser mengevaluasi HTML/CSS/JavaScript untuk merender halaman.
Apakah Anda menyukai postingan ini? Jika Anda memiliki pertanyaan atau saran untuk postingan mendatang, kami ingin dengarkan pendapat Anda di bagian komentar di bawah atau @kosamari di Twitter.