Mengoptimalkan Time to First Byte

Pelajari cara mengoptimalkan metrik Time to First Byte.

Jeremy Wagner

Barry Pollard

Time to First Byte (TTFB) adalah metrik performa web dasar yang mendahului setiap metrik pengalaman pengguna lain yang bermakna, seperti First Contentful Paint (FCP) dan Largest Contentful Paint (LCP). Ini berarti nilai TTFB yang tinggi menambah waktu ke metrik yang mengikutinya.

Sebaiknya server Anda merespons permintaan navigasi dengan cukup cepat sehingga persentil ke-75 pengguna mengalami FCP dalam batas "baik". Sebagai panduan kasar, sebagian besar situs harus berusaha memiliki TTFB 0,8 detik atau kurang.

Cara Mengukur TTFB

Sebelum dapat mengoptimalkan TTFB, Anda perlu mengamati bagaimana pengaruhnya terhadap pengguna situs Anda. Anda harus mengandalkan data lapangan sebagai sumber utama untuk mengamati TTFB karena terpengaruh oleh pengalihan, sedangkan alat berbasis lab sering diukur menggunakan URL final, sehingga penundaan tambahan ini tidak ada.

PageSpeed Insights adalah cara mudah untuk mendapatkan informasi kolom dan lab untuk situs publik yang tersedia di Laporan Pengalaman Pengguna Chrome.

TTFB untuk pengguna nyata ditampilkan di atas bagian Temukan apa yang dialami pengguna Anda yang sebenarnya:

Sebagian TTFB ditampilkan dalam audit waktu respons server:

Untuk mengetahui cara lain mengukur TTFB di lapangan dan lab, lihat halaman metrik TTFB.

Memahami TTFB tinggi dengan Server-Timing

Header respons Server-Timing dapat digunakan di backend aplikasi untuk mengukur proses backend yang berbeda yang dapat berkontribusi pada latensi tinggi. Struktur nilai header fleksibel, menerima, setidaknya, handle yang Anda tentukan. Nilai opsional mencakup nilai durasi (melalui dur), serta deskripsi opsional yang dapat dibaca manusia (melalui desc).

Serving-Timing dapat digunakan untuk mengukur banyak proses backend aplikasi, tetapi ada beberapa yang mungkin perlu Anda perhatikan secara khusus:

• Kueri {i>database<i}
• Waktu rendering sisi server, jika berlaku
• Disk mencari
• Cache server edge ditemukan/tidak ada (jika menggunakan CDN)

Semua bagian entri Server-Timing dipisahkan dengan titik dua, dan beberapa entri dapat dipisahkan dengan koma:

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

Header dapat disetel menggunakan bahasa backend aplikasi Anda. Di PHP, misalnya, Anda dapat menetapkan {i>header<i} seperti berikut:

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Jika ditetapkan, header ini akan menampilkan informasi yang dapat Anda gunakan baik di lab maupun di kolomnya.

Di kolom, setiap halaman dengan header respons Server-Timing yang ditetapkan akan mengisi properti serverTiming di Navigation Timing API:

// Get the serverTiming entry for the first navigation request:
performance.getEntries("navigation")[0].serverTiming.forEach(entry => {
    // Log the server timing data:
    console.log(entry.name, entry.description, entry.duration);
});

Di lab, data dari header respons Server-Timing akan divisualisasikan di panel pengaturan waktu pada tab Jaringan di Chrome DevTools:

Header respons Server-Timing divisualisasikan di tab jaringan Chrome DevTools. Di sini, Server-Timing digunakan untuk mengukur apakah permintaan untuk resource telah mencapai cache CDN, dan berapa lama waktu yang diperlukan agar permintaan tersebut mencapai server edge CDN dan kemudian asal.

Setelah menentukan bahwa TTFB bermasalah dengan menganalisis data yang tersedia, Anda dapat melanjutkan ke perbaikan.

Cara mengoptimalkan TTFB

Aspek yang paling menantang dalam mengoptimalkan TTFB adalah, meski tumpukan frontend web akan selalu berupa HTML, CSS, dan JavaScript, tumpukan backend dapat sangat bervariasi. Ada banyak produk database dan stack backend yang masing-masing memiliki teknik pengoptimalannya sendiri. Oleh karena itu, panduan ini akan berfokus pada apa yang berlaku untuk sebagian besar arsitektur, bukan hanya berfokus pada panduan khusus stack.

