Hai, nama saya Stas Makeev. Di Yandex, saya memimpin pengembangan teknologi untuk halaman Turbo, yang menyediakan pemuatan konten yang cepat bahkan dengan koneksi yang lambat. Hari ini saya akan memberi tahu pembaca Habr sedikit tentang arsitektur proyek kami.
Kebahagiaan pengguna sebagian besar dipengaruhi oleh seberapa cepat ia melihat konten halaman web. Kecepatan mengkhawatirkan banyak orang: di toko aplikasi seluler, hanya Speedtest yang memiliki lebih dari seratus juta instalasi. Penyedia, operator seluler, pengembang situs web dan aplikasi berusaha untuk menyediakan akses tercepat ke konten sehingga pelanggan puas.
Kecepatan unduhan rata-rata di jaringan seluler Rusia adalah
16,26 Mbit / s - ini adalah indikator yang cukup bagus. Tetapi kecepatan koneksi tidak merata, kita masih dihadapkan dengan koneksi internet yang lambat - 3G, 2G, EDGE. Tentunya Anda berada dalam situasi di mana di sebuah kafe atau pusat perbelanjaan, di jalan atau di rumah pedesaan, kecepatan tinggi yang biasa sangat berkurang: situs memuat selama puluhan detik, atau bahkan lebih lama.
Teknologi halaman Turbo memecahkan masalah akses ke konten, termasuk pada kecepatan koneksi yang rendah atau tidak stabil. Ini penting bagi pemilik situs yang mengurangi persentase pengunjung "jatuh" selama transisi dari pencarian.
Cara Kerja Halaman Turbo
Pemilik situs mendaftarkan umpan RSS di Yandex.Webmaster. Umpan memasuki sistem konten Halaman Turbo, yang membutuhkan pembaruan setiap beberapa menit. Konten berat - terutama gambar dan video - kami tembolok dan diletakkan di CDN. Selain RSS, konten dapat dikirimkan melalui API dan autoparser.
Volume gambar dalam cache dari halaman Turbo mendekati 100 Tb
Keandalan dan toleransi kesalahan sistem penting bagi kami, oleh karena itu kami membuat beberapa replika data dan menyimpannya di tiga pusat data kami. Di setiap pusat data, ratusan server memproses ribuan permintaan per detik, yang memungkinkan Anda untuk menyeimbangkan beban secara fleksibel.
Sistem konten Halaman Turbo layak mendapat pos terpisah, dan kami akan menulisnya. Untuk saat ini, kami membatasi diri pada skema yang disederhanakan.
Apa yang terjadi ketika Anda membuka URL di browser?
Ketika pengguna pergi ke halaman Turbo, sesuatu seperti yang berikut terjadi "di bawah tenda":
Adaptor HTTP memproses permintaan HTTP pengguna dan membuat permintaan ke grafik yang diinginkan di AppHost dan pemberi laporan.
AppHost adalah komponen khusus yang merangkum interaksi jaringan sumber, digambarkan sebagai grafik ketergantungan. Sumber diinterogasi dalam urutan penyortiran topologis pada grafik ini, semua logika bisnis dijahit di dalamnya dan dalam konfigurasi grafik. Secara khusus, pada tingkat grafik, penyimpanan KV disurvei dan permintaan data dikirim ke API pihak ketiga.
Report-renderer adalah aplikasi yang ditulis dalam node.js yang menerima input JSON, mengeksekusi templat yang ditulis dalam JS, dan mengembalikan sebuah string.
Semua ini terjadi hampir secara instan.
Apa yang memengaruhi kecepatan unduhan?
Kami sedang mengerjakan semua aspek kecepatan: mulai dari menerapkan HTTP / 2 pada balancer dan mengoptimalkan jabat tangan TLS hingga mengoptimalkan SVG secara manual. Dalam hal ini, Anda perlu memahami kecepatan pengguna akhir.
Di dalam tim, kami membedakan tiga tahap pemrosesan permintaan: server, jaringan dan klien.
ServerIni termasuk semua yang terjadi di pusat data: mulai dari saat permintaan HTTP sampai ke server kami hingga pembuatan halaman HTML, yang dikirim langsung ke klien.
Waktu pemrosesan permintaan di server harus minimal. Meskipun nilainya relatif kecil, ini memengaruhi semua kueri pengguna. Selain itu, semua proses terjadi di lingkungan yang terkendali - tidak mungkin ada alasan untuk penundaan besar.
Waktu server terdiri dari interaksi jaringan antara simpul dari grafik ketergantungan sumber dan waktu operasi masing-masing simpul. Tetapi kami tidak akan fokus pada fitur-fitur infrastruktur jaringan pusat data Yandex - mereka pantas mendapatkan pos terpisah.
Saya ingin lebih memperhatikan komponen kedua - waktu pelaksanaan masing-masing puncak. Sebagai contoh, mari kita lihat prinsip dan alat kami untuk bekerja dengan komponen pemberi laporan, yang bertanggung jawab untuk menghasilkan HTML. Untuk komponen lain, mereka sangat mirip.
Dalam proses CI kami, ada tugas yang menerima permintaan tarikan di dev, yang melakukan pemeriksaan dasar untuk setiap komit ke cabang fitur. Jika ada indikator yang melebihi batas yang ditentukan, pengaruh di dev dibekukan sampai alasannya diklarifikasi.
Metrik kunci pada tahap ini:
- waktu templat;
- ukuran halaman ringkasan;
- ukuran file statis.
Kami mengumpulkan statistik klien (CSS dan JS) untuk setiap halaman tergantung pada data, tetapi bundel dengan blok itu sendiri tidak tergantung pada permintaan, sehingga cukup untuk membandingkan ukuran file di cabang dengan file yang serupa di dev. Untuk berbagai jenis file, kami telah menetapkan nilai ambang yang berbeda, setelah itu tugas tidak dapat dituangkan ke dev tanpa "OK" dari mereka yang bertanggung jawab untuk kecepatan.
Sebagai aturan, ada analisis bersama dari kode dan mencari cara untuk mengoptimalkan.
Kami harus bertindak berbeda dengan metrik ukuran halaman dan waktu templat, karena sangat bergantung pada permintaan tertentu dan diperlukan semacam kepastian statistik. Selain itu, Anda tidak dapat mengambil kueri sintetis, karena ini akan menjadi pengukuran yang tidak jujur. Oleh karena itu, kami terus mengumpulkan permintaan pengguna acak untuk log akses, membentuk "kartrid" dari mereka dan "menembak" mereka dengan pola di cabang dengan perubahan dan dengan dev. Ini memungkinkan Anda untuk menangkap perubahan bahkan pada permintaan yang tidak terlalu populer.
Kami memiliki beberapa "keranjang permintaan" yang memungkinkan kami untuk menutupi sebagian besar lalu lintas ke halaman Turbo.
Selain mengoptimalkan template kami, kami mengikuti optimasi yang terjadi di dalam V8. Misalnya, beralih ke
TurboFan menghasilkan hasil yang sangat baik: waktu templating sisi server berkurang secara signifikan.
Waktu templating server menurun setelah beralih ke TurboFan
JaringanDi bagian jaringan, kami menyertakan semua yang terjadi antara klien dan server: waktu transfer data, ukuran halaman dan statika, serta caching sumber daya. Ini sudah lebih menarik, karena dari pusat data kami yang nyaman kami menemukan diri kami di dunia luar yang liar, di mana tidak semuanya tergantung pada kami. Pengukuran menjadi sedikit lebih rumit, dan yang paling penting - Anda bisa mendapatkan hasil nyata dalam ratusan milidetik.
Inilah yang kami lakukan.
Kami telah memutar parameter TCP dan TLS, yang memungkinkan Anda memenangkan beberapa RTT (Round Trip Time), ini memberikan hasil luar biasa di jaringan dengan latensi tinggi. Rekan-rekan kami sudah
menulis tentang ini, jadi saya tidak akan masuk terlalu dalam.
Ukuran data yang dikirimkan dapat sangat memengaruhi kecepatan unduhan, jadi kami mencoba mengirim hanya apa yang dibutuhkan halaman saat ini dengan cara yang paling efisien.
Gambar di antarmuka kami dioptimalkan menggunakan ImageOptim. Untuk mengoptimalkan SVG, kami tidak hanya menggunakan
SVGO , tetapi kami juga tidak terlalu malas untuk melihat ke dalam konten dan, jika memungkinkan, optimalkan dengan tangan.
Kami mengunggah gambar dari pemilik situs ke CDN khusus, dioptimalkan untuk rendering gambar. Kami memotong profil exif dan warna gambar dengan terlebih dahulu mengonversi gambar menjadi sRGB. Kecepatan bit dikurangi menjadi 8 bit per saluran, tingkat kompresi diatur ke 85. Filter lanczos digunakan untuk mengubah ukuran.
Kami membuat lusinan opsi untuk setiap gambar untuk kombinasi ukuran layar yang berbeda, dengan mempertimbangkan kerapatan piksel akun (tampilan retina). Dan tentu saja, kami secara otomatis menyandikan gambar dalam format WebP, jika didukung oleh browser.
Format teks (HTML, JavaScript, CSS) dikompres menggunakan gzip / zopfli dan brotli, jika browser mendukungnya.
Penting untuk tidak melupakan keterpencilan pengguna dari server. Halaman Turbo digunakan di banyak wilayah, dan kontennya bisa apa saja. Jadi kami tidak berkompromi dan mengurangi latensi bahkan di daerah paling terpencil kami menggunakan CDN, yang terus berkembang.
Dan tentu saja, permintaan tercepat adalah mereka tidak melakukannya sama sekali. Semua statika diberikan dengan caching abadi dari domain yang terpisah tanpa cookie, dan untuk meningkatkan hit cache, masih dapat juga ditambahkan pada halaman utama dan halaman dengan hasil pencarian.
PelangganTidak cukup untuk membentuk respons server dan mengirimkannya ke browser melalui jaringan, masih perlu ditampilkan secara efektif. Kami mengoptimalkan waktu mulai untuk merender halaman sehingga orang tersebut mulai membaca konten lebih cepat.
Di header HTML, kami "menghangatkan" koneksi ke server distribusi statis kami dan juga memuatnya. Gaya sebaris ke dalam halaman, yang memungkinkan browser untuk mulai merender halaman tanpa menunggu gaya untuk memuat melalui jaringan.
Gambar konten, sematan dan iklan tidak dimuat segera, tetapi saat mereka membaca halaman, ketika mereka lebih dekat ke bidang tampilan pengguna.
JavaScript sebagian tertanam dalam HTML, dan semua skrip lainnya dimuat di bagian akhir dengan permintaan HTTP terpisah. Script penting untuk memulai, kesalahan dan pengumpulan metrik, serta komponen yang tidak sering ditemukan pada halaman tertanam di halaman.
Kami mengumpulkan metrik pemuatan halaman RUM. Yang paling kritis: waktu sampai byte pertama, gambar pertama dan awal interaktivitas, ketika semua skrip telah menyelesaikan inisialisasi dan pengguna dapat menggunakan halaman.
Sebagian besar pengguna tidak mengakses halaman Turbo secara langsung, tetapi dari layanan Yandex lainnya, dan kami ingin mengevaluasi waktu pemuatan halaman dalam konteks pengalaman pengguna. Bukan hanya mendapatkan waktu abstrak dalam ruang hampa, tetapi metrik tentang bagaimana pengguna melihat segalanya.
Jadi kami merumuskan metrik kecepatan integral:
max (firstContentfulPaint, firstImageLoadTime, timeToVisible) — timeToClickDimana:
- timeToClick - waktu klik absolut yang mengarah ke tampilan halaman Turbo. Ini bisa berupa klik pada cuplikan pada halaman hasil pencarian atau pada kartu di Yandex.Zen.
- firstImageLoadTime - waktu pemuatan absolut dari gambar konten pertama di layar pertama.
- timeToVisible - waktu absolut halaman masuk ke status terlihat. Ini berlaku untuk kasus-kasus ketika halaman telah dimuat di latar belakang.
Dan mendapat metrik pengalaman pengguna:
- jika 2/3 layar ditempati oleh gambar yang belum dimuat, integritas metrikContentfulPaint pertama agak meragukan;
- ada banyak event handler pada tautan, antara klik dan waktu mulai aktual dari halaman yang memuat waktu yang bukan nol, yang ingin saya pahami.
Kami terus mengembangkan teknologi sehingga situs menarik lebih banyak pengunjung. Sekarang halaman Turbo memuat rata-rata 15 kali lebih cepat dari versi seluler biasa. Puluhan ribu situs menggunakan Turbo, dan jumlah total kunjungan ke mereka lebih dari 12 miliar.
Semua ini adalah hasil karya pengembang, layanan dukungan, manajer yang bekerja dengan pemilik situs, dan banyak lainnya. Seiring waktu, tim, tentu saja, berkembang. Sebagai contoh, sekarang kami sedang mencari
spesialis frontend dan backend dan akan senang melihat kolega baru.
Komponen apa dari teknologi Turbo Page yang ingin Anda baca materi teknis lebih rinci di masa depan? Pengalaman apa yang Anda minati? Kami juga akan menerima umpan balik dan gagasan. Terima kasih