Pertimbangan performa HTML umum

Langkah pertama dalam membangun situs yang dimuat dengan cepat adalah menerima respons tepat waktu dari server untuk HTML halaman. Saat Anda memasukkan URL di kolom URL browser, browser akan mengirimkan permintaan GET ke server untuk mengambilnya. Permintaan pertama untuk halaman web adalah untuk resource HTML—dan memastikan HTML tiba dengan cepat dan dengan penundaan minimal adalah tujuan utama performa.

Permintaan awal untuk HTML tersebut melalui beberapa langkah, yang masing-masing memerlukan waktu. Mengurangi waktu yang dihabiskan untuk setiap langkah akan memberi Anda Waktu ke Byte Pertama (TTFB) yang lebih cepat. Meskipun TTFB bukan satu-satunya metrik yang harus Anda fokuskan terkait seberapa cepat halaman dimuat, TTFB yang tinggi memang menyulitkan untuk mencapai nilai minimum "baik" yang ditetapkan untuk metrik seperti Largest Contentful Paint (LCP) dan First Contentful Paint (FCP).

Minimalkan pengalihan

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

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

1. Pengalihan lintas asal yang terjadi sepenuhnya dalam asal Anda. Jenis pengalihan ini sepenuhnya berada di bawah kendali Anda, karena logika untuk mengelolanya sepenuhnya berada di server web Anda.
2. Pengalihan lintas origin yang dimulai oleh origin lain. Jenis pengalihan ini biasanya di luar kendali Anda.

Pengalihan lintas origin sering digunakan oleh iklan, layanan pemendek URL, dan layanan pihak ketiga lainnya. Meskipun pengalihan lintas origin berada di luar kendali Anda, sebaiknya Anda tetap memeriksa untuk menghindari beberapa pengalihan—misalnya, memiliki iklan yang menautkan ke halaman HTTP yang pada gilirannya mengalihkan ke halaman HTTPS yang setara, atau pengalihan lintas origin yang tiba ke origin Anda, tetapi kemudian memicu pengalihan origin yang sama.

Respons HTML cache

Respons HTML sulit di-cache, karena respons dapat menyertakan link ke resource penting lainnya seperti CSS, JavaScript, gambar, dan jenis resource lainnya. Resource ini dapat mencakup sidik jari unik dalam nama filenya masing-masing, yang berubah berdasarkan konten file. Artinya, dokumen HTML yang di-cache mungkin menjadi tidak valid setelah deployment, karena akan berisi referensi ke subresource yang sudah tidak berlaku.

Namun demikian, masa aktif cache yang singkat—bukan tanpa penyimpanan cache—dapat memberikan manfaat seperti memungkinkan aset di-cache di CDN—mengurangi jumlah permintaan yang ditayangkan dari server asal—dan di browser, memungkinkan aset divalidasi ulang, bukan didownload lagi. Pendekatan ini paling cocok untuk konten statis yang tidak berubah dalam konteks apa pun, dan waktu yang tepat untuk meng-cache resource dapat ditetapkan ke beberapa menit yang Anda anggap sesuai. Lima menit untuk resource HTML statis adalah pilihan yang aman, dan memastikan bahwa update berkala tidak terlewatkan.

Jika konten HTML halaman dipersonalisasi dengan cara tertentu—seperti untuk pengguna yang diautentikasi—Anda kemungkinan besar tidak ingin menyimpan konten dalam cache sama sekali karena berbagai alasan, termasuk keamanan dan keaktualan. Jika respons HTML di-cache oleh browser pengguna, Anda tidak dapat membatalkan validasi cache. Oleh karena itu, sebaiknya hindari menyimpan HTML dalam cache sama sekali dalam kasus seperti ini.

Pendekatan yang hati-hati untuk melakukan caching HTML adalah dengan menggunakan header respons ETag atau Last-Modified. Header ETag—atau dikenal sebagai tag entitas—adalah ID yang secara unik merepresentasikan resource yang diminta, sering kali dengan menggunakan hash konten resource:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

Namun, latensi jaringan yang terlibat dalam memvalidasi ulang keaktualan resource tetap memiliki kekurangannya sendiri. Seperti banyak aspek pengembangan web lainnya, trade-off dan kompromi tidak dapat dihindari. Anda yang menentukan apakah upaya tambahan untuk meng-cache HTML dengan cara ini sepadan, atau apakah lebih baik untuk tetap aman dan tidak perlu meng-cache konten HTML sama sekali.

Mengukur waktu respons server

Jika respons tidak di-cache, waktu respons server sangat bergantung pada penyedia hosting dan stack aplikasi backend Anda. Halaman web yang menyajikan respons yang dibuat secara dinamis—seperti mengambil data dari database, misalnya—mungkin memiliki TTFB yang lebih tinggi daripada halaman web statis yang dapat disajikan dengan segera tanpa waktu komputasi yang signifikan di backend. Menampilkan spinner pemuatan, lalu mengambil semua data di sisi klien memindahkan upaya dari lingkungan sisi server yang lebih dapat diprediksi ke lingkungan sisi klien yang berpotensi tidak dapat diprediksi. Meminimalkan upaya sisi klien biasanya akan meningkatkan metrik yang berfokus pada pengguna.

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

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

Nilai header Server-Timing dapat mencakup beberapa metrik, serta durasi untuk setiap metrik. Data ini kemudian dapat dikumpulkan dari pengguna di lapangan menggunakan Navigation Timing API dan dianalisis untuk melihat apakah pengguna mengalami penundaan. Dalam cuplikan kode sebelumnya, header respons mencakup dua pengaturan waktu:

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

Sebaiknya Anda juga meninjau infrastruktur hosting dan mengonfirmasi bahwa Anda memiliki resource yang memadai untuk menangani traffic yang diterima situs Anda. Penyedia hosting bersama sering kali 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 dapat didownload lebih cepat. Algoritma kompresi yang paling banyak digunakan adalah gzip dan Brotli. Brotli menghasilkan peningkatan sekitar 15% hingga 20% dibandingkan gzip.

Kompresi sering kali disiapkan secara otomatis oleh sebagian besar penyedia hosting web, tetapi ada beberapa hal penting yang perlu dipertimbangkan jika Anda dapat mengonfigurasi atau mengubah setelan kompresi sendiri:

1. Gunakan Brotli jika memungkinkan. Seperti yang dinyatakan sebelumnya, Brotli memberikan peningkatan yang cukup signifikan dibandingkan gzip, dan Brotli didukung di semua browser utama. Gunakan Brotli jika memungkinkan, tetapi jika situs Anda digunakan oleh banyak pengguna di browser lama, pastikan gzip digunakan sebagai pengganti, karena kompresi apa pun lebih baik daripada tidak ada kompresi sama sekali.
2. Ukuran file penting. Resource yang sangat kecil—kurang dari 1 KiB—tidak dikompresi dengan baik, atau terkadang tidak dikompresi sama sekali. Efektivitas semua jenis kompresi data bergantung pada ketersediaan data dalam jumlah besar yang dapat digunakan oleh algoritma kompresi untuk menemukan bit data yang lebih mudah dikompresi. Semakin besar ukuran file, semakin baik kompresi berfungsi—namun, jangan mengirim resource yang sangat besar hanya karena resource tersebut dapat dikompresi secara lebih efektif. Resource besar—seperti JavaScript dan CSS misalnya—membutuhkan waktu yang jauh lebih lama untuk diuraikan dan dievaluasi setelah browser mendekompresi-nya, dan mungkin lebih sering berubah meskipun hanya berubah sedikit, karena setiap perubahan akan menghasilkan hash file yang berbeda.
3. Pahami kompresi dinamis versus statis. Kompresi dinamis dan statis adalah pendekatan yang berbeda untuk menentukan kapan resource harus dikompresi. Kompresi dinamis mengompresi resource pada saat resource diminta, dan terkadang setiap kali resource tersebut diminta. Di sisi lain, kompresi statis mengompresi file sebelum waktunya, sehingga tidak memerlukan kompresi yang dilakukan pada saat permintaan. Kompresi statis menghilangkan latensi yang terlibat dalam kompresi itu sendiri, yang dapat menambah waktu respons server dalam kasus kompresi dinamis. Resource statis—seperti JavaScript, CSS, dan gambar SVG—harus dikompresi secara statis, sedangkan resource HTML—terutama jika dibuat secara dinamis untuk pengguna yang diautentikasi—harus dikompresi secara dinamis.

Menggunakan kompresi dengan benar sendiri cukup sulit, dan sering kali lebih baik membiarkan Jaringan Penayangan Konten (CDN)—yang dibahas di bagian berikutnya—menangani hal ini untuk Anda. Namun, mengetahui konsep ini dapat membantu Anda membedakan apakah penyedia hosting Anda menggunakan kompresi dengan benar. Pengetahuan tersebut dapat membantu Anda menemukan peluang untuk meningkatkan setelan kompresi agar memberikan manfaat maksimal bagi situs Anda.

Jaringan Penayangan Konten (CDN)

Jaringan Penayangan Konten (CDN) adalah jaringan server terdistribusi yang melakukan caching resource dari server asal Anda, dan pada gilirannya, menayangkannya dari server edge yang secara fisik lebih dekat dengan pengguna Anda. Kedekatan fisik dengan pengguna Anda mengurangi waktu pulang pergi (RTT), sementara pengoptimalan seperti HTTP/2 atau HTTP/3, penyimpanan cache, dan kompresi memungkinkan CDN menayangkan konten lebih cepat daripada jika konten diambil dari server asal Anda. Penggunaan CDN dapat meningkatkan TTFB situs Anda secara signifikan dalam beberapa kasus.

Menguji pengetahuan Anda

Berikutnya: Memahami jalur kritis

Setelah memahami beberapa pertimbangan performa yang terkait dengan HTML situs Anda, Anda akan berada dalam posisi yang lebih baik untuk memastikan situs dapat dimuat secepat mungkin—tetapi itu hanyalah awal dari pembelajaran performa web. Selanjutnya, teori di balik jalur rendering penting akan dibahas. Modul ini menjelaskan konsep utama seperti resource yang memblokir rendering dan memblokir parsing, serta peran yang dimainkannya dalam membuat rendering awal halaman di browser secepat mungkin.