Apa yang menyebabkan waktu tunggu sebelum HTML saya dimuat?


12

Saya memiliki situs web yang tampaknya memuat sangat lambat. Ketika saya menjalankan tes kecepatan di atasnya saya melihat tampaknya ada celah 6 detik sebelum HTML dimuat. Gambar dan skrip JS dimuat dengan sangat cepat setelah titik itu.

Anda dapat melihat pada gambar di bawah bilah 'tunggu waktu' berwarna kuning:

Memuat file HTML membutuhkan waktu lebih dari 5 detik, sementara sebagian besar aset lainnya dimuat dalam waktu kurang dari 1 detik

Ini tampaknya konsisten, apa pun konten HTML pada halaman tersebut.

Situs ini menggunakan CMS (ModX Revo) sehingga HTML sebenarnya disimpan dalam database SQL dan dibawa oleh PHP, tetapi saya belum pernah mengalami masalah ini sebelumnya.

Adakah yang tahu apa yang menyebabkan ini dan bagaimana saya bisa mempercepatnya?


Apakah ini hal baru? Yaitu, apakah halaman-halaman ini berkinerja normal sebelum dan sekarang berkinerja buruk? Atau ini instalasi / situs yang lebih baru? Bisakah Anda memberi tahu kami lebih banyak?
closetnoc

1
Kecuali jika ada beberapa jaringan perantara yang menahan ini, maka ini sepertinya waktu yang digunakan server Anda untuk menghasilkan respons? Anda mengatakan "tidak peduli apa konten HTML" - konten HTML melalui CMS Anda, atau secara harfiah halaman HTML statis? Saya pasti akan mencoba halaman HTML statis "Hello World" sederhana jika Anda belum melakukannya. Juga perhatikan bahwa server pingdom ada di sisi lain dunia ke Australia (yang saya asumsikan di mana Anda dihosting)?
MrWhite

1
IMO masalahnya terutama dengan satu halaman itu - server / CMS Anda tampaknya membutuhkan waktu lama untuk menghasilkan respons. Permintaan SQL tidak efisien ?? Halaman lain di situs Anda tampaknya relatif cepat. (?)
MrWhite

Jawaban:


13

Istilah teknis untuk menunggu direferensikan sebagai waktu untuk byte pertama dan menentukan daya tanggap server web atau sumber daya jaringan lainnya.

Beberapa alasan umum Anda mungkin melihat waktu yang tinggi untuk byte pertama:

  • Jaringan kelebihan beban (biasanya hosting bersama)
  • Server salah konfigurasi
  • Jarak dari Anda dan server (lokasi geografis memainkan peran kecil)
  • Kesalahan server (hop)

Umumnya masalah ini sering terlihat di shared hosting karena banyaknya situs web dan orang-orang yang mengunjungi mereka yang tentu saja meningkatkan waktu byte jaringan. Penyebab lain yang mungkin adalah kesalahan pada jaringan di suatu tempat, seperti lompatan atau karena server Anda tidak berada dalam lokasi audiens yang Anda targetkan, misalnya server Inggris 'GOOD' akan memiliki waktu byte yang lebih rendah daripada server AS yang menargetkan pengguna di Inggris, karena jarak yang perlu dikirim dan diterima data (Biasanya peningkatan sekitar 100-200ms).

Mungkin ada waktu untuk mendapatkan host baru

Di masa lalu saya harus pindah dari server ke server karena jeda waktu ke byte pertama, Anda mungkin harus memilih web host baru atau meningkatkan paket Anda saat ini.

Pengujian yang andal

Menguji kecepatan situs web Anda dari broadband rumah Anda sangat berat karena mungkin masalah dengan broadband Anda tidak merespons situs web. Anda harus menguji situs web Anda menggunakan beberapa koneksi dari beberapa server ... Saya merekomendasikan pengujian halaman web dan menjalankan beberapa pengujian sekaligus dari lokasi yang berbeda dan banyak di audiens geo yang ditargetkan. Ini akan memberi Anda gambaran yang lebih baik tentang apa yang terjadi, jika byte pertama maka saya sarankan Anda menghubungi host web Anda sebelum hal lain.

Ping dan lacak rute server

Jika Anda mencoba menjalankan ping pada server yang hasilnya mungkin ditampilkan atau tidak, ping menggunakan ICMP daripada UDP atau TCP yang artinya tidak seperti menanyakan server pada port 80 di mana httpd Anda akan berjalan. Anda bisa menggunakan jejak lacak untuk mengidentifikasi server mana pun pada rute yang bisa menyebabkan byte pertama bertambah, lagi ... itu tidak meminta server httpd pada port 80 dan jika traceroute menggunakan Windows itu akan menggunakan ICMP dan Mac / Linux mesin akan menggunakan UDP. Ini layak untuk diuji karena ini hal yang cepat dan mudah dilakukan tetapi jika hasilnya kembali baik-baik saja, tidak perlu berarti tidak ada masalah di suatu tempat.


Hai @SunWKim Saya telah memperbarui jawaban saya dengan apa yang Anda minta. Lihatlah bagian bawah jawaban saya.
Simon Hayter

Saya menyetujui alasan umum Anda waktu untuk byte pertama. Namun, dalam hal ini; Saya percaya ini lebih berkaitan dengan kode JavaScript.
Sun

Byte Pertama dapat disebabkan oleh berbagai hal tetapi JavaScript bukan salah satunya karena respons tajuk sebelum elemen inline seperti JavaScript, CSS, Gambar, dan sebagainya. Jangan bingung byte pertama dengan elemen dan file yang sebenarnya ..
Simon Hayter

Saya tidak membingungkan keduanya. Mungkin jika Anda mengunjungi mbff.com.au dan melihat sendiri, Anda mungkin yakin itu bukan masalah waktu untuk byte pertama. Penundaan terjadi setelah respons tajuk pertama.
Sun

1
The delay is occurring after the first header responsemaka itu bukan byte pertama. Byte pertama adalah respons pertama.
Simon Hayter

4

1) Anda memiliki Adobe TypeKit yang tidak memuat secara tidak sinkron dengan kode saat ini. Coba ganti dengan kode asinkron lanjut: http://help.typekit.com/customer/portal/articles/649336-embed-code

Kode embed standar ini mengambil keuntungan dari fakta bahwa tag memblokir render halaman lebih lanjut untuk membantu mencegah FOUT [Flash Teks Tanpa Gaya]. Saat skrip Typekit sedang memuat, rendering halaman diblokir, jadi teks tidak akan mulai di-render dengan font fallback.

2) Uji dengan TypeKit baru. Bagaimana waktu pemuatan sekarang? Lebih baik? Lanjutkan ke langkah 3.

3) Ganti Google Analytics Anda dengan JavaScript yang diperbarui yang menyediakan sintaks asinkron terbaru: https://developers.google.com/analytics/devguides/collection/gajs/

4) Uji. Apakah halaman memuat masih lebih baik?

5) Akhirnya, pertimbangkan untuk mengoptimalkan gambar seperti pattern.jpg. Saya mengonversinya menjadi PNG dan dapat mengurangi ukuran file dari 199kB menjadi 56kB. Ini mengurangi waktu untuk menerima file: https://www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

Saya harap ini membantu.


3

Elemen PHP vs. Non-PHP

Jika Anda membandingkan waktu pemuatan aset non-PHP dengan waktu pemuatan berbasis PHP, Anda akan melihat bahwa server merespons dengan cepat jika PHP tidak terlibat.

Ini biasanya menunjukkan masalah internal skrip PHP Anda.

Masalahnya bisa di dalam lapisan PHP atau database. Menggunakan alat debugging canggih seperti XDebug atau NewRelic dapat membantu Anda dengan cepat melihat kemacetan.

Waktu untuk masalah byte pertama dapat disebabkan oleh kendala perangkat keras, konfigurasi yang buruk atau kode yang tidak efisien. Di hosting bersama, kendala perangkat keras dan konfigurasi yang buruk kemungkinan besar.

Dalam kasus apa pun, menyelesaikan masalah biasanya berarti satu atau semua:

  • Lebih banyak perangkat keras
  • Pemrograman yang lebih baik
  • Tambahkan Caching

Perangkat keras yang lebih cepat adalah solusi yang jelas tetapi seringkali mahal jika Anda sudah menggunakan sumber daya khusus.

Pemrograman yang lebih baik mungkin tidak dapat dilakukan jika masalahnya internal ke kode yang tidak Anda pertahankan atau kekurangan sumber daya pengembang.

Caching membantu dengan mengurangi jumlah permintaan yang harus mengenai sumber daya yang mendasarinya dan berkinerja buruk.

Pengujian

Saat menggunakan alat pengujian, pastikan untuk melakukan beberapa kali proses. Jaringan dan lonjakan server sementara dapat dengan mudah membawa Anda ke jalan yang salah, jadi Anda ingin mencoba meratakannya.

Hosting

Jika Anda menggunakan akun hosting bersama, maka pertimbangkan untuk pindah ke layanan tipe cloud atau VPS sehingga Anda memiliki wawasan yang lebih baik tentang masalah kinerja. Kecuali Anda menggunakan teknik caching (CDN atau layanan tipe Cloudflare), memperbaiki masalah kinerja pada sistem hosting yang dibagikan secara massal bisa sangat menantang karena Anda tidak memiliki kontrol yang cukup terhadap server.


-1

Coba atur cookie pihak ketiga hanya untuk dikunjungi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.