Panduan khusus platform

Platform yang Anda gunakan untuk situs dapat berdampak besar pada TTFB. Misalnya, performa WordPress dipengaruhi oleh jumlah dan kualitas plugin, atau tema yang digunakan. Platform lain akan terkena dampak serupa saat platform disesuaikan. Sebaiknya baca dokumentasi platform Anda untuk mendapatkan saran khusus vendor guna melengkapi saran performa yang lebih umum dalam postingan ini. Audit Lighthouse untuk mengurangi waktu respons server juga mencakup beberapa panduan khusus stack terbatas.

Hosting, hosting, hosting

Bahkan sebelum Anda mempertimbangkan pendekatan pengoptimalan lainnya, hosting harus menjadi hal pertama yang Anda pertimbangkan. Tidak banyak panduan khusus yang dapat ditawarkan di sini, tetapi aturan praktisnya adalah memastikan bahwa host situs Anda mampu menangani traffic yang Anda kirimkan.

Hosting bersama umumnya akan lebih lambat. Jika Anda menjalankan situs web pribadi kecil yang sebagian besar menyajikan file statis, ini mungkin tidak masalah, dan beberapa teknik pengoptimalan yang mengikutinya akan membantu Anda menurunkan TTFB sebanyak mungkin.

Namun, jika Anda menjalankan aplikasi yang lebih besar dengan banyak pengguna yang melibatkan personalisasi, kueri database, dan operasi sisi server intensif lainnya, pilihan hosting Anda menjadi penting untuk menurunkan TTFB di lapangan.

Saat memilih penyedia hosting, berikut beberapa hal yang harus diperhatikan:

• Berapa banyak memori yang dialokasikan oleh instance aplikasi Anda? Jika aplikasi Anda tidak memiliki memori yang cukup, aplikasi akan bekerja dengan keras dan berjuang untuk menyajikan halaman secepat mungkin.
• Apakah penyedia hosting Anda terus memperbarui backend stack? Seiring dengan dirilisnya versi baru bahasa backend aplikasi, implementasi HTTP, dan software database, performa software tersebut akan terus ditingkatkan dari waktu ke waktu. Kuncinya adalah bermitra dengan penyedia hosting yang memprioritaskan pemeliharaan penting seperti ini.
• Jika Anda memiliki persyaratan aplikasi yang sangat spesifik dan menginginkan akses tingkat terendah ke file konfigurasi server, tanyakan apakah masuk akal untuk menyesuaikan backend instance aplikasi Anda sendiri.

Ada banyak penyedia hosting yang akan menangani hal ini untuk Anda, tetapi jika Anda mulai mengamati nilai TTFB yang panjang bahkan di penyedia hosting khusus, itu mungkin pertanda bahwa Anda mungkin perlu mengevaluasi kembali kemampuan penyedia hosting saat ini sehingga Anda dapat memberikan pengalaman pengguna sebaik mungkin.

Menggunakan Jaringan Penayangan Konten (CDN)

Topik Penggunaan CDN adalah salah satu topik yang sudah umum, tetapi tidak mengapa: Anda dapat memiliki backend aplikasi yang dioptimalkan dengan sangat baik, tetapi pengguna yang berada jauh dari server asal Anda mungkin masih mengalami TTFB yang tinggi di lapangan.

CDN mengatasi masalah kedekatan pengguna dari server asal dengan menggunakan jaringan server terdistribusi yang meng-cache resource pada server yang secara fisik lebih dekat dengan pengguna Anda. Server ini disebut server edge.

Penyedia CDN juga dapat menawarkan manfaat di luar server edge:

• Penyedia CDN biasanya menawarkan waktu resolusi DNS yang sangat cepat.
• CDN kemungkinan akan menayangkan konten Anda dari server edge menggunakan protokol modern seperti HTTP/2 atau HTTP/3.
• HTTP/3 secara khusus memecahkan masalah pemblokiran head-of-line yang ada di TCP (yang diandalkan HTTP/2) dengan menggunakan protokol UDP.
• CDN kemungkinan juga akan menyediakan TLS versi modern, yang menurunkan latensi yang terlibat dalam waktu negosiasi TLS. TLS 1.3 secara khusus dirancang untuk membuat negosiasi TLS sesingkat mungkin.
• Beberapa penyedia CDN menyediakan fitur yang sering disebut "edge worker", yang menggunakan API yang mirip dengan Service Worker API untuk menangkap permintaan, mengelola respons secara terprogram di edge cache, atau menulis ulang respons sepenuhnya.
• Penyedia CDN sangat baik dalam mengoptimalkan kompresi. Kompresi sulit untuk dilakukan sendiri, dan dapat menyebabkan waktu respons yang lebih lambat dalam kasus tertentu dengan markup yang dihasilkan secara dinamis, yang harus dikompresi dengan cepat.
• Penyedia CDN juga akan secara otomatis meng-cache respons terkompresi untuk resource statis, yang menghasilkan kombinasi terbaik antara rasio kompresi dan waktu respons.

Meskipun mengadopsi CDN memerlukan berbagai upaya, mulai dari yang kecil hingga yang signifikan, hal tersebut harus menjadi prioritas tinggi untuk dilakukan dalam mengoptimalkan TTFB Anda jika situs Anda belum menggunakannya.

Menggunakan konten yang disimpan dalam cache jika memungkinkan

CDN memungkinkan konten di-cache di server edge yang secara fisik lebih dekat dengan pengunjung, asalkan konten dikonfigurasi dengan header HTTP Cache-Control yang sesuai. Meskipun ini tidak sesuai untuk konten yang dipersonalisasi, mengharuskan perjalanan kembali ke tempat asal dapat meniadakan banyak nilai CDN.

Untuk situs yang sering memperbarui kontennya, bahkan waktu caching yang singkat dapat menghasilkan peningkatan performa yang signifikan untuk situs yang sibuk, karena hanya pengunjung pertama selama waktu tersebut yang akan mengalami latensi sepenuhnya kembali ke server asal, sementara semua pengunjung lain dapat menggunakan kembali resource yang di-cache dari server edge. Beberapa CDN mengizinkan pembatalan cache pada rilis situs yang memungkinkan yang terbaik dari keduanya—waktu cache yang lama, tetapi pembaruan instan saat diperlukan.

Meskipun penyimpanan cache dikonfigurasi dengan benar, hal ini dapat diabaikan melalui penggunaan parameter string kueri yang unik untuk pengukuran analisis. Meski terlihat sama, konten ini mungkin terlihat berbeda dengan CDN, sehingga versi yang di-cache tidak akan digunakan.

Konten yang lebih lama atau lebih jarang dikunjungi juga mungkin tidak di-cache, yang dapat menghasilkan nilai TTFB yang lebih tinggi di beberapa halaman dibandingkan halaman lainnya. Peningkatan waktu penyimpanan dalam cache dapat mengurangi dampak hal ini, tetapi perlu diketahui bahwa seiring bertambahnya waktu penyimpanan cache, semakin besar kemungkinan penayangan konten yang berpotensi tidak berlaku.

Dampak konten yang di-cache tidak hanya memengaruhi mereka yang menggunakan CDN. Infrastruktur server mungkin perlu menghasilkan konten dari pencarian database yang mahal saat konten yang di-cache tidak dapat digunakan kembali. Data yang lebih sering diakses atau halaman yang di-precache sering kali berperforma lebih baik.

Menghindari pengalihan beberapa halaman

Salah satu kontributor umum terhadap TTFB yang tinggi adalah pengalihan. Pengalihan terjadi saat permintaan navigasi untuk dokumen menerima respons yang memberi tahu browser bahwa resource ada di lokasi lain. Satu pengalihan pasti dapat menambahkan latensi yang tidak diinginkan ke permintaan navigasi, tetapi hal ini bisa menjadi lebih buruk jika pengalihan tersebut mengarah ke resource lain yang menyebabkan pengalihan lain—dan seterusnya. Hal ini terutama dapat memengaruhi situs yang menerima pengunjung dalam jumlah besar dari iklan atau newsletter, karena situs tersebut sering kali mengalihkan melalui layanan analisis untuk tujuan pengukuran. Menghilangkan pengalihan di bawah kontrol langsung Anda dapat membantu mencapai TTFB yang baik.

Ada dua jenis pengalihan:

