Bagaimana Kami Meningkatkan Vital Web Inti Kami (Studi Kasus)

Tahun lalu, Google mulai menekankan pentingnya Core Web Vitals dan bagaimana mereka mencerminkan pengalaman nyata seseorang ketika mengunjungi situs di seluruh web. Kinerja adalah fitur inti dari perusahaan kami, Pencarian Domain Instan—inilah namanya. Bayangkan keterkejutan kami ketika kami menemukan bahwa skor vital kami tidak bagus untuk banyak orang. Komputer cepat dan internet fiber kami menutupi pengalaman orang-orang nyata di situs kami. Tidak lama kemudian, lautan pemberitahuan merah "miskin" dan kuning "perlu perbaikan" di Google Search Console kami membutuhkan perhatian kami. Entropi telah menang, dan kami harus mencari cara untuk membersihkan jank—dan membuat situs kami lebih cepat.

Saya mendirikan Pencarian Domain Instan pada tahun 2005 dan menjadikannya sebagai pekerjaan sampingan saat saya bekerja di perusahaan Y Combinator (Snipshot, W06), sebelum bekerja sebagai insinyur perangkat lunak di Facebook. Kami baru-baru ini berkembang menjadi grup kecil yang sebagian besar berbasis di Victoria, Kanada dan kami sedang mengerjakan banyak fitur baru dan peningkatan kinerja. Skor vital web kami yang buruk, dan Google Update yang menjulang, membawa fokus kami untuk menemukan dan memperbaiki masalah ini.

Ketika versi pertama situs diluncurkan, saya membangunnya dengan PHP, MySQL, dan XMLHttpRequest. Internet Explorer 6 didukung penuh, Firefox mendapatkan pangsa pasar, dan Chrome masih bertahun-tahun sejak diluncurkan. Seiring waktu, kami telah berevolusi melalui berbagai generator situs statis, kerangka kerja JavaScript, dan teknologi server. Tumpukan front-end kami saat ini adalah React yang disajikan dengan Next.js dan layanan backend bawaan Rust untuk menjawab pencarian nama domain kami. Kami mencoba mengikuti praktik terbaik dengan menyajikan sebanyak mungkin melalui CDN, menghindari skrip pihak ketiga sebanyak mungkin, dan menggunakan grafik SVG sederhana alih-alih PNG bitmap. Itu tidak cukup.

Next.js memungkinkan kita membangun halaman dan komponen kita di React dan TypeScript. Saat dipasangkan dengan VS Code, pengalaman pengembangannya luar biasa. Next.js umumnya bekerja dengan mengubah komponen React menjadi HTML dan CSS statis. Dengan cara ini, konten awal dapat disajikan dari CDN, dan selanjutnya dapat "menghidrasi" halaman untuk membuat elemen dinamis. Setelah halaman terhidrasi, situs kami berubah menjadi aplikasi satu halaman tempat orang dapat mencari dan membuat nama domain. Kami tidak mengandalkan Next.js untuk melakukan banyak pekerjaan sisi server, sebagian besar konten kami diekspor secara statis sebagai HTML, CSS, dan JavaScript untuk disajikan dari CDN.

Ketika seseorang mulai mencari nama domain, kami mengganti konten halaman dengan hasil pencarian. Untuk melakukan pencarian secepat mungkin, front-end langsung menanyakan backend Rust kami yang sangat dioptimalkan untuk pencarian dan saran domain. Banyak pertanyaan yang dapat kami jawab secara instan, tetapi untuk beberapa TLD, kami perlu melakukan kueri DNS yang lebih lambat yang membutuhkan waktu satu atau dua detik untuk diselesaikan. Ketika beberapa kueri yang lebih lambat ini diselesaikan, kami akan memperbarui UI dengan informasi baru apa pun yang masuk. Halaman hasil berbeda untuk setiap orang, dan mungkin sulit bagi kami untuk memprediksi dengan tepat bagaimana pengalaman setiap orang di situs.

Chrome DevTools sangat bagus, dan tempat yang baik untuk memulai ketika mengejar masalah kinerja. Tampilan Performa menunjukkan dengan tepat kapan permintaan HTTP keluar, tempat browser menghabiskan waktu mengevaluasi JavaScript, dan banyak lagi:

Ada tiga metrik Core Web Vitals yang akan digunakan Google untuk membantu memberi peringkat situs dalam pembaruan algoritme pencarian yang akan datang. Google membuang pengalaman menjadi “Baik”, “Perlu Peningkatan”, dan “Buruk” berdasarkan skor LCP, FID, dan CLS yang dimiliki orang-orang di situs:

• LCP , atau Cat Konten Terbesar, menentukan waktu yang diperlukan agar elemen konten terbesar terlihat.
• FID , atau First Input Delay, berkaitan dengan respons situs terhadap interaksi—waktu antara ketukan, klik, atau penekanan tombol di antarmuka dan respons dari halaman.
• CLS , atau Pergeseran Tata Letak Kumulatif, melacak bagaimana elemen bergerak atau bergeser pada halaman tanpa tindakan seperti keyboard atau peristiwa klik.

Chrome disiapkan untuk melacak metrik ini di semua pengguna Chrome yang masuk, dan mengirimkan statistik anonim yang merangkum pengalaman pelanggan di situs kembali ke Google untuk dievaluasi. Skor ini dapat diakses melalui Laporan Pengalaman Pengguna Chrome, dan ditampilkan saat Anda memeriksa URL dengan alat PageSpeed ​​Insights. Skor tersebut menunjukkan pengalaman persentil ke-75 bagi orang-orang yang mengunjungi URL tersebut selama 28 hari sebelumnya. Ini adalah nomor yang akan mereka gunakan untuk membantu memberi peringkat situs dalam pembaruan.

Metrik persentil ke-75 (hal 75) memberikan keseimbangan yang wajar untuk sasaran kinerja. Mengambil rata-rata, misalnya, akan menyembunyikan banyak pengalaman buruk yang dimiliki orang. Median, atau persentil ke-50 (p50), berarti setengah dari orang yang menggunakan produk kami mengalami pengalaman yang lebih buruk. Persentil ke-95 (p95), di sisi lain, sulit untuk dibangun karena menangkap terlalu banyak outlier ekstrim pada perangkat lama dengan koneksi jerawatan. Kami merasa bahwa penilaian berdasarkan persentil ke-75 adalah standar yang adil untuk dipenuhi.

Untuk mengendalikan skor kami, pertama-tama kami beralih ke Lighthouse untuk mendapatkan beberapa alat luar biasa yang terpasang di Chrome dan dihosting di web.dev/measure/, dan di PageSpeed ​​Insights. Alat-alat ini membantu kami menemukan beberapa masalah teknis yang luas dengan situs kami. Kami melihat bahwa cara Next.js menggabungkan CSS kami dan memperlambat waktu rendering awal kami yang memengaruhi FID kami. Kemenangan mudah pertama datang dari fitur Next.js eksperimental, optimizeCss, yang membantu meningkatkan skor kinerja umum kami secara signifikan.

Lighthouse juga menangkap kesalahan konfigurasi cache yang mencegah beberapa aset statis kami dilayani dari CDN kami. Kami dihosting di Google Cloud Platform, dan CDN Google Cloud mengharuskan header Cache-Control berisi "publik". Next.js tidak mengizinkan Anda untuk mengonfigurasi semua header yang dipancarkannya, jadi kami harus menimpanya dengan menempatkan server Next.js di belakang Caddy, server proxy HTTP ringan yang diimplementasikan di Go. Kami juga mengambil kesempatan untuk memastikan bahwa kami melayani apa yang kami bisa dengan dukungan basi-sementara-validasi ulang yang relatif baru di browser modern yang memungkinkan CDN untuk mengambil konten dari asal (server Next.js kami) secara asinkron di latar belakang.

Sangat mudah—mungkin terlalu mudah—untuk menambahkan hampir semua yang Anda butuhkan ke produk Anda dari npm. Tidak butuh waktu lama untuk ukuran bundel tumbuh. Bundel besar membutuhkan waktu lebih lama untuk diunduh pada jaringan yang lambat, dan ponsel persentil ke-75 akan menghabiskan banyak waktu memblokir utas UI utama saat mencoba memahami semua kode yang baru saja diunduh. Kami menyukai BundlePhobia yang merupakan alat gratis yang menunjukkan berapa banyak dependensi dan byte yang akan ditambahkan oleh paket npm ke bundel Anda. Ini mengarahkan kami untuk menghilangkan atau mengganti sejumlah animasi bertenaga reaksi-pegas dengan transisi CSS yang lebih sederhana:

Melalui penggunaan BundlePhobia dan Lighthouse, kami menemukan bahwa logging kesalahan dan perangkat lunak analitik pihak ketiga berkontribusi secara signifikan terhadap ukuran bundel dan waktu muat kami. Kami menghapus dan mengganti alat ini dengan pencatatan sisi klien kami sendiri yang memanfaatkan API browser modern seperti sendBeacon dan ping. Kami mengirimkan logging dan analitik ke infrastruktur Google BigQuery kami sendiri di mana kami dapat menjawab pertanyaan yang kami pedulikan secara lebih mendetail daripada yang dapat disediakan oleh alat siap pakai mana pun. Ini juga menghilangkan sejumlah cookie pihak ketiga dan memberi kami kendali yang jauh lebih besar atas bagaimana dan kapan kami mengirim data logging dari klien.

Skor CLS kami masih memiliki banyak ruang untuk perbaikan. Cara Google menghitung CLS rumit—Anda diberi "jendela sesi" maksimum dengan jeda 1 detik, dibatasi 5 detik dari pemuatan halaman awal, atau dari interaksi keyboard atau klik, untuk menyelesaikan pemindahan barang di sekitar situs . Jika Anda tertarik untuk membaca lebih dalam tentang topik ini, berikut adalah panduan hebat tentang topik tersebut. Ini menghukum banyak jenis hamparan dan munculan yang muncul tepat setelah Anda mendarat di sebuah situs. Misalnya, iklan yang mengubah konten atau meningkatkan penjualan yang mungkin muncul saat Anda mulai menggulir iklan sebelumnya untuk menjangkau konten. Artikel ini memberikan penjelasan yang sangat baik tentang bagaimana skor CLS dihitung dan alasan di baliknya.

Kami pada dasarnya menentang kekacauan digital semacam ini, jadi kami terkejut melihat betapa banyak ruang untuk perbaikan yang kami buat oleh Google. Chrome memiliki overlay Web Vitals bawaan yang dapat Anda akses dengan menggunakan Menu Perintah untuk "Show Core Web Vitals overlay". Untuk melihat dengan tepat elemen mana yang dipertimbangkan Chrome dalam penghitungan CLS-nya, kami menemukan opsi "Logging Konsol" ekstensi Chrome Web Vitals di setelan lebih membantu. Setelah diaktifkan, plugin ini menampilkan skor LCP, FID, dan CLS Anda untuk halaman saat ini. Dari konsol, Anda dapat melihat dengan tepat elemen mana pada halaman yang terhubung dengan skor ini. Skor CLS kami memiliki ruang paling besar untuk perbaikan.

Dari tiga metrik, CLS adalah satu-satunya yang terakumulasi saat Anda berinteraksi dengan halaman. Ekstensi Web Vitals memiliki opsi pencatatan yang akan menunjukkan dengan tepat elemen mana yang menyebabkan CLS saat Anda berinteraksi dengan suatu produk. Perhatikan bagaimana metrik CLS ditambahkan saat kami menggulir di beranda Smashing Magazine:

Google akan terus menyesuaikan cara menghitung CLS dari waktu ke waktu, jadi penting untuk tetap mendapatkan informasi dengan mengikuti blog pengembangan web Google. Saat menggunakan alat seperti ekstensi Chrome Web Vitals, penting untuk mengaktifkan pembatasan CPU dan jaringan untuk mendapatkan pengalaman yang lebih realistis. Anda dapat melakukannya dengan alat pengembang dengan mensimulasikan CPU seluler.

Cara terbaik untuk melacak kemajuan dari satu penerapan ke penerapan berikutnya adalah dengan mengukur pengalaman halaman dengan cara yang sama seperti yang dilakukan Google. Jika Anda telah menyiapkan Google Analytics, cara mudah untuk melakukannya adalah dengan menginstal modul web-vitals Google dan menghubungkannya ke Google Analytics. Ini memberikan ukuran kasar kemajuan Anda dan membuatnya terlihat di dasbor Google Analytics.

Di sinilah kita menabrak tembok. Kami dapat melihat skor CLS kami, dan meskipun kami telah meningkatkannya secara signifikan, kami masih memiliki pekerjaan yang harus dilakukan. Skor CLS kami kira-kira 0,23 dan kami perlu mendapatkan ini di bawah 0,1—dan sebaiknya turun ke 0. Namun, pada titik ini, kami tidak dapat menemukan sesuatu yang memberi tahu kami secara tepat komponen mana pada halaman mana yang masih memengaruhi skor. Kami dapat melihat bahwa Chrome mengungkap banyak detail di alat Data Web Inti mereka, tetapi agregator logging membuang bagian terpenting: elemen halaman mana yang menyebabkan masalah.

Untuk menangkap semua detail yang kami butuhkan, kami membangun fungsi tanpa server untuk menangkap data vital web dari browser. Karena kami tidak perlu menjalankan kueri waktu nyata pada data, kami mengalirkannya ke API streaming Google BigQuery untuk penyimpanan. Arsitektur ini berarti kami dapat dengan murah menangkap sebanyak mungkin titik data yang dapat kami hasilkan.

Setelah mempelajari beberapa pelajaran saat bekerja dengan Web Vitals dan BigQuery, kami memutuskan untuk menggabungkan fungsi ini dan merilis alat ini sebagai sumber terbuka di vitals.dev.

Menggunakan Vital Instan adalah cara cepat untuk mulai melacak skor Vital Web Anda di BigQuery. Berikut contoh skema tabel BigQuery yang kami buat:

Mengintegrasikan dengan Vital Instan itu mudah. Anda dapat memulai dengan mengintegrasikan dengan pustaka klien untuk mengirim data ke fungsi backend atau tanpa server Anda:

 import { init } from "@instantdomain/vitals-client"; init({ endpoint: "/api/web-vitals" });

Kemudian, di server Anda, Anda dapat berintegrasi dengan perpustakaan server untuk menyelesaikan rangkaian:

 import fs from "fs"; import { init, streamVitals } from "@instantdomain/vitals-server"; // Google libraries require service key as path to file const GOOGLE_SERVICE_KEY = process.env.GOOGLE_SERVICE_KEY; process.env.GOOGLE_APPLICATION_CREDENTIALS = "/tmp/goog_creds"; fs.writeFileSync( process.env.GOOGLE_APPLICATION_CREDENTIALS, GOOGLE_SERVICE_KEY ); const DATASET_; init({ datasetId: DATASET_ID }).then().catch(console.error); // Request handler export default async (req, res) => { const body = JSON.parse(req.body); await streamVitals(body, body.name); res.status(200).end(); };

Cukup panggil streamVitals dengan isi permintaan dan nama metrik untuk mengirim metrik ke BigQuery. Pustaka akan menangani pembuatan kumpulan data dan tabel untuk Anda.

Setelah mengumpulkan data selama satu hari, kami menjalankan kueri ini seperti ini:

 SELECT `<project_name>.web_vitals.CLS`.Value, Node FROM `<project_name>.web_vitals.CLS` JOIN UNNEST(Entries) AS Entry JOIN UNNEST(Entry.Sources) WHERE Node != "" ORDER BY value LIMIT 10

Kueri ini menghasilkan hasil seperti ini:

Ini menunjukkan kepada kita elemen mana di halaman mana yang paling berdampak pada CLS. Itu membuat daftar pukulan bagi tim kami untuk diselidiki dan diperbaiki. Pada Pencarian Domain Instan, ternyata koneksi seluler yang lambat atau buruk akan memakan waktu lebih dari 500 md untuk memuat beberapa hasil pencarian kami. Salah satu kontributor terburuk untuk CLS bagi pengguna ini sebenarnya adalah footer kami.

Skor pergeseran tata letak dihitung sebagai fungsi dari ukuran elemen yang bergerak, dan seberapa jauh jaraknya. Dalam tampilan hasil penelusuran kami, jika perangkat membutuhkan lebih dari waktu tertentu untuk menerima dan merender hasil penelusuran, tampilan hasil akan diciutkan ke zero-height , sehingga footer terlihat. Ketika hasilnya masuk, mereka mendorong footer kembali ke bagian bawah halaman. Elemen DOM besar yang bergerak sejauh ini menambah banyak skor CLS kami. Untuk mengatasi ini dengan benar, kita perlu merestrukturisasi cara hasil pencarian dikumpulkan dan dirender. Kami memutuskan untuk menghapus footer di tampilan hasil pencarian sebagai peretasan cepat yang akan menghentikannya terpental pada koneksi yang lambat.

Kami sekarang meninjau laporan ini secara teratur untuk melacak bagaimana kami meningkatkan — dan menggunakannya untuk melawan penurunan hasil saat kami bergerak maju. Kami telah menyaksikan nilai perhatian ekstra pada fitur dan produk yang baru diluncurkan di situs kami dan telah mengoperasionalkan pemeriksaan yang konsisten untuk memastikan vital inti bertindak sesuai dengan peringkat kami. Kami berharap dengan membagikan Vital Instan, kami dapat membantu pengembang lain mengatasi skor Vital Web Inti mereka juga.

Google menyediakan alat kinerja luar biasa yang terpasang di Chrome, dan kami menggunakannya untuk menemukan dan memperbaiki sejumlah masalah kinerja. Kami mengetahui bahwa data lapangan yang disediakan oleh Google menawarkan ringkasan yang baik tentang kemajuan p75 kami, tetapi tidak memiliki detail yang dapat ditindaklanjuti. Kami perlu mencari tahu elemen DOM mana yang menyebabkan pergeseran tata letak dan penundaan input. Setelah kami mulai mengumpulkan data lapangan kami sendiri—dengan kueri XPath—kami dapat mengidentifikasi peluang khusus untuk meningkatkan pengalaman semua orang di situs kami. Dengan sedikit usaha, kami menurunkan nilai bidang Data Web Inti dunia nyata kami ke kisaran yang dapat diterima sebagai persiapan untuk Pembaruan Pengalaman Halaman bulan Juni. Kami senang melihat angka-angka ini turun dan ke kanan!