Sekarang saya sedang mengerjakan proyek untuk satu klien. Ini adalah situs e-commerce, jadi saya sangat tertarik dengan beberapa aspek kinerja. Sebagai permulaan, ini adalah berbagai indikator yang mencirikan waktu pemuatan suatu situs. Berikutnya - ini adalah waktu mulai merender halaman, yang penting bagi pengunjung yang, setelah memasuki situs, ingin melihat isinya secepat mungkin (tentu saja, semua pengunjung situs termasuk dalam kategori ini). Di antara indikator kinerja yang menarik minat saya adalah yang mencerminkan spesifikasi aktivitas klien saya. Misalnya: "Seberapa cepat gambar utama memuat produk?" Analisis semua indikator ini dapat memberikan informasi berharga tentang keadaan proyek.
Namun, ada satu indikator, yang, sepertinya, pengembang front-end sering tidak memperhatikan. Sudah waktunya untuk byte pertama (Waktu ke Byte Pertama, TTFB). Anda dapat memahami ini, Anda dapat dan setidaknya memaafkan sebagian pengembang atas sikap terhadap TTFB, terutama mengingat fakta bahwa mereka melihat indikator ini sebagai sesuatu yang hanya bergantung pada bagian belakang proyek. Tetapi jika kita mencoba untuk secara singkat mengungkapkan masalah mengenai indikator ini, maka kita dapat mengatakan yang berikut: "Meskipun nilai TTFB yang baik tidak selalu berarti bahwa situs web yang mendemonstrasikannya dapat dianggap cepat, indikator TTFB yang buruk hampir pasti mengindikasikan masalah dengan kinerja proyek."
Bahkan jika kita memperhitungkan fakta bahwa pengembang front-end mungkin berada dalam posisi di mana ia tidak dapat memengaruhi backend dan TTFB secara independen, penting untuk mempertimbangkan fakta bahwa nilai-nilai TTFB yang tinggi dapat secara signifikan mempengaruhi kinerja situs. Akibatnya, upaya pengembang front-end yang berjuang untuk kecepatan situs web akan menyerupai game catch-up. Ini berlaku, misalnya, untuk pengoptimalan gambar, dan untuk meminimalkan volume materi yang membentuk bagian paling penting dari proyek, dan untuk mengunduh font web secara asinkron. Ini bukan untuk mengatakan bahwa, mengetahui hal ini, Anda dapat menyerah dan mengabaikan optimisasi front-end. Tetapi jika TTFB terlalu tinggi, maka semua optimasi tersebut mengingatkan untuk mencoba memperbaiki masalah dalam kondisi ketika sudah membahayakan, dan ketika sudah terlambat untuk memperbaiki masalah ini. Faktanya, itu sebabnya sangat penting bagi mereka yang mengembangkan front-end untuk memonitor indikator TTFB, dan sangat penting, ketika nilainya terlalu tinggi, mengambil langkah-langkah untuk memperbaikinya.
Apa itu TTFB?
TTFB tidak terlihat sangat informatif ( gambar ukuran penuh )TTFB adalah indikator yang terlihat, lebih tepatnya, buram. Begitu banyak yang dipengaruhi olehnya sehingga saya merasa bahwa kita semua hanya menghabiskan analisisnya yang serius. Banyak yang berspekulasi bahwa TTFB hanyalah waktu yang dibutuhkan server untuk menyiapkan respons, tetapi kenyataannya, hanya sebagian kecil dari apa yang memengaruhi TTFB.
Hal pertama yang saya ingin menarik perhatian Anda adalah setelah mengetahui apa yang biasanya orang sangat terkejut. Kita berbicara tentang fakta bahwa TTFB mencakup waktu ketika permintaan dari klien berpindah jaringan ke server, dan waktu yang dibutuhkan jalur tanggapan server ke klien. Inilah yang disebut "waktu perjalanan pulang pergi" (Round Trip Time, RTT). TTFB bukan hanya beberapa waktu yang dihabiskan oleh server menyiapkan tanggapan. Ini juga merupakan waktu yang dihabiskan untuk cara data berpindah dari klien ke server dan dari server ke klien (data ini, tentu saja, berisi "byte pertama" yang menarik bagi kami).
Sekarang, dengan berbekal pengetahuan ini, kita dapat dengan mudah memahami alasan bahwa ketika melihat situs dari perangkat seluler, indikator TTFB sering kali tidak besar. Sangat mungkin bahwa sebelumnya dalam situasi seperti itu Anda akan bertanya sesuatu seperti ini: "Saya yakin server tidak tahu bahwa saya melihat situs dari ponsel. Lalu bagaimana cara meningkatkan TTFB? ” Alasannya adalah karena koneksi jaringan seluler adalah koneksi latensi tinggi. Jika indikator RTT, yang mencerminkan waktu yang diperlukan untuk data untuk melakukan perjalanan dari telepon ke server dan kembali, misalnya, 250 ms, maka TTFB akan meningkat dengan nilai yang sesuai.
Jika saya ingin pembaca materi ini hanya mengambil satu ide utama darinya, maka saya akan merumuskan ide ini sebagai berikut: "Keterlambatan jaringan memengaruhi TTFB."
Apa lagi yang memengaruhi TTFB? Bahkan - banyak semuanya. Berikut ini adalah daftar yang jauh dari lengkap tentang apa yang berkontribusi pada pembentukan indikator ini. Item dalam daftar ini dalam urutan acak.
- Keterlambatan jaringan. Seperti yang telah disebutkan, TTFB mencakup waktu yang diperlukan untuk mengirimkan permintaan ke server dan mengembalikan respons dari server. Ambil, misalnya, waktu yang diperlukan untuk sesi pertukaran data antara perangkat yang berlokasi di London dan server yang berlokasi di New York. Idealnya, saat menggunakan koneksi serat optik, ini adalah 28 ms. Tetapi ini didasarkan pada banyak asumsi yang sangat optimis. Pada kenyataannya, Anda harus mengharapkan sekitar 75 ms . Itulah mengapa sangat penting untuk menggunakan CDN. Bahkan sekarang, di zaman Internet, kedekatan geografis suatu bisnis dan pelanggannya merupakan keuntungan.
- Routing Jika Anda menggunakan CDN (dan memang seharusnya begitu!), Maka permintaan klien Anda, katakanlah, dari Leeds, dapat dialihkan ke pusat data MAN saja sehingga ternyata sumber daya yang dibutuhkan klien tidak ada dalam cache PoP yang sesuai . Kemudian permintaan akan dialihkan ke server nyata dengan materi Anda untuk tetap mengirimkan kepada klien apa yang dibutuhkan. Jika server ini berlokasi, misalnya, di Virginia, maka semua hal di atas akan menyebabkan peningkatan TTFB yang serius tanpa alasan yang jelas.
- Bekerja dengan file. Bahkan jika server hanya membaca data statis dari sistem file-nya, seperti gambar atau file gaya, dibutuhkan beberapa waktu untuk menyelesaikan operasi ini. Kali ini juga merupakan bagian dari TTFB.
- Prioritas Protokol HTTP / 2 memiliki mekanisme untuk memprioritaskan pemrosesan permintaan. Akibatnya, mungkin ternyata permintaan prioritas rendah dapat ditunda di server, memberikan jalan bagi permintaan prioritas tinggi. Bahkan jika Anda tidak memperhitungkan mekanisme prioritas HTTP / 2 dan menganggap bahwa semuanya berfungsi dengan lancar, penundaan yang diharapkan ini dapat berkontribusi pada TTFB.
- Menjalankan aplikasi. Ini, pada kenyataannya, cukup jelas, tetapi saya ingin mencatat bahwa waktu yang diperlukan untuk menjalankan aplikasi server secara serius mempengaruhi TTFB.
- Permintaan basis data. Jika Anda perlu meminta sesuatu dari database untuk membentuk halaman, maka waktu untuk menyelesaikan operasi semacam itu juga akan dimasukkan dalam TTFB.
- Panggilan API Jika data dari API tertentu (internal atau eksternal) diperlukan untuk menyiapkan halaman, maka panggilan ke API ini akan memengaruhi TTFB.
- Render server Sangat jelas bahwa rendering sisi server membutuhkan waktu, kali ini mudah untuk dievaluasi, tetapi ini tidak meniadakan kontribusi operasi ini ke TTFB.
- Hosting murah. Jika Anda menggunakan hosting murah, berusaha menghemat sebanyak mungkin dan mengorbankan kinerja, ini biasanya berarti bahwa sejumlah proyek lain menggunakan server di mana proyek Anda berada. Mungkin jumlah yang cukup banyak. Akibatnya, seseorang yang menggunakan hosting murah dapat mengharapkan penurunan kinerja server, yang dapat memengaruhi kemampuan proyek untuk memproses permintaan. Bahkan, kita berbicara tentang fakta bahwa kekuatan perangkat keras server tidak cukup untuk memenuhi kebutuhan aplikasi.
- Serangan DDoS, beban tinggi pada proyek. Di sini kita melanjutkan topik yang dibahas dalam paragraf sebelumnya dari daftar ini. Yaitu, jika beban pada server bertambah, dan proyek tidak menyediakan penskalaan kapasitas server yang fleksibel, ini mengarah pada fakta bahwa peralatan mulai bekerja hingga batasnya. Dan, sebagai hasilnya, kinerja aplikasi turun.
- WAF, muat penyeimbang. Layanan, seperti WAF atau load balancers yang terletak di depan aplikasi server, meningkatkan TTFB.
- Beberapa fitur CDN. Menggunakan CDN adalah faktor yang tentunya memiliki efek menguntungkan pada TTFB, tetapi beberapa fitur CDN dapat memperburuk ini. Misalnya, ini adalah permintaan lipat , ESI , dll.
- Keterlambatan di "last mile". Ketika kita berbicara tentang komputer dari London yang mengakses server yang berlokasi di New York, kita biasanya menyederhanakan situasi, hampir menguranginya menjadi fakta bahwa komputer dan server terhubung langsung satu sama lain. Namun dalam kenyataannya, semuanya jauh lebih rumit. Sinyal antara komputer dan server melewati banyak perantara. Router kami mengirimkannya ke penyedia; dari jaringan nirkabel, ia masuk ke kabel yang diletakkan di dasar lautan ... Penundaan pada "mil terakhir" mencakup semua kesulitan yang menghalangi transfer data antara perangkat akhir.
TTFB 0 ms adalah mimpi pipa. Oleh karena itu, penting untuk dicatat bahwa tidak ada dalam daftar yang selalu berdampak negatif terhadap TTFB atau selalu memperburuk indikator ini. Daftar ini paling baik dipahami sebagai deskripsi struktur proyek TTFB. Tujuan saya bukan untuk mengkritik teknologi tertentu, tetapi untuk menunjukkan bagaimana teknologi tertentu dapat memengaruhi TTFB. Dan, jujur saja, mengingat berapa banyak hal yang terjadi sebelum klien menerima byte pertama dari respon dari server, sudah mengejutkan bahwa situs-situs tersebut umumnya memuat.
Misteri Mengungkap dengan TTFB
Mudah-mudahan, TTFB tidak terlihat misterius lagi. Dan jika Anda menghabiskan sedikit waktu pada implementasi
Timing Server API, maka Anda dapat mulai mengukur indikator waktu server yang rumit dan mengirimkannya ke sistem klien. Ini akan memungkinkan pengembang web untuk mendeteksi dan menghilangkan potensi kemacetan kinerja yang sebelumnya tersembunyi dari mata mereka.
Server Timing API memungkinkan pengembang untuk memperluas respons kueri dengan header HTTP
Server-Timing opsional. Ini berisi informasi waktu yang diukur oleh aplikasi itu sendiri.
Mekanisme inilah yang kami gunakan tahun lalu ketika bekerja pada BBC iPlayer.
Header Server-Timing baru dapat ditambahkan ke jawaban apa pun ( gambar ukuran penuh )
Perhatikan bahwa Waktu Server juga memberikan tekanan pada sistem. Dalam perjalanan kerjanya, Anda perlu mengukur indikator yang relevan dan mengisi header
Server-Timing . Browser hanya memungkinkan pengembang front-end untuk melihat data ini menggunakan alat yang sesuai.
Sekarang, tepat di browser, Anda dapat melihat struktur TTFB ( gambar ukuran penuh )Jika Anda ingin menerapkan Server Timing API, lihat
materi ini .
Ringkasan
Sangat penting bahwa pengembang web memahami sejauh mana TTFB mempengaruhi apa yang mereka sebut "kinerja situs." Waktu ke byte pertama adalah batas tertentu, setelah menyeberang yang dapat kita bicarakan optimasi situs web. Semakin rendah indikator ini, semakin baik.
Pembaca yang budiman! Apakah Anda mengoptimalkan proyek web Anda dengan TTFB?