• Pengalihan asal yang sama, dengan pengalihan terjadi sepenuhnya di situs Anda.
• Pengalihan lintas origin, saat pengalihan awalnya terjadi di origin lain—seperti dari layanan penyingkatan URL media sosial, misalnya—sebelum tiba di situs Anda.

Sebaiknya Anda berfokus untuk menghilangkan pengalihan dari origin yang sama, karena hal ini adalah sesuatu yang akan Anda kontrol langsung. Langkah ini termasuk memeriksa link di situs Anda untuk melihat apakah ada link yang menghasilkan kode respons 302 atau 301. Sering kali hal ini dapat disebabkan oleh tidak menyertakan skema https:// (jadi browser ditetapkan secara default ke http:// yang kemudian dialihkan) atau karena garis miring di akhir tidak disertakan atau dikecualikan dengan tepat dalam URL.

Pengalihan lintas origin lebih rumit karena sering kali berada di luar kendali Anda. Namun, cobalah untuk menghindari beberapa pengalihan jika memungkinkan—misalnya, dengan menggunakan penyingkat beberapa link saat membagikan link. Pastikan URL yang diberikan kepada pengiklan atau newsletter adalah URL final yang benar agar Anda tidak menambahkan pengalihan lain ke URL yang digunakan oleh layanan tersebut.

Sumber waktu pengalihan penting lainnya dapat berasal dari pengalihan HTTP-ke-HTTPS. Salah satu cara untuk mengatasi hal ini adalah dengan menggunakan header Strict-Transport-Security (HSTS), yang akan menerapkan HTTPS pada kunjungan pertama ke origin, lalu akan memberi tahu browser untuk segera mengakses origin melalui skema HTTPS pada kunjungan mendatang.

Setelah menerapkan kebijakan HSTS yang baik, Anda dapat mempercepat kunjungan ke situs origin dengan menambahkan situs Anda ke daftar pramuat HSTS.

Streaming markup ke browser

Browser dioptimalkan untuk memproses markup secara efisien ketika di-streaming, artinya markup ditangani dalam potongan saat tiba dari server. Ini adalah hal penting apabila berkaitan dengan payload markup yang besar, karena artinya browser dapat mengurai potongan markup secara bertahap, sebagai lawan dari menunggu seluruh respons tiba sebelum penguraian dapat dimulai.

Meskipun browser sangat hebat dalam menangani markup streaming, penting untuk melakukan semua yang Anda bisa untuk menjaga streaming tersebut tetap mengalir sehingga bit awal markup tersebut segera dikirim. Jika backend menahan semuanya, ini adalah masalah. Karena stack backend banyak, hal itu berada di luar cakupan panduan ini untuk mencakup setiap stack dan masalah yang dapat muncul di setiap stack tertentu.

React, misalnya—dan framework lain yang dapat merender markup sesuai permintaan di server—telah menggunakan pendekatan sinkron untuk rendering sisi server. Namun, versi React yang lebih baru telah menerapkan metode server untuk markup streaming saat sedang dirender. Ini berarti Anda tidak perlu menunggu metode API server React untuk merender seluruh respons sebelum dikirim.

Cara lain untuk memastikan markup di-streaming ke browser dengan cepat adalah dengan mengandalkan rendering statis yang menghasilkan file HTML selama waktu build. Dengan file lengkap yang segera tersedia, server web dapat langsung mulai mengirimkan file dan sifat bawaan HTTP akan menghasilkan markup streaming. Meskipun tidak cocok untuk setiap halaman di setiap situs—seperti yang memerlukan respons dinamis sebagai bagian dari pengalaman pengguna—pendekatan ini dapat bermanfaat untuk halaman yang tidak memerlukan markup agar dapat dipersonalisasi untuk pengguna tertentu.

Menggunakan pekerja layanan

Service Worker API dapat berdampak besar pada TTFB untuk dokumen dan resource yang dimuatnya. Alasannya adalah pekerja layanan bertindak sebagai proxy antara browser dan server—tetapi apakah ada dampak pada TTFB situs web Anda bergantung pada cara Anda menyiapkan pekerja layanan, dan apakah penyiapan tersebut sesuai dengan persyaratan aplikasi Anda.

• Gunakan strategi yang tidak berlaku saat validasi ulang untuk aset. Jika aset berada dalam cache pekerja layanan—baik itu dokumen atau resource yang diperlukan dokumen—strategi usang saat validasi ulang akan melayani resource tersebut dari cache terlebih dahulu, lalu akan mendownload aset tersebut di latar belakang dan menayangkannya dari cache untuk interaksi pada masa mendatang.
  • Jika Anda memiliki resource dokumen yang tidak terlalu sering berubah, penggunaan strategi yang sudah usang saat validasi ulang dapat membuat TTFB halaman hampir seketika. Namun, cara ini tidak akan berfungsi dengan baik jika situs Anda mengirim markup yang dibuat secara dinamis—seperti markup yang berubah berdasarkan apakah pengguna diautentikasi atau tidak. Dalam kasus semacam ini, Anda sebaiknya selalu terhubung ke jaringan terlebih dahulu, sehingga dokumen selalu baru.
  • Jika dokumen Anda memuat resource non-kritis yang berubah dengan beberapa frekuensi, tetapi pengambilan resource yang sudah tidak berlaku tidak akan terlalu memengaruhi pengalaman pengguna—seperti gambar tertentu atau resource lain yang tidak penting—TTFB untuk resource tersebut dapat dikurangi secara signifikan menggunakan strategi usang saat validasi ulang.
• Gunakan arsitektur pekerja layanan streaming jika memungkinkan. Arsitektur pekerja layanan ini menggunakan pendekatan dengan penyimpanan bagian resource dokumen dalam cache pekerja layanan, dan dikombinasikan dengan sebagian konten selama permintaan navigasi. Efek yang dihasilkan dari penggunaan pola pekerja layanan ini adalah navigasi akan cukup cepat, sementara payload HTML yang lebih kecil akan diunduh dari jaringan. Meskipun pola pekerja layanan ini tidak selalu berfungsi untuk setiap situs, waktu TTFB untuk resource dokumen dapat dilakukan secara instan bagi situs yang dapat menggunakannya.
• Gunakan model app shell untuk aplikasi yang dirender klien. Model ini paling cocok untuk SPA dengan "shell" halaman dapat dikirim secara instan dari cache pekerja layanan, dan konten dinamis halaman akan diisi dan dirender nanti di siklus proses halaman.

Gunakan 103 Early Hints untuk resource penting render

Terlepas dari seberapa baik backend aplikasi Anda dioptimalkan, mungkin masih ada banyak pekerjaan yang perlu dilakukan server untuk menyiapkan respons, termasuk pekerjaan database yang mahal (tetapi perlu) yang menunda respons navigasi agar tidak tiba secepat mungkin. Efek potensial dari hal ini adalah beberapa sumber daya penting render berikutnya dapat tertunda, seperti CSS atau—dalam beberapa kasus—JavaScript yang merender markup pada klien.

Header 103 Early Hints adalah kode respons awal yang dapat dikirim server ke browser saat backend sibuk menyiapkan markup. Header ini dapat digunakan untuk menunjukkan kepada browser bahwa ada resource penting render yang harus mulai didownload oleh halaman saat markup sedang disiapkan. Untuk mendukung browser, efeknya dapat berupa rendering dokumen (CSS) yang lebih cepat dan ketersediaan fungsi halaman inti (JavaScript) yang lebih cepat.

Kesimpulan

Karena ada begitu banyak kombinasi stack aplikasi backend, tidak ada satu artikel yang dapat merangkum semua yang dapat Anda lakukan untuk menurunkan TTFB situs Anda. Namun, ini adalah beberapa opsi yang dapat Anda coba untuk membuat semuanya berjalan lebih cepat di sisi server.

Seperti dalam mengoptimalkan setiap metrik, pendekatannya sebagian besar mirip: ukur TTFB Anda di lapangan, gunakan alat lab untuk melihat perincian penyebab, lalu terapkan pengoptimalan jika memungkinkan. Tidak semua teknik di sini mungkin cocok untuk situasi Anda, tetapi beberapa akan cocok. Seperti biasa, Anda harus terus memantau data kolom, dan melakukan penyesuaian sesuai kebutuhan untuk memastikan pengalaman pengguna secepat mungkin.

Banner besar oleh Taylor Vick, yang diambil dari Unsplash.