Ini adalah bagaimana saya menyelesaikan permasalahan saya dengan TTFB pada website saya yang berbasis PHP dengan database MySQL. pada awalnya TTFB saya lebih dari 15 detik. mudah-mudahan dapat membantu kawan-kawan yang mengalami masalah yang sama.

bagi kawan yang belum tau apa itu TTFB, ini pengertian yang saya kutip dari Mbah Wikipedia :

Time to first byte (TTFB) is a measurement used as an indication of the responsiveness of a webserver or other network resource. (https://en.wikipedia.org/wiki/Time_to_first_byte)
maksudnya kira-kira TTFB adalah waktu yang dibutuhkan oleh server kita untuk memberikan respons byte pertama data dari website kita. TTFB berhubungan lansung dengan kecepatan akses website kita, semakin lama TTFB maka dipastikan semakin lama waktu loading sebuah website. proses TTFB dapat dilihat pada saat mengakses sebuah website di browser, ditandai dengan proses menunggu atau dalam bahasa inggris nya whaiting.

untuk memahami tentang permasalahan TTFB ini, sebaiknya kita memahami bagaimana prosesnya sebuah website sampai ketangan kita melalui web browser, gambar berikut ini akan memberikan sedikit keterangan kepada kita
Proses Transfer data
Sumber : https://www.keycdn.com/support/what-is-ttfb/
dari gambar diatas kita bisa melihat sebuah proses yaitu visitor melalui peramban web nya mengirimkan permintaan melalui protokol transfer (HTTP Request) permintaan ini merupakan beberapa byte data yang mendeskripsikan konten yang dimintanya. kita mengenal ini dengan request url. request ini berisi pernyataan skema transfer (HTTP/HTTPS), host (domain/sub : Server), dan request uri. kemudian host memproses permintaan kita dan mengirimkan permintaan tersebut ke peramban website kita. analoginya biar mudah dipahami.

anda pasti pernah makan di rumah makan kan? hal pertama yang anda lakukan adalah memanggil pelayan nya, kita sebut proses ini dengan DNS Lookup. setelah pelayannya datang, kita bilang sama dia :

anda : "mas minta teh telor satu!" (di rumah makan kok mintak teh telor. wkwk).
si pelayan : "ok mas, tunggu sebentar ya",

mas mas nya kemudian meneruskan permintaaan kita ke dapur. jika ternyata tek telur nggk ada maka mas pelayannya bilang sama ente :

pelayan : "maaf mas, teh telor nggak ada, ada nya teh telor dadar sama telor mata sapi" (ternyata mas-mas nya orang sunda).

respons ini sudah bisa dikatakan sebagai TTFB, dalam hal ini barangkali dia ngasih kode HTTP 404. berbeda kasus jika teh telur ternyata terseda dan dapat di pesan. koki di dapur kemudian menjalankan prosedur pembuatan teh telur, (memproses file "misalnya" PHP). jika membutuhkan teh, telur, atau air panas dia mengambilnya dalam lemari (dalam hal ini database MySQL) *kok air panas diambil dari lemari yak

jika sudah selesai maka pesanan anda segera dikirim kepada anda (200 Ok). dalam hal ini yang dimaksud dengan TTFB adalah saat dimana si pelayan sampai dimeja anda membawa pesanan yang anda minta. setelah itu terserah anda, mau diminum atau dibuang tong sampah aja.

dari penjelasan dan analogi diatas menunjukkan kepada kita bahwa ada sangat banyak hal-hal yang kita tidak tau apapun yang terjadi selama proses hingga pesanan kita selesai dan sampai di meja kita. inilah mengapa memperbaiki TTFB menjadi tantangan tersendiri bagi developer website. mulai dari kecepatan koneksi internet, latensi waktu karena jarak antara visitor dan server (apalagi jika server anda di USA). dapat juga bagaimana server anda bekerja dan menangani request (file CGI dan PHP) hingga koneksi database anda (kebanyakan hosting meletakkan database dan disk pada server berbeda). bahkan kesalahan dapat juga berada pada browser visitor itu sendiri.

dari banyak artikel baik bahasa atau english yang saya pelajari, kebanyakan dari mereka menyalahkan penyedia hosting anda sebagai dalang utama, namun ke sebaiknya anda tidak berburuk sangka, seperti apa yang saya alami.

Kembali ke masalah saya

website saya di Genews.co.id adalah web yang mendapatkan masalah ini. saya menggunakan banyak tools untuk mengecek bagaimana kinerja website saya, mulai dari google console hingga GTMatrix, dalam hal ini saya menggunakan layanan GTMatrix.com, masalah saya cukup serius karena TTFB hingga 16 detik, anda bisa bayangkan berapa banyak orang yang menekan close dan kabur dari website saya hanya karena malas menuggu tanpa kepastian. berikut ss TTFB saya dari GTmatrix sebelum diperbaiki


 
sebagaimana banyak artikel di internet yang menyalahkan kualitas server anda sebagai tersangka utama dibalik  lemotnya TTFB yang anda alami. saya juga sempat berburuk sangka. saya meg-test website saya pada host lain. sialnya saya disuguhkan kenyataan yang sepertinya mendukung asumsi saya.

host demo yang saya gunakan untuk menuji website saya menyelesaikan TTFB saya hanya 1.42 detik!, sedangkan host yang saya gunakan menanganinya hingga 16.16 detik! pilihan pindah host mungkin menjadi pilihan yang tepat saya ambil menyikapi hal ini.

saya hanya menolak tergesa-gesa, saya mengecek di forum ternyata tidak ada develover yang mengalami masalah seperti saya di host yang sama dengan saya. ini sebuah antitesis tentunya bagi keputusan saya. seorang develover tentu tidak ingin hasil kerjanya dibawah rata-rata.
 
saya mengambil langkah untuk mengukur kecepatan eksekusi script saya, berhubung semua request ditangani oleh file index.php saya menuliskan script berikut di file index.php


​ hasilnya adalah sebagai berikut :

benarkah 15 ms? haha. tidak masuk akal. ternyata saya tertipu dengan kesalahan typo saya sendiri. harusnya saya tulis "detik pada script microtime() saya. pengukuran diatas artinya lama eksekusi script saya adalah 15.5994xxxx DETIK! .saya berkesimpulan masalah ini adalah di script yang saya buat!
 
ternyata benar masalah ini disebabkan bagaimana script PHP saya berinteraksi dengan database. terbukti ketika saya mengganti prosedur koneksi database dari yang sebelumnya menggunakan MySQLi prosedural menjadi MySQLi berbasis object. masalah saya lansung terselesaikan.

banyak permintaan koneksi Mysql

mempermudah select dengan memanfaatkan function memaksa saya membuka dan menutup koneksi setiap kali selesai mengeksekusi sebuah function. ini menyebabkan script saya membuat hingga puluhan kali putus-nyambung koneksi ke database dalam satu proses. (kayak nya script saya susah move on. wkwk).
 
pada server sebagaian hosting ini tidak menjadi maslah, namun di hosting saya sekarang sepertinya ada latensi yang cukup besar saat membuat koneksi ke database. mungkin, sekali lagi mungkin host saya yang sekarang meletakkan database dan disk di komputer yang berbeda atau trafik koneksi ke database cukup besar dari akun shared karena saya menggunakan shared hosting (maunya yang murah aja. wkwk).
 
Banyaknya permintaan MySQL adalah tersangka utama, oleh sebab itu saya mendesign sebuah class yang menangani koneksi ke database dengan menampung hasil request dalam bentuk array, saat permintaan "SELECT" ke database dengan query yang sama tidak lagi akan diload dari database, melainkan menggunakan hasil select sebelumnya saja. sebelumnya saya banyak mengulang prosedur SELECT dengan query yang sama untuk keperluan widget (dengan memanfaatkan function di PHP), namun dengan bantuan class yang saya buat permintaan bisa dikurangi secara signifikan. 

koneksi database berbasis objek

saya memutuskan untuk  mempermudah koneksi dengan menggunakan objek. kita dapat membuat koneksi pada metode "__construct()" dan dan menutup koneksi pada metode "__destruct()". kita dapat menjalankan perintah select dengan metode tersendiri dan menyimpannya pada sebuah variabel yang diproteksi. ketika metode select dijalankan kembali, metode dapat mengecek query kita apakah sudah pernah dijalankan sebelumnya, jika sudah pernah maka cukup berikan return dengan nilai query sebelumnya, jika querynya baru maka minta data tersebut dari database berhubung koneksi belum ditutup. hehe. struktur array yang saya buat adalah multiple array dengan query mySQL sebagai key nya, dengan demikian akan mempermudah pengecekan apakah query sudah pernah dilakukan sebelumnya atau tidak cukup dengan perinta "if isset". ini adalah bentuk dasar algoritma class saya dan saya masih mengerjakan improv class tersebut agar lebih efisien.

terimakasih sudah baca sampai di paragraf ini. mohon kritik dan sarannya atau jika ada pertanyaan tinggalkan komentar dibawah.