Time to First Byte (biasanya di singkat dengan TTFB) adalah durasi waktu yang di butuhkan oleh webserver untuk memberikan respon kepada HTTP request yang di kirimkan oleh browser klien.

Penjelasan sederhana time to first byte

Browser harus melakukan beberapa hal pada saat browser terhubung ke sebuah webserver. Breakdown-nya kurang lebih seperti ini:

  • Browser melakukan lookup DNS untuk URL yang di berikan
  • Browser melakukan inisiasi koneksi awal
  • Browser menunggu respon webserver
  • Browser menerima data dari webserver
  • Browser menutup koneksi yang terjadi ke webserver

Time to first byte adalah waktu yang di butuhkan browser untuk menunggu webserver memberikan data awal berupa HTTP response dan HTML.

Time to first byte berbeda dengan load time, karena TTFB hanya menghitung durasi waktu respon tanpa menghitung waktu loading aset-aset web (gambar-gambar, css, javascript dan sebagainya).

Sedangkan load time menghitung durasi waktu muat halaman website dari awal HTTP request di kirimkan browser sampai dengan seluruh aset website tersebut tampil sempurna pada browser.

TTFB merupakan faktor penting untuk menentukan kecepatan loading website. Semakin tinggi TTFB, maka semakin lambat website dimuat oleh browser, dan sebaliknya, jika TTFB rendah, maka semakin cepat website akan di tampilkan oleh browser.

Idealnya time to first byte terjadi kurang dari 400 ms. Bahkan Google punya standar sendiri untuk TTFB yang baik, yaitu kurang dari 200 ms. Ini merupakan PR tersendiri bagi para developer web dan administrator webserver yang ingin memiliki website dengan kecepatan akses yang maksimal.

tips-optimalisasi-time-first-byte-pada-webserver-nginx-01

Akselerasi website, secepat roket!

Faktor-faktor yang menentukan durasi time to first byte

Setidaknya ada 2 faktor utama yang menentukan durasi TTFB, yaitu:

Kecepatan dan responsivitas webserver

Kecepatan dan responsivitas webserver mengacu pada efesiensi kinerja dari daemon webserver (nginx, Apache, Lightspeed, dan sebagainya) dan server side scripting.

Latensi jaringan

Latensi jaringan / network latency juga sangat mempengaruhi TTFB. Oleh karena itu sangat penting untuk “merumahkan” website pada webserver yang memiliki koneksi cepat dan stabil.

Memahami mekanisme TTFB pada webserver

Time to first byte explained (courtesy KeyCDN).

Secara sederhana, proses webserver memberikan respon yang berisi data awal kepada browser. Kurang lebih prosedurnya seperti ini:

  • Webserver menerima permintaan dari browser
  • Webserver memeriksa halaman yang diminta webserver (biasanya halaman index dalam format standar web)
  • Webserver mengirimkan data berdasarkan permintaan browser
  • Webserver menutup koneksi yang terjadi ke browser

Jika website menggunakan konten yang bersifat dinamik (menggunakan server side scripting), maka prosedurnya akan bertambah, kurang lebih menjadi seperti ini:

  • Webserver menerima permintaan dari browser
  • Webserver memeriksa file yang diminta webserver dan bekerjasama dengan worker server side scripting
  • Jika di butuhkan, server side scripting akan men-generate dan mengkompilasi sebuah halaman (biasanya dalam format standar web) untuk memenuhi permintaan browser
  • Webserver mengirimkan data hasil generate / kompilasi server side scripting kepada browser
  • Webserver menutup koneksi yang terjadi ke browser

Jika website yang sobat kelola memiliki jumlah pengunjung yang tinggi, maka server akan terbebani untuk proses server side scripting. Dan ujung-ujungnya, TTFB juga akan melonjak drastis karena adanya antrian proses scripting.

Proses menerima respon dan memberikan respon seperti yang di jelaskan di atas idealnya hanya terjadi di bawah 400 ms. Dan harus di ingat bahwa, TTFB pada website dinamik pasti lebih tinggi jika di bandingkan dengan TTFB website statik.

Tips Optimalisasi Time to First Byte Pada Webserver NGINX

Nah, dalam kesempatan kali ini, admin akan membahas sedikit tips optimalisasi time to first byte pada webserver NGINX. Admin tidak membahas optimalisasi TTFB pada server side scripting secara spesifik, karena setiap website biasanya memiliki preferensi CMS atau backend yang berbeda-beda.

Advertisement

Rule to keep in thumb: TTFB pada website dinamik pasti lebih tinggi jika di bandingkan dengan TTFB website statik.

Oleh karena itu, jika sobat hanya me-manage website yang kontennya statik, sobat tidak perlu repot-repot untuk melakukan tuning TTFB. Namun sebaliknya, jika website yang sobat kelola memiliki konten dinamik dan pengunjung yang tinggi, maka di perlukan sedikit ‘sentuhan’ untuk mengoptimalkan TTFB.

Fast loading website = happy visitor + better conversions

Kenapa website dinamis memiliki TTFB tinggi? Jawabannya adalah karena konten dinamis membutuhkan waktu tambahan untuk di generate, dan proses generate seperti ini akan terulang setiap ada pengunjung baru di website kita.

Jadi untuk meminimalisir proses generate konten yang berulang, perlu di terapkan mekanisme caching.

Mekanisme caching memungkinkan webserver untuk menyimpan sementara halaman atau konten hasil generate dari server side scripting ke dalam bentuk file statik. Sehingga, proses generate halaman atau konten website tidak perlu terjadi berulang-ulang.

Berdasarkan pengalaman admin, proses caching ini mampu memangkas time to first byte antara 100 – 300 ms, tergantung pada spesifikasi webserver. Sangat signifikan menjadikan website menjadi lebih cepat di akses dan di muat oleh browser.

Pada webserver NGINX, terdapat modul caching bawaan, yaitu fastcgi_cache. Modul ini bisa di terapkan dengan mudah kedalam konfigurasi NGINX.

Cara Mengaktifkan Modul fastcgi_cache NGINX

Cara mengaktifkan fastcgi_cache pada NGINX cukup mudah di lakukan, cukup menambahkan beberapa baris parameter pada file konfigurasi NGINX.

Misalnya, isi file konfigurasi untuk fazar.net adalah seperti di bawah ini:

server {
 ....
 listen 80;
 server_name www.fazar.net;
 index index.php index.html;
 root /var/www/fazar.net;
 ....
}

Untuk mengaktifkan fastcgi_cache, tambahkan beberapa parameter seperti yang terlihat di bawah ini:

# fastcgi enabled
fastcgi_cache_path /etc/nginx-cache levels=1:2 keys_zone=phpcache:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
 ....
 listen 80;
 server_name www.fazar.net;
 index index.php index.html;
 root /var/www/fazar.net;
 fastcgi_cache phpcache; 
 fastcgi_cache_valid 200 30m;
 fastcgi_cache_methods GET HEAD;
 add_header X-FastCache $upstream_cache_status;
 ....
}

Setelah melakukan perubahan, lakukan restart atau reconfigure NGINX.

Untuk melakukan pengetesan apakah fastcgi_cache sudah berjalan baik, silakan fetch header pada website yang di tuju.

Saat pertama kali di akses dan sebelum cache di hit.

root@fazar:~# curl -I www.fazar.net
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 23 Nov 2017 07:07:20 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 23 Nov 2017 10:07:01 GMT
Cache-Control: max-age=10800
X-FastCache: MISS

Saat kedua kali di akses dan cache berhasil di hit.

root@fazar:~# curl -I www.fazar.net
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 23 Nov 2017 07:07:05 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 23 Nov 2017 10:07:25 GMT
Cache-Control: max-age=10800
X-FastCache: HIT

Sobat juga bisa menggunakan beberapa online tools untuk mengetest time to first byte website yang sudah sobat tuning, misalnya dengan menggunakan ByteCheck atau dengan menggunakan utility dari KeyCDN.

Saat pertama kali di akses dan sebelum cache di hit.

Tips Optimalisasi Time to First Byte Pada Webserver NGINX

Saat kedua kali di akses dan cache berhasil di hit.

Tips Optimalisasi Time to First Byte Pada Webserver NGINX

Terlihat bedanya kan?

Oh ya, jika sobat masih kurang puas dengan mekanisme fastcgi_caching di NGINX, maka sobat bisa bereksperimen di level server side scripting, misalnya dengan mengurangi query ke database, caching database query, efisiensi di dalam rutin script, dan sebagainya.

Related Posts

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *