Pertimbangan performa HTML umum

Langkah pertama dalam membangun situs yang dimuat dengan cepat adalah menerima respons dari server untuk HTML halaman. Saat Anda memasukkan URL di kolom URL browser, browser mengirimkan permintaan GET ke server untuk mendapatkannya kembali. Permintaan pertama untuk laman web adalah sumber daya HTML—dan memastikan bahwa HTML tiba dengan cepat dengan sedikit penundaan adalah kinerja utama sasaran.

Permintaan awal untuk HTML tersebut melalui beberapa langkah, masing-masing membutuhkan beberapa saat. Mengurangi waktu yang dihabiskan di setiap langkah akan memberikan Waktu untuk First Byte (TTFB). Meskipun TTFB bukan satu-satunya metrik yang harus Anda fokuskan ketika berkaitan dengan seberapa cepat halaman dimuat, TTFB yang tinggi memang membuatnya sulit untuk dijangkau yang ditetapkan sebagai "bagus" nilai minimum untuk metrik seperti Largest Contentful Paint (LCP) dan First Contentful Paint (FCP).

Minimalkan pengalihan

Saat sumber daya diminta, server dapat merespons dengan pengalihan, baik dengan pengalihan permanen (respons 301 Moved Permanently) atau satu (respons 302 Found).

Pengalihan memperlambat kecepatan pemuatan halaman karena mengharuskan browser melakukan permintaan HTTP tambahan di lokasi baru untuk mengambil sumber daya. Ada dua jenis pengalihan:

1. Pengalihan origin yang sama yang sepenuhnya terjadi dalam origin Anda. Jenis-jenis ini pengalihan sepenuhnya berada dalam kendali Anda, karena logika untuk mengelola mereka sepenuhnya berada di server web Anda.
2. Pengalihan lintas origin yang dimulai oleh origin lain. Jenis-jenis pengalihan biasanya berada di luar kendali Anda.

Pengalihan lintas asal sering digunakan oleh iklan, layanan pemendekan URL, dan dan layanan pihak ketiga. Meskipun pengalihan lintas origin berada di luar kendali Anda, Anda mungkin perlu memeriksa apakah Anda menghindari beberapa pengalihan—misalnya, memiliki iklan yang tertaut ke halaman HTTP yang nantinya mengalihkan ke HTTPS setara, atau pengalihan lintas origin yang tiba ke origin Anda, tetapi kemudian memicu pengalihan origin yang sama.

Menyimpan respons HTML dalam cache

Menyimpan respons HTML ke dalam cache sulit, karena respons mungkin menyertakan tautan ke sumber daya penting lainnya seperti CSS, JavaScript, gambar, dan sumber daya jenis datanya. Resource ini mungkin menyertakan sidik jari unik di masing-masing nama {i>file<i}, yang berubah berdasarkan isi file. Ini berarti bahwa cache Anda Dokumen HTML mungkin menjadi basi setelah penerapan, karena akan berisi referensi terhadap subresource yang sudah usang.

Meskipun demikian, masa pakai cache yang singkat—bukan tanpa penyimpanan cache—dapat bermanfaat seperti mengizinkan sumber daya untuk di-cache di CDN—mengurangi jumlah permintaan yang disajikan dari server asal—dan di browser, yang memungkinkan resource divalidasi ulang, bukan didownload lagi. Pendekatan ini berfungsi cocok untuk konten statis yang tidak berubah dalam konteks apa pun, dan waktu untuk meng-cache sumber daya dapat diatur menjadi beberapa menit yang Anda anggap yang sesuai. Lima menit untuk resource HTML statis adalah taruhan yang aman, dan memastikan bahwa pembaruan berkala tidak luput dari perhatian.

Jika konten HTML halaman dipersonalisasi dengan cara tertentu—misalnya untuk pengguna yang diautentikasi — kemungkinan besar Anda tidak ingin meng-cache konten sama sekali berbagai masalah, termasuk keamanan dan keaktualan situs Anda. Jika respons HTML adalah di-cache oleh browser pengguna, Anda tidak dapat membatalkan cache. Penting oleh karena itu, dalam kasus semacam ini, sebaiknya Anda tidak meng-{i>cache<i} HTML sama sekali.

Pendekatan hati-hati untuk menyimpan HTML dalam cache dapat berupa menggunakan ETag atau Header respons Last-Modified. ETag—atau dikenal sebagai entity tag—header adalah ID yang secara unik mewakili resource yang diminta, sering kali dengan menggunakan hash konten resource:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Setiap kali resource berubah, nilai ETag baru harus dibuat. Aktif permintaan berikutnya, browser akan mengirimkan nilai ETag melalui Header permintaan If-None-Match. Jika ETag di server cocok dengan yang dikirim oleh browser, server akan merespons dengan respons 304 Not Modified, dan browser menggunakan sumber daya dari cache. Meskipun hal ini masih menimbulkan latensi jaringan, respons 304 Not Modified jauh lebih kecil daripada keseluruhan resource HTML.

Namun, latensi jaringan yang terlibat dalam memvalidasi ulang keaktualan resource masih memiliki kelemahan. Seperti banyak aspek pengembangan web lainnya, kompromi dan kompromi tidak bisa dihindari. Terserah Anda untuk mencari tahu apakah upaya tambahan untuk menyimpan HTML di {i>cache<i} dengan cara ini sangatlah bermanfaat, atau jika lebih baik untuk tetap aman dan tidak perlu repot-repot menyimpan konten HTML dalam cache sama sekali.

Mengukur waktu respons server

Jika respons tidak di-cache, waktu respons server sangat bergantung pada penyedia hosting dan stack aplikasi backend Anda. Laman web yang melayani respons yang dihasilkan secara dinamis—seperti mengambil data dari database, untuk — mungkin memiliki TTFB yang lebih tinggi daripada halaman web statis yang dapat ditayangkan tanpa waktu komputasi yang signifikan di backend. Menampilkan indikator lingkaran berputar pemuatan lalu mengambil semua data di sisi klien akan memindahkan upaya dari lingkungan sisi server yang lebih dapat diprediksi ke lingkungan sisi server yang berpotensi tidak satu sisi klien. Meminimalkan upaya dari sisi klien biasanya menghasilkan peningkatan metrik yang berfokus pada pengguna.

Jika pengguna mengalami TTFB yang lambat di bidang, Anda dapat mengekspos informasi tempat waktu dihabiskan di server melalui penggunaan Server-Timing header respons:

Server-Timing: auth;dur=55.5, db;dur=220

Nilai header Server-Timing dapat mencakup beberapa metrik, serta durasi untuk setiap tabel tersebut. Data ini kemudian dapat dikumpulkan dari pengguna di lapangan menggunakan Navigation Timing API dan menganalisis untuk mengetahui apakah pengguna mengalami keterlambatan pengiriman. Dalam cuplikan kode sebelumnya, header respons menyertakan dua pengaturan waktu:

• Waktu untuk mengautentikasi pengguna (auth), yang memerlukan waktu 55,5 milidetik.
• Waktu akses database (db), yang memerlukan waktu 220 milidetik.

Anda juga dapat meninjau infrastruktur hosting dan mengonfirmasi bahwa Anda memiliki sumber daya yang memadai untuk menangani lalu lintas data yang diterima situs web Anda. Dibagikan penyedia {i>hosting <i}sering rentan terhadap TTFB yang tinggi, dan solusi khusus yang memberikan waktu respons lebih cepat mungkin lebih mahal.

Kompresi

Respons berbasis teks seperti HTML, JavaScript, CSS, dan gambar SVG harus dikompresi untuk mengurangi ukuran transfernya melalui jaringan agar mereka dapat mengunduh lebih cepat. Algoritma kompresi yang paling banyak digunakan adalah {i>gzip<i} dan Brotli. Brotli menghasilkan peningkatan sekitar 15% hingga 20% dibandingkan {i>gzip<i}.

Kompresi sering kali secara otomatis diatur oleh sebagian besar penyedia {i>web hosting<i}, tetapi ada beberapa hal penting yang perlu dipertimbangkan jika Anda berada dalam posisi untuk mengkonfigurasi atau menyesuaikan setelan kompresi sendiri:

1. Gunakan Brotli jika memungkinkan. Seperti yang disebutkan sebelumnya, Brotli memberikan peningkatan nyata dibandingkan gzip, dan Brotli didukung dalam semua layanan browser. Gunakan Brotli jika memungkinkan, tetapi jika situs digunakan oleh jumlah pengguna di {i>browser<i} lama, pastikan bahwa {i>gzip<i} digunakan sebagai pengganti, karena kompresi apa pun lebih baik daripada tidak ada kompresi sama sekali.
2. Ukuran file itu penting. Resource yang sangat kecil—kurang dari 1 KiB—jangan mengompresi sangat baik, atau kadang-kadang bahkan tidak dikompresi sama sekali. Efektivitas jenis apa pun kompresi data tergantung pada adanya jumlah data yang besar yang algoritma kompresi yang dapat digunakan untuk menemukan lebih banyak bit yang dapat dikompresi data. Semakin besar file, semakin baik kompresi akan berfungsi—namun, jangan mengirimkan sumber daya yang sangat besar hanya karena dapat dikompresi secara efektif. Resource besar—seperti JavaScript dan CSS—menggunakan lebih banyak waktu untuk mengurai dan mengevaluasi setelah {i>browser<i} didekompresi, dan dapat berubah lebih sering bahkan jika hanya sedikit berubah, karena setiap perubahan menghasilkan hash file yang berbeda.
3. Pahami kompresi dinamis versus statis. Dinamis dan statis kompresi adalah pendekatan berbeda untuk kapan resource harus dikompresi. Kompresi dinamis mengompresi resource pada saat , dan terkadang setiap kali permintaan diminta. Di sisi lain, kompresi statis mengkompresi file lebih cepat, tidak memerlukan kompresi yang akan dilakukan pada saat permintaan. Kompresi statis menghilangkan yang terlibat dalam kompresi itu sendiri, yang bisa menambah respons server kali dalam kasus kompresi dinamis. Resource statis—seperti Gambar JavaScript, CSS, dan SVG—harus dikompresi secara statis, sedangkan resource—terutama jika dibuat secara dinamis untuk autentikasi pengguna—harus dikompresi secara dinamis.

Melakukan kompresi dengan benar sendiri itu sulit, dan sebaiknya membiarkan saja Jaringan Penayangan Konten (CDN)—yang akan dibahas di bagian berikutnya— menangani hal ini untuk Anda. Namun, mengetahui konsep-konsep ini dapat membantu Anda membedakan apakah penyedia hosting menggunakan kompresi dengan benar. Pengetahuan itu bisa membantu menemukan peluang untuk memperbaiki setelan kompresi sehingga menghasilkan keuntungan maksimum untuk {i>website<i} Anda.

Jaringan Penayangan Konten (CDN)

Jaringan Penayangan Konten (CDN) adalah jaringan server terdistribusi yang meng-cache resource dari server origin, dan kemudian menyalurkannya dari edge server yang secara fisik lebih dekat dengan pengguna Anda. Kedekatan fisik dengan pengguna mengurangi waktu round-trip (RTT), sementara pengoptimalan seperti HTTP/2 atau HTTP/3, penyimpanan dalam cache, dan kompresi memungkinkan CDN untuk menayangkan konten dengan lebih cepat daripada jika data itu akan diambil dari server asal. Menggunakan CDN dapat meningkatkan TTFB situs web Anda secara signifikan dalam beberapa kasus.

Menguji pengetahuan Anda

Berikutnya: Memahami jalur kritis

Setelah Anda memahami beberapa pertimbangan performa yang diperlukan dengan HTML situs, Anda berada di posisi yang lebih baik untuk memastikan situs dapat dimuat secepat mungkin—tetapi ini baru awal dari mempelajari tingkat tinggi. Selanjutnya, teori di balik jalur rendering penting adalah dibahas. Modul ini menjelaskan konsep utama seperti pemblokiran render dan menguraikan sumber daya yang memblokir, dan perannya dalam mendapatkan rendering di browser secepat mungkin.