Mengoptimalkan Time to First Byte

Pelajari cara mengoptimalkan metrik Time to First Byte.

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

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

Nilai TTFB yang baik adalah 0,8 detik atau kurang, nilai yang buruk lebih besar dari 1,8 detik, dan nilai di antara keduanya perlu ditingkatkan

Cara Mengukur TTFB

Sebelum dapat mengoptimalkan TTFB, Anda perlu mengamati 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 kali diukur menggunakan URL akhir sehingga tidak mendeteksi penundaan tambahan ini.

PageSpeed Insights adalah salah satu cara untuk mendapatkan informasi lapangan dan lab untuk situs publik yang tersedia di Laporan Pengalaman Pengguna Chrome.

TTFB untuk pengguna sebenarnya ditampilkan di bagian atas Mencari tahu pengalaman pengguna Anda yang sebenarnya:

Data pengguna sebenarnya PageSpeed Insights, termasuk data kolom untuk metrik TTFB.

Subkumpulan TTFB ditampilkan di audit waktu respons server:

Audit waktu respons server

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

Men-debug TTFB tinggi di kolom dengan Server-Timing

Header respons Server-Timing dapat digunakan di backend aplikasi Anda untuk mengukur proses backend yang berbeda yang dapat berkontribusi pada latensi tinggi. Struktur nilai header bersifat fleksibel, setidaknya menerima nama sebutan channel 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 database
  • Waktu rendering sisi server, jika berlaku
  • Pencarian disk
  • Hit/miss cache server Edge (jika menggunakan CDN)

Semua bagian entri Server-Timing dipisahkan 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 ditetapkan menggunakan bahasa backend aplikasi pilihan Anda. Misalnya, di PHP, Anda dapat menetapkan header seperti ini:

<?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 - $dbReadStartTime) / 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 di lab, dan di lapangan.

Di kolom ini, 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 divisualisasi di panel pengaturan waktu pada tab Jaringan di Chrome DevTools:

Visualisasi nilai header Server-Timing di tab Jaringan Chrome DevTools. Dalam gambar ini, nilai header Server-Timing mengukur apakah server edge CDN mengalami hit atau miss cache, serta waktu untuk mengambil resource dari edge dan server origin.

Header respons Server-Timing yang 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 permintaan untuk mencapai server edge CDN, lalu origin.

Setelah menentukan bahwa Anda memiliki TTFB yang bermasalah dengan menganalisis data yang tersedia, Anda dapat melanjutkan untuk memperbaiki masalah tersebut.

Cara mengoptimalkan TTFB

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

Panduan khusus platform

Platform yang Anda gunakan untuk situs dapat sangat memengaruhi TTFB. Misalnya, performa WordPress dipengaruhi oleh jumlah dan kualitas plugin, atau tema yang digunakan. Platform lain juga terpengaruh dengan cara yang sama saat platform tersebut disesuaikan. Anda harus melihat dokumentasi untuk platform Anda guna mendapatkan saran khusus vendor untuk melengkapi saran performa yang lebih umum dalam postingan ini. Audit Lighthouse untuk mengurangi waktu respons server juga menyertakan beberapa panduan khusus stack terbatas.

Hosting, hosting, hosting

Sebelum mempertimbangkan pendekatan pengoptimalan lainnya, hosting harus menjadi hal pertama yang Anda pertimbangkan. Tidak ada banyak panduan spesifik yang dapat ditawarkan di sini, tetapi aturan umum yang dapat diterapkan adalah memastikan bahwa host situs Anda mampu menangani traffic yang Anda kirim ke sana.

Hosting bersama umumnya akan lebih lambat. Jika Anda menjalankan situs pribadi kecil yang sebagian besar menayangkan file statis, hal ini mungkin tidak masalah, dan beberapa teknik pengoptimalan yang akan dijelaskan berikut akan membantu Anda mengurangi 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 sangat penting untuk menurunkan TTFB di lapangan.

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

  • Berapa banyak memori yang dialokasikan untuk instance aplikasi Anda? Jika aplikasi Anda tidak memiliki memori yang memadai, aplikasi akan mengalami thrashing dan kesulitan untuk menayangkan halaman secepat mungkin.
  • Apakah penyedia hosting Anda selalu mengupdate stack backend Anda? Seiring dengan dirilisnya versi baru bahasa backend aplikasi, implementasi HTTP, dan software database, performa software tersebut akan ditingkatkan seiring waktu. Anda harus berpartner dengan penyedia hosting yang memprioritaskan pemeliharaan penting semacam ini.
  • Jika Anda memiliki persyaratan aplikasi yang sangat spesifik dan menginginkan akses tingkat terendah ke file konfigurasi server, tanyakan apakah sebaiknya menyesuaikan backend instance aplikasi Anda sendiri.

Ada banyak penyedia hosting yang akan menangani hal-hal ini untuk Anda, tetapi jika Anda mulai mengamati nilai TTFB yang lama bahkan di penyedia hosting khusus, hal ini mungkin merupakan tanda bahwa Anda mungkin perlu mengevaluasi kembali kemampuan penyedia hosting saat ini agar dapat memberikan pengalaman pengguna terbaik.

Menggunakan Jaringan Penayangan Konten (CDN)

Topik penggunaan CDN sudah sering dibahas, tetapi ada alasan yang baik: Anda mungkin memiliki backend aplikasi yang dioptimalkan dengan sangat baik, tetapi pengguna yang berada jauh dari server origin Anda mungkin masih mengalami TTFB tinggi di lapangan.

CDN memecahkan masalah kedekatan pengguna dari server origin Anda dengan menggunakan jaringan server terdistribusi yang meng-cache resource di 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 menjadi andalan 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 mencegat permintaan, mengelola respons secara terprogram di cache edge, atau menulis ulang respons secara keseluruhan.
  • Penyedia CDN sangat mahir dalam mengoptimalkan kompresi. Kompresi sulit dilakukan sendiri, dan dapat menyebabkan waktu respons yang lebih lambat dalam kasus tertentu dengan markup yang dibuat secara dinamis, yang harus dikompresi dengan cepat.
  • Penyedia CDN juga akan otomatis meng-cache respons yang dikompresi untuk resource statis, sehingga menghasilkan kombinasi terbaik antara rasio kompresi dan waktu respons.

Meskipun penggunaan CDN memerlukan upaya yang bervariasi, mulai dari yang sepele hingga yang signifikan, CDN harus menjadi prioritas utama dalam mengoptimalkan TTFB jika situs Anda belum menggunakannya.

Menggunakan konten yang di-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 tidak sesuai untuk konten yang dipersonalisasi, mewajibkan perjalanan kembali ke origin dapat meniadakan banyak nilai CDN.

Untuk situs yang sering memperbarui kontennya, bahkan waktu penyimpanan dalam cache yang singkat dapat menghasilkan peningkatan performa yang signifikan untuk situs yang sibuk, karena hanya pengunjung pertama selama waktu tersebut yang mengalami latensi penuh kembali ke server asal, sementara semua pengunjung lainnya dapat menggunakan kembali resource yang di-cache dari server edge. Beberapa CDN mengizinkan pembatalan validasi cache pada rilis situs sehingga Anda mendapatkan yang terbaik dari kedua sisi—waktu cache yang lama, tetapi pembaruan instan saat diperlukan.

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

Konten lama atau yang jarang dikunjungi mungkin juga tidak di-cache, yang dapat menyebabkan nilai TTFB di beberapa halaman lebih tinggi daripada yang lain. Meningkatkan waktu penyimpanan dalam cache dapat mengurangi dampaknya, tetapi perlu diketahui bahwa dengan meningkatnya waktu penyimpanan dalam cache, kemungkinan untuk menampilkan konten yang berpotensi sudah tidak berlaku akan semakin besar.

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

Hindari pengalihan halaman lebih dari satu kali

Salah satu kontributor umum 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 tentu dapat menambahkan latensi yang tidak diinginkan ke permintaan navigasi, tetapi hal ini dapat menjadi lebih buruk jika pengalihan tersebut mengarah ke resource lain yang menghasilkan pengalihan lain—dan seterusnya. Hal ini dapat memengaruhi situs yang menerima banyak pengunjung dari iklan atau newsletter, karena situs tersebut sering kali mengalihkan pengunjung melalui layanan analisis untuk tujuan pengukuran. Menghapus pengalihan yang berada di bawah kontrol langsung Anda dapat membantu mencapai TTFB yang baik.

Ada dua jenis pengalihan:

  • Pengalihan dengan origin yang sama, yang pengalihannya terjadi sepenuhnya di situs Anda.
  • Pengalihan lintas origin, yang awalnya terjadi di origin lain—misalnya dari layanan penyingkatan URL media sosial—sebelum diarahkan ke situs Anda.

Anda ingin berfokus untuk menghilangkan pengalihan dengan origin yang sama, karena Anda akan memiliki kontrol langsung atas hal ini. Hal ini akan melibatkan pemeriksaan 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:// (sehingga browser secara default menggunakan http:// yang kemudian mengalihkan) atau karena garis miring di akhir tidak disertakan atau dikecualikan dengan benar dalam URL.

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

Sumber penting lainnya dari waktu pengalihan 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 berikutnya.

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

Melakukan streaming markup ke browser

Browser dioptimalkan untuk memproses markup secara efisien saat di-streaming, yang berarti markup ditangani dalam beberapa bagian saat tiba dari server. Hal ini sangat penting jika payload markup besar menjadi masalah, karena berarti browser dapat mengurai potongan markup secara bertahap, bukan menunggu seluruh respons tiba sebelum penguraian dapat dimulai.

Meskipun browser sangat andal dalam menangani markup streaming, Anda harus melakukan semua yang Anda bisa untuk menjaga aliran streaming tersebut sehingga bit awal markup tersebut akan segera ditampilkan. Jika backend mengalami masalah, itu akan menjadi masalah. Karena ada banyak stack backend, cakupan panduan ini tidak akan mencakup setiap stack dan masalah yang dapat muncul di setiap stack tertentu.

React, misalnya—dan framework lain yang dapat merender markup secara on demand di server—telah menggunakan pendekatan sinkron untuk rendering sisi server. Namun, React versi yang lebih baru telah menerapkan metode server untuk streaming markup saat dirender. Artinya, Anda tidak perlu menunggu metode API server React 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 langsung tersedia, server web dapat langsung mulai mengirim file dan sifat inheren HTTP akan menghasilkan markup streaming. Meskipun pendekatan ini tidak cocok untuk setiap halaman di setiap situs—seperti halaman yang memerlukan respons dinamis sebagai bagian dari pengalaman pengguna—pendekatan ini dapat bermanfaat untuk halaman yang tidak memerlukan markup untuk dipersonalisasi bagi pengguna tertentu.

Menggunakan pekerja layanan

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

  • Gunakan strategi stale-while-revalidate untuk aset. Jika aset berada di cache pekerja layanan—baik dokumen maupun resource yang diperlukan dokumen—strategi stale-while-revalidate akan melayani resource tersebut dari cache terlebih dahulu, lalu akan mendownload aset tersebut di latar belakang dan menayangkannya dari cache untuk interaksi mendatang.
    • Jika Anda memiliki resource dokumen yang jarang berubah, menggunakan strategi stale-while-revalidate dapat membuat TTFB halaman hampir instan. Namun, hal ini tidak berfungsi dengan baik jika situs Anda mengirimkan markup yang dibuat secara dinamis—seperti markup yang berubah berdasarkan apakah pengguna diautentikasi atau tidak. Dalam kasus seperti itu, Anda harus selalu mengakses jaringan terlebih dahulu, sehingga dokumen akan selalu terbaru.
    • Jika dokumen Anda memuat resource non-penting yang berubah dengan frekuensi tertentu, 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 stale-while-revalidate.
  • Gunakan model shell aplikasi untuk aplikasi yang dirender klien. Model ini paling cocok untuk SPA tempat "shell" halaman dapat dikirimkan secara instan dari cache pekerja layanan, dan konten dinamis halaman diisi dan dirender nanti dalam siklus proses halaman.

Menggunakan 103 Early Hints untuk resource yang penting untuk rendering

Tidak peduli seberapa baik backend aplikasi Anda dioptimalkan, mungkin masih ada banyak pekerjaan yang perlu dilakukan server untuk menyiapkan respons, termasuk pekerjaan database yang mahal (tetapi diperlukan) yang menunda respons navigasi agar tidak tiba secepat mungkin. Potensi efeknya adalah beberapa resource penting render berikutnya dapat tertunda, seperti CSS atau—dalam beberapa kasus—JavaScript yang merender markup di klien.

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

Kesimpulan

Karena ada begitu banyak kombinasi stack aplikasi backend, tidak ada satu artikel pun yang dapat merangkum semuanya yang dapat Anda lakukan untuk menurunkan TTFB situs. Namun, berikut beberapa opsi yang dapat Anda jelajahi untuk mencoba mempercepat proses di sisi server.

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

Gambar hero oleh Taylor Vick, bersumber dari Unsplash.