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 yang penting lainnya, seperti First Contentful Paint (FCP) dan Largest Contentful Paint (LCP). Ini berarti nilai TTFB yang tinggi menambahkan waktu pada 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 berupaya memiliki TTFB 0,8 detik atau kurang.

Cara Mengukur TTFB

Sebelum dapat mengoptimalkan TTFB, Anda perlu mengamati bagaimana TTFB memengaruhi pengguna situs web 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 final sehingga tidak ada penundaan tambahan ini.

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

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

Sebagian TTFB ditampilkan dalam audit waktu respons server:

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

Debug TTFB tinggi di kolom dengan Server-Timing

Header respons Server-Timing dapat digunakan di backend aplikasi Anda untuk mengukur proses backend berbeda yang dapat berkontribusi pada latensi tinggi. Struktur nilai header fleksibel, menerima, minimal, 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 beri perhatian khusus:

• Kueri {i>database<i}
• Waktu rendering sisi server, jika berlaku
• Pencarian disk
• Cache server edge tidak ditemukan (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 pilihan Anda. Di PHP, misalnya, Anda dapat menetapkan {i>header<i} 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 - $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 di lab dan di kolom.

Di kolom ini, setiap halaman dengan kumpulan header respons Server-Timing 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 permintaan untuk mencapai server edge CDN, lalu ke server asal.

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

Cara mengoptimalkan TTFB

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

Panduan khusus platform

Platform yang Anda gunakan untuk situs web Anda dapat berdampak besar pada TTFB. Misalnya, performa WordPress dipengaruhi oleh jumlah dan kualitas plugin, atau tema yang digunakan. Platform lain juga akan terkena dampak yang serupa saat platform tersebut disesuaikan. Sebaiknya baca dokumentasi untuk platform Anda guna 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 yang terbatas.

Hosting, hosting, hosting

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

Hosting bersama biasanya akan lebih lambat. Jika Anda menjalankan situs web pribadi kecil yang sebagian besar menyajikan file statis, ini mungkin tidak masalah, dan beberapa teknik pengoptimalan selanjutnya 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 instance aplikasi Anda? Jika aplikasi Anda tidak memiliki memori yang cukup, aplikasi akan menghancurkan dan berupaya menyajikan halaman secepat mungkin.
• Apakah penyedia hosting selalu memperbarui stack backend Anda? Seiring dengan dirilisnya versi baru bahasa backend aplikasi, implementasi HTTP, dan software database, performa dalam software tersebut akan ditingkatkan dari waktu ke waktu. Sangat penting untuk bermitra 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 masuk akal untuk 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 panjang bahkan pada penyedia hosting khusus, ini mungkin tanda bahwa Anda mungkin perlu mengevaluasi kembali kemampuan penyedia hosting Anda saat ini sehingga Anda dapat memberikan pengalaman pengguna sebaik mungkin.

Menggunakan Jaringan Penayangan Konten (CDN)

Topik Penggunaan CDN sudah usang, tetapi untuk alasan yang bagus: Anda bisa memiliki backend aplikasi yang dioptimalkan dengan sangat baik, tetapi pengguna yang berada jauh dari server asal Anda mungkin masih mengalami TTFB yang tinggi di bidang tersebut.

CDN mengatasi masalah jarak pengguna dari server asal dengan menggunakan jaringan server terdistribusi yang menyimpan resource ke dalam cache di server yang secara fisik lebih dekat dengan pengguna Anda. Server ini disebut server edge.

Penyedia CDN juga dapat menawarkan manfaat selain server edge:

• Penyedia CDN biasanya menawarkan waktu resolusi DNS yang sangat cepat.
• CDN kemungkinan akan menyajikan konten Anda dari server edge menggunakan protokol modern seperti HTTP/2 atau HTTP/3.
• HTTP/3 secara khusus menyelesaikan masalah pemblokiran head-of-line yang ada di TCP (yang diandalkan HTTP/2) dengan menggunakan protokol UDP.
• CDN kemungkinan juga akan menyediakan versi TLS modern, yang menurunkan latensi yang ada dalam waktu negosiasi TLS. TLS 1.3 khususnya dirancang untuk menjaga 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 didapat dengan benar, dan dalam kasus tertentu dapat menyebabkan waktu respons yang lebih lambat, dengan markup yang dibuat secara dinamis, yang harus dikompresi dengan cepat.
• Penyedia CDN juga akan secara otomatis menyimpan respons terkompresi untuk resource statis dalam cache, yang menghasilkan perpaduan terbaik antara rasio kompresi dan waktu respons.

Meskipun adopsi CDN melibatkan berbagai upaya dari yang sederhana hingga signifikan, prioritas tinggi harus diupayakan dalam mengoptimalkan TTFB Anda jika situs web Anda belum menggunakannya.

Menggunakan konten yang di-cache jika memungkinkan

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

Untuk situs yang sering memperbarui kontennya, bahkan waktu caching yang singkat dapat mengakibatkan peningkatan performa yang nyata untuk situs sibuk, karena hanya pengunjung pertama selama waktu tersebut yang akan mengalami latensi penuh kembali ke server asal, sementara semua pengunjung lainnya dapat menggunakan kembali resource yang di-cache dari server edge. Beberapa CDN memungkinkan pembatalan cache pada rilis situs, sehingga memungkinkan yang terbaik dari keduanya, yaitu waktu cache yang lama, tetapi update instan jika diperlukan.

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

Konten yang lebih lama atau kurang sering dikunjungi juga tidak dapat di-cache, yang dapat menghasilkan nilai TTFB yang lebih tinggi di beberapa halaman dibandingkan halaman lain. Peningkatan waktu penyimpanan dalam cache dapat mengurangi dampak ini, tetapi perhatikan bahwa dengan meningkatnya waktu penyimpanan dalam cache, penayangan konten yang berpotensi usang akan lebih besar.

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

Hindari pengalihan halaman lebih dari satu kali

Salah satu kontributor umum untuk 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 saja dapat menambahkan latensi yang tidak diinginkan ke permintaan navigasi, tetapi tentu dapat lebih buruk jika pengalihan tersebut mengarah ke resource lain yang menghasilkan pengalihan lain—dan seterusnya. Hal ini dapat memengaruhi situs yang menerima volume pengunjung yang tinggi 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 origin yang sama, yang pengalihan terjadi sepenuhnya di situs Anda.
• Pengalihan lintas origin, yakni saat pengalihan terjadi di awal yang lain—seperti dari layanan pemendekan URL media sosial, misalnya—sebelum tiba di situs Anda.

Anda ingin berfokus untuk menghilangkan pengalihan dari origin yang sama karena ini adalah sesuatu yang akan Anda kontrol langsung. Langkah 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:// (jadi browser ditetapkan secara default ke http:// yang kemudian mengalihkan) atau karena garis miring akhir tidak disertakan atau dikecualikan dengan benar di 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 URL yang digunakan oleh layanan tersebut.

Sumber waktu pengalihan penting lainnya dapat berasal dari pengalihan HTTP-ke-HTTPS. Salah satu cara yang dapat Anda lakukan adalah dengan menggunakan header Strict-Transport-Security (dataset), 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 dataset yang baik, Anda dapat mempercepat proses pada kunjungan pertama ke origin dengan menambahkan situs Anda ke daftar pramuat ](

Mengalirkan markup ke browser

Browser dioptimalkan untuk memproses markup secara efisien saat di-streaming, yang berarti bahwa markup ditangani dalam potongan saat tiba dari server. Hal ini sangat penting ketika muatan markup yang besar diperhatikan, karena hal ini berarti browser dapat mengurai potongan markup secara bertahap, bukan menunggu seluruh respons tiba sebelum penguraian dapat dimulai.

Meskipun browser hebat dalam menangani markup streaming, Anda harus melakukan semua yang Anda bisa untuk menjaga streaming tersebut tetap mengalir sehingga bagian awal markup tersebut dapat digunakan sesegera mungkin. Jika backend bermasalah, itu adalah masalah. Karena stack backend sangat banyak, maka akan berada di luar cakupan panduan ini untuk membahas 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. Artinya, 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 langsung tersedia, server web dapat segera mulai mengirim file tersebut dan sifat inheren HTTP akan menghasilkan markup streaming. Meskipun tidak cocok untuk setiap halaman di setiap situs, misalnya 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 dimuat. 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 yang sudah tidak berlaku saat validasi ulang untuk aset. Jika aset berada dalam cache pekerja layanan—baik berupa dokumen maupun 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 menyalurkannya dari cache untuk interaksi di masa mendatang.
  • Jika Anda memiliki aset dokumen yang tidak sering berubah, menggunakan strategi yang sudah tidak berlaku saat validasi ulang dapat membuat TTFB halaman hampir instan. Namun, hal ini tidak akan berfungsi dengan baik jika situs Anda mengirimkan markup yang dibuat secara dinamis—seperti markup yang berubah berdasarkan apakah pengguna telah diautentikasi. Dalam kasus ini, Anda sebaiknya beralih ke jaringan terlebih dahulu, agar dokumen terlihat baru.
  • Jika dokumen Anda memuat sumber daya non-kritis yang berubah dengan frekuensi tertentu, namun mengambil sumber daya yang usang tidak akan terlalu memengaruhi pengalaman pengguna—seperti gambar tertentu atau sumber daya lain yang tidak penting—TTFB untuk sumber daya tersebut dapat sangat dikurangi dengan menggunakan strategi yang sudah usang saat memvalidasi ulang.
• Gunakan model shell aplikasi untuk aplikasi yang dirender klien. Model ini paling cocok untuk SPA karena "shell" halaman dapat dikirim langsung dari cache pekerja layanan, dan konten dinamis halaman akan diisi dan dirender nanti dalam siklus proses halaman.

Menggunakan 103 Early Hints untuk resource penting render

Terlepas dari seberapa baik backend aplikasi Anda dioptimalkan, masih ada banyak pekerjaan yang perlu dilakukan server untuk menyiapkan respons, termasuk pekerjaan database yang mahal (tetapi diperlukan) yang menunda respons navigasi dari 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 mengisyaratkan ke browser bahwa ada sumber daya penting render yang harus mulai diunduh halaman saat markup sedang disiapkan. Untuk mendukung browser, efeknya dapat berupa lebih cepat rendering dokumen (CSS) dan ketersediaan fungsi halaman inti (JavaScript) yang lebih cepat.

Kesimpulan

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

Seperti halnya pengoptimalan setiap metrik, pendekatannya sangat mirip: ukur TTFB Anda di lapangan, gunakan alat lab untuk melihat perincian penyebabnya, lalu terapkan pengoptimalan jika memungkinkan. Tidak semua teknik di sini mungkin cocok untuk situasi Anda, tetapi beberapa mungkin cocok. Seperti biasa, Anda harus terus memantau data lapangan, dan melakukan penyesuaian yang diperlukan untuk memastikan pengalaman pengguna secepat mungkin.

Banner besar oleh Taylor Vick, bersumber dari Unsplash.