Langkah pertama dalam membuat situs yang dapat dimuat dengan cepat adalah menerima respons tepat waktu dari server untuk HTML halaman. Saat Anda memasukkan URL di
kolom URL browser, browser akan mengirim permintaan GET ke server untuk
mengambilnya. Permintaan pertama untuk halaman web adalah untuk resource HTML—dan memastikan bahwa HTML diterima dengan cepat dengan sedikit keterlambatan adalah tujuan performa utama.
Permintaan awal untuk HTML tersebut melalui beberapa langkah, yang masing-masing memerlukan waktu. Mengurangi waktu yang dihabiskan pada setiap langkah akan memberi Anda Time to First Byte (TTFB) yang lebih cepat. Meskipun TTFB bukan satu-satunya metrik yang harus menjadi fokus dalam terkait seberapa cepat halaman dimuat, TTFB yang tinggi memang menyulitkan untuk mencapai batas "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 respons sementara (respons 302 Found).
Pengalihan memperlambat kecepatan pemuatan halaman karena browser mengharuskan browser membuat permintaan HTTP tambahan di lokasi baru untuk mengambil resource. Ada dua jenis pengalihan:
- Pengalihan origin yang sama yang terjadi sepenuhnya dalam origin Anda. Jenis pengalihan ini sepenuhnya berada dalam kendali Anda, karena logika untuk mengelolanya sepenuhnya berada di server web Anda.
- Pengalihan lintas origin yang dimulai oleh origin lain. Jenis pengalihan ini biasanya di luar kendali Anda.
Pengalihan lintas origin sering kali digunakan oleh iklan, layanan penyingkat URL, dan layanan pihak ketiga lainnya. Meskipun pengalihan lintas origin berada di luar kendali Anda, sebaiknya periksa apakah Anda menghindari beberapa pengalihan—misalnya, memiliki iklan yang ditautkan ke halaman HTTP yang kemudian dialihkan ke HTTPS yang setara, atau pengalihan lintas origin yang masuk ke origin Anda, tetapi kemudian memicu pengalihan origin yang sama.
Menyimpan respons HTML dalam cache
Menyimpan respons HTML ke dalam cache adalah hal yang sulit, karena responsnya dapat mencakup link ke resource penting lainnya seperti CSS, JavaScript, gambar, dan jenis resource lainnya. Resource ini dapat menyertakan sidik jari unik di nama filenya masing-masing, yang berubah berdasarkan konten file. Artinya, dokumen HTML yang di-cache mungkin menjadi usang setelah deployment, karena dokumen tersebut berisi referensi ke subresource yang sudah tidak berlaku.
Meskipun demikian, masa pakai cache yang singkat—bukannya dalam cache—dapat memiliki manfaat, seperti mengizinkan resource untuk disimpan dalam cache di CDN—mengurangi jumlah permintaan yang disalurkan dari server asal—dan di browser, sehingga resource dapat 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 disetel ke beberapa menit yang Anda anggap 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—Anda sangat mungkin tidak ingin menyimpan konten dalam cache sama sekali karena berbagai masalah, termasuk keamanan dan keaktualan. Jika respons HTML disimpan di cache oleh browser pengguna, Anda tidak dapat membatalkan cache. Oleh karena itu, sebaiknya hindari caching HTML sama sekali dalam kasus semacam ini.
Pendekatan yang hati-hati untuk meng-cache HTML dapat menggunakan header respons ETag atau
Last-Modified. Header ETag—atau dikenal sebagai tag
entity—adalah ID yang merepresentasikan resource yang diminta secara unik,
sering kali menggunakan hash konten resource:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Setiap kali resource berubah, nilai ETag baru harus dibuat. Pada
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 akan menggunakan resource dari cache. Meskipun hal ini 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 masih merupakan kekurangan tersendiri. Seperti banyak aspek pengembangan web lainnya, kompromi dan kompromi tidak dapat dihindari. Terserah Anda untuk mengetahui apakah upaya tambahan untuk meng-cache HTML dengan cara ini sepadan, atau lebih baik tetap berjaga-jaga 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 menayangkan respons yang dihasilkan secara dinamis—seperti mengambil data dari database—mungkin memiliki TTFB yang lebih tinggi daripada halaman web statis yang dapat langsung ditayangkan tanpa waktu komputasi yang signifikan di backend. Dengan menampilkan indikator lingkaran berputar pemuatan, lalu mengambil semua data di sisi klien, upaya akan dipindahkan dari lingkungan sisi server yang lebih dapat diprediksi ke lingkungan sisi klien yang berpotensi tidak dapat diprediksi. Meminimalkan upaya sisi klien biasanya menghasilkan peningkatan metrik yang berfokus pada pengguna.
Jika pengguna mengalami TTFB yang lambat di kolom, Anda dapat menampilkan informasi
tentang tempat 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 kolom
menggunakan Navigation Timing API dan dianalisis untuk melihat apakah pengguna mengalami
keterlambatan. 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.
Sebaiknya Anda juga meninjau infrastruktur hosting dan memastikan 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 gambar HTML, JavaScript, CSS, dan SVG harus dikompresi untuk mengurangi ukuran transfer melalui jaringan agar dapat didownload dengan lebih cepat. Algoritma kompresi yang paling banyak digunakan adalah gzip dan Brootli. Brotli menghasilkan peningkatan sekitar 15% hingga 20% dibandingkan {i>gzip<i}.
Kompresi sering kali disiapkan secara otomatis oleh sebagian besar penyedia hosting web, tetapi ada beberapa hal penting yang perlu dipertimbangkan jika Anda berada di posisi untuk mengonfigurasi atau menyesuaikan setelan kompresi sendiri:
- Gunakan Brotli jika memungkinkan. Seperti yang disebutkan 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 penggantian, karena kompresi apa pun lebih baik daripada tidak ada kompresi sama sekali.
- Ukuran file itu penting. Resource yang sangat kecil—kurang dari 1 KiB—tidak dikompresi dengan baik, atau terkadang bahkan tidak dikompresi sama sekali. Efektivitas jenis kompresi data apa pun bergantung pada banyaknya data yang dapat digunakan oleh algoritma kompresi untuk menemukan lebih banyak bit data yang dapat dikompresi. Semakin besar ukuran file, semakin baik kompresi yang dihasilkan. Namun, jangan mengirim resource yang sangat besar agar dapat dikompresi dengan lebih efektif. Resource besar—seperti JavaScript dan CSS misalnya—memerlukan waktu yang jauh lebih lama untuk mengurai dan mengevaluasi setelah browser mendekompresi resource tersebut, dan dapat berubah lebih sering meskipun hanya berubah sedikit, karena setiap perubahan akan menghasilkan hash file yang berbeda.
- Pahami kompresi dinamis versus kompresi statis. Kompresi dinamis dan statis adalah pendekatan yang berbeda untuk kapan resource harus dikompresi. Kompresi dinamis mengompresi resource pada saat diminta, dan terkadang setiap kali diminta. Di sisi lain, kompresi statis mengompresi file lebih cepat, sehingga tidak memerlukan kompresi untuk dilakukan pada saat permintaan. Kompresi statis menghapus latensi yang terlibat dalam kompresi itu sendiri, yang dapat menambah waktu respons server jika terjadi kompresi dinamis. Resource statis—seperti gambar JavaScript, CSS, dan SVG—harus dikompresi secara statis, sedangkan resource HTML—terutama jika dibuat secara dinamis untuk pengguna yang diautentikasi—harus dikompresi secara dinamis.
Melakukan kompresi sendiri merupakan hal yang menantang, dan sering kali sebaiknya Jaringan Penayangan Konten (CDN) digunakan, yang dibahas di bagian berikutnya, untuk 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 sehingga dapat menghasilkan manfaat maksimum bagi situs Anda.
Jaringan Penayangan Konten (CDN)
Jaringan Penayangan Konten (CDN) adalah jaringan server terdistribusi yang menyimpan resource dalam cache dari server asal, dan kemudian menayangkannya dari server edge yang secara fisik lebih dekat dengan pengguna Anda. Kedekatan fisik dengan pengguna Anda mengurangi waktu round-trip (RTT), sedangkan pengoptimalan seperti HTTP/2 atau HTTP/3, penyimpanan dalam cache, dan kompresi memungkinkan CDN menayangkan konten lebih cepat daripada jika akan diambil dari server asal. Dalam beberapa kasus, menggunakan CDN dapat meningkatkan TTFB situs Anda secara signifikan.
Menguji pengetahuan Anda
Jenis pengalihan apa yang sepenuhnya berada dalam kendali Anda?
Header Server-Timing dapat berisi beberapa metrik.
Jenis server apa yang kemungkinan besar secara fisik paling dekat dengan pengguna akhir Anda?
Selanjutnya: Memahami jalur kritis
Setelah memahami beberapa pertimbangan performa yang terkait dengan HTML situs, sekarang Anda berada di posisi yang lebih baik untuk memastikan bahwa HTML dapat dimuat secepat mungkin—tetapi ini hanyalah awal dari mempelajari performa web. Selanjutnya, teori di balik jalur rendering kritis dibahas. Modul ini menjelaskan konsep utama seperti resource pemblokir render dan pemblokiran penguraian, serta perannya dalam mendapatkan rendering awal halaman di browser secepat mungkin.