Mengapa situs web tidak segera menampilkan teks mereka hari ini?

Saya perhatikan bahwa baru-baru ini banyak situs web yang lambat menampilkan teksnya. Biasanya, latar belakang, gambar dan sebagainya akan dimuat, tetapi tidak ada teks. Setelah beberapa waktu, teks mulai muncul di sana-sini (tidak selalu semuanya pada waktu yang sama).

Ini pada dasarnya bekerja sebaliknya seperti dulu, ketika teks ditampilkan pertama kali, maka gambar dan sisanya dimuat setelahnya. Teknologi baru apa yang menciptakan masalah ini? Ada ide?

Perhatikan bahwa saya berada di koneksi yang lambat, yang mungkin menonjolkan masalah.

Lihat di bawah untuk contoh - semuanya dimuat tetapi butuh beberapa detik lagi sebelum teks akhirnya ditampilkan:

Salah satu alasannya adalah bahwa perancang web saat ini suka menggunakan font web (biasanya dalam format WOFF ), misalnya melalui font Web Google .

Sebelumnya, satu-satunya font yang dapat ditampilkan di situs adalah font yang telah diinstal pengguna secara lokal. Karena misalnya pengguna Mac dan Windows tidak harus memiliki font yang sama, desainer secara naluriah selalu mendefinisikan aturan sebagai

font-family: Arial, Helvetica, sans-serif;

di mana, jika font pertama tidak ditemukan pada sistem, browser akan mencari yang kedua, dan terakhir font "sans-serif" yang mundur.

Sekarang, seseorang dapat memberikan URL font sebagai aturan CSS untuk membuat browser mengunduh font, seperti:

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

dan kemudian memuat font untuk elemen tertentu dengan misalnya:

font-family: 'Droid Serif',sans-serif;

Ini sangat populer untuk dapat menggunakan font khusus, tetapi juga mengarah pada masalah bahwa tidak ada teks yang ditampilkan sampai sumber daya dimuat oleh browser, yang meliputi waktu pengunduhan, waktu pemuatan font dan waktu render. Saya berharap ini adalah artefak yang Anda alami.

Sebagai contoh: salah satu surat kabar nasional saya, Dagens Nyheter , menggunakan font web untuk berita utama mereka, tetapi bukan lead mereka, jadi ketika situs itu dimuat saya biasanya melihat lead terlebih dahulu, dan setengah detik kemudian semua ruang kosong di atas diisi dengan tajuk berita (setidaknya ini berlaku di Chrome dan Opera. Belum mencoba yang lain).

(Juga, para desainer memercikkan JavaScript dengan benar-benar ke mana-mana akhir-akhir ini, jadi mungkin seseorang mencoba melakukan sesuatu yang pintar dengan teks, itulah sebabnya mengapa ia ditunda. Itu akan sangat spesifik untuk situs, meskipun: kecenderungan umum untuk teks akan tertunda dalam hal ini kali adalah masalah font web yang dijelaskan di atas, saya percaya.)

Tambahan

Jawaban ini menjadi sangat terangkat, meskipun saya tidak terlalu mendetail, atau mungkin karena ini. Ada banyak komentar di utas pertanyaan, jadi saya akan mencoba sedikit memperluas (banyak komentar tampaknya telah menghilang sebentar setelah topik dilindungi - beberapa moderator mungkin secara manual membersihkannya). Baca juga jawaban lain di utas ini karena semuanya berkembang dengan caranya sendiri.

Fenomena ini rupanya dikenal sebagai "kilasan konten tanpa gaya" secara umum, dan "flash teks tanpa gaya" pada khususnya. Mencari "FOUC" dan "FOUT" memberikan lebih banyak info.

Saya dapat merekomendasikan posting desainer web Paul Irish di FOUT sehubungan dengan font web .

Apa yang dapat dicatat adalah bahwa browser yang berbeda menangani hal ini secara berbeda. Saya menulis di atas bahwa saya telah menguji Opera dan Chrome, yang keduanya berperilaku sama. Semua yang berbasis WebKit (Chrome, Safari, dll.) Memilih untuk menghindari FOUT dengan tidak merender teks font web dengan font fallback selama periode pemuatan font web. Bahkan jika font web di-cache, akan ada penundaan render . Ada banyak komentar di utas pertanyaan ini yang mengatakan sebaliknya dan itu salah kalau font yang di-cache berperilaku seperti ini, tetapi mis. Dari tautan di atas:

Dalam kasus apa Anda akan mendapatkan FOUT

• Will: Mengunduh dan menampilkan remote ttf / otf / woff
• Will: Menampilkan ttf / otf / woff yang di-cache
• Will: Mengunduh dan menampilkan data-uri ttf / otf / woff
• Will: Menampilkan data cache-uri ttf / otf / woff
• Tidak akan: Menampilkan font yang sudah diinstal dan dinamai dalam tumpukan font tradisional Anda
• Tidak akan: Menampilkan font yang diinstal dan dinamai menggunakan lokasi lokal ()

Karena Chrome menunggu hingga risiko FOUT hilang sebelum rendering, ini memberikan penundaan. Untuk yang sejauh efek terlihat (terutama ketika loading dari cache) tampaknya tergantung pada antara lain jumlah teks yang perlu diberikan dan faktor mungkin lainnya, tetapi caching tidak benar-benar menghapus efek.

Irish juga memiliki beberapa pembaruan tentang perilaku peramban pada 2011–04–14 di bagian bawah pos:

• Firefox (pada FFb11 dan FF4 Final) tidak lagi memiliki KEJUTAN! Wooohoo! http://bugzil.la/499292 Pada dasarnya teks tidak terlihat selama 3 detik, dan kemudian mengembalikan font fallback. Webfont mungkin akan dimuat dalam tiga detik itu ... semoga ..
• IE9 mendukung WOFF dan TTF dan OTF (meskipun membutuhkan set bit embedding - kebanyakan dapat diperdebatkan jika Anda menggunakan WOFF). NAMUN!!! IE9 memiliki FOUT. :(
• Webkit memiliki tambalan yang menunggu untuk mendarat untuk menampilkan teks mundur setelah 0,5 detik. Jadi perilaku yang sama seperti FF tetapi 0,5 bukannya 3s.
• Tambahan : Blink memiliki bug yang terdaftar untuk ini juga , tetapi tampaknya belum tercapai konsensus tentang apa yang harus dilakukan dengan itu - implementasi saat ini sama dengan WebKit.

Jika ini adalah pertanyaan yang ditujukan untuk para desainer, orang dapat mencari cara untuk menghindari masalah seperti ini webfontloader, tetapi itu akan menjadi pertanyaan lain. Tautan Paul Irish menjelaskan lebih lanjut tentang masalah ini.

Alasan untuk ini adalah teks yang belum dapat Anda baca sedang diterjemahkan dengan font web yang masih dalam perjalanan menuju pipa ke browser Anda.

Juga, karena browser Anda adalah Google Chrome, yang menggunakan WebKit untuk membuat halaman, diputuskan oleh mereka (WebKit) bahwa yang terbaik adalah Anda tidak melihat teks sama sekali sampai font web diunduh. Namun, jika Anda seorang pengembang yang lebih suka teks yang dapat dibaca dalam font sistem mundur yang sesuai, maka Anda dapat menggunakan sesuatu seperti Google WebFont Loader untuk mencapai ini.

Jawaban singkat: AJAX atau WOFF

Ada beberapa penyebab situs web menjadi "lambat untuk menampilkan teksnya" . Kelambatan pada portableapps.com disebabkan oleh mengunduh font WOFF . Namun, apa yang Anda gambarkan sebagai "teks mulai muncul di sana-sini" lebih sering disebabkan oleh AJAX .

Situs web terdiri dari banyak bagian. Bagaimana bagian-bagian ini diunduh dan dirakit adalah pilihan desain di bawah kendali desainer web . Kelambatan ini disebabkan oleh bagaimana pengembang memilih untuk merakit blok bangunan berikut:

• Halaman HTML awal
• CSS
• JS
• Gambar-gambar
• Font WOFF
• Permintaan AJAX
• Manipulasi DOM

Situs web tradisional:

Secara tradisional, itu adalah hal biasa bagi para pengembang untuk meletakkan konten teks di halaman HTML awal dan menampilkannya segera setelah tersedia . HTML akan merujuk beberapa sumber yang akan diunduh. Browser kemudian akan secara bertahap menggambar ulang layar untuk memasukkan gaya dan gambar ketika sudah tersedia. AJAX dan WOFF tidak tersedia.

Situs Web WOFF:

Font WOFF memungkinkan situs web untuk menggunakan font yang biasanya tidak tersedia untuk browser, dengan mengunduh font dengan situs web . Beberapa pengembang menginstruksikan browser untuk tidak menampilkan konten teks sampai semua font WOFF telah diunduh. Dalam pengalaman saya, pendekatan ini belum mendapatkan penggunaan yang sangat luas.

Situs Web AJAX:

Beberapa pengembang memilih untuk tidak memasukkan konten teks di halaman HTML awal. Sebagai gantinya, mereka memilih untuk mengunduh konten teks menggunakan AJAX. Ini terjadi setelah halaman dasar dimuat . Dalam pengalaman saya, metode ini telah mendapatkan adopsi yang jauh lebih luas daripada font WOFF dan paling sering menjadi penyebab kelambatan yang Anda gambarkan.

Menentukan Penyebabnya

Untuk menentukan penyebab situs tertentu memerlukan analisis menggunakan alat seperti Firebug atau Alat Pengembang Chrome . Atau sebagai alternatif, Anda dapat membuka situs menggunakan Internet Explorer 8 , yang mendukung AJAX tetapi tidak WOFF. Jika situs ini masih lambat, masalahnya adalah AJAX dan bukan WOFF.

Saya sering mungkin merupakan pilihan yang disengaja untuk menghindari "kilasan konten tanpa gaya". Jika teks ditampilkan sebelum CSS dimuat, Anda akan melihatnya sebentar saat muncul mentah, dan kemudian flash ketika browser menggambarnya. Dengan memasukkan beberapa gaya inline dasar untuk awalnya menyembunyikan konten, yang ditimpa dalam stylesheet yang sebenarnya, atau menggunakan JS, pengembang menghindari flash ini.

Seperti yang telah dicatat orang lain, font khusus kemungkinan berkontribusi pada keterlambatan.

Untuk memberikan sedikit lebih banyak latar belakang, browser melakukan kira-kira hal-hal berikut sebelum dapat membuat konten halaman ke layar:

1. fetch HTML (beberapa perjalanan pulang-pergi untuk DNS, TCP, request / response)
2. mulai parsing HTML, temukan sumber daya eksternal seperti CSS eksternal dan JS. Perhatikan bahwa CSS memblokir tata letak, dan JS memblokir parsing. Jadi sumber daya eksternal seperti CSS dan JS dimuat di awal dokumen (misalnya di kepala) memperlambat waktu yang dibutuhkan untuk halaman untuk menampilkan konten di layar.
3. mengambil CSS eksternal dan JS (beberapa perjalanan pulang-pergi: DNS dan TCP jika sumber daya ini berada pada domain yang berbeda seperti CDN, serta RTT untuk permintaan / respons)
4. setelah CSS eksternal dan JS selesai memuat, parsing / jalankan JS, parsing / terapkan gaya
5. jika CSS membuat referensi ke font khusus, font-font itu sekarang harus diunduh juga, mengakibatkan keterlambatan bolak-balik tambahan untuk merender bagian mana pun dari halaman yang bergantung pada font khusus tersebut.

Meskipun ini bukan tentang penundaan yang disebabkan oleh font khusus, saya menulis posting blog baru-baru ini yang memberikan informasi tambahan tentang penyebab keterlambatan render. Ini memberikan beberapa saran untuk meminimalkan waktu mengecat halaman Anda. Semoga ini bermanfaat bagi pembaca yang tertarik untuk membuat halaman mereka menampilkan konten lebih cepat, termasuk halaman-halaman yang ingin menggunakan font khusus: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -satu detik/

Jawaban singkat: Pengembang.

Ketika tag tautan dan skrip yang merujuk pada dokumen eksternal (seperti file .css atau .js) ditempatkan di bagian atas dokumen (lebih tinggi dalam aliran daripada tubuh, dan elemen-elemennya), mereka dimuat terlebih dahulu. JavaScript dieksekusi dari markup yang merujuknya; jika ada banyak kode untuk diproses, atau itu adalah kode yang rumit, atau lebih umum jika teks yang Anda harapkan ditampilkan di server dan diisi ke dalam dokumen yang dimuat - dan kode sisi server juga rumit, besar, atau memblokir I / O karena pemrosesan beberapa permintaan secara bersamaan, Anda mungkin akan melihat downtime sebelum HTML berkesempatan untuk merendernya. Beberapa pengembang memilih untuk memuat JavaScript yang tidak terkait tampilan setelah markup dan gaya (di akhir badan),

Kecepatan koneksi Internet memainkan peran dalam pengunduhan data yang lambat, cukup jelas, tetapi kode yang ditulis dengan buruk, atau tumpukan teknologi yang dirancang buruk (untuk jenis situs web) memainkan peran yang semakin sentral dalam pemuatan konten dinamis yang lambat, karena koneksi jaringan yang lebih cepat pendekatan di mana-mana.

Singkatnya, terlalu banyak objek yang dapat dimuat yang perlu dimuat dari GET HTTP terpisah sebelum halaman dapat ditampilkan, dan ketergantungan berlebih pada latensi rata-rata sebagai ukuran kesehatan situs.

Yang pertama merujuk pada semua .css, .js, dan webfonts yang dimuat halaman, belum lagi fakta bahwa banyak situs juga perlu mengambil objek JSON melalui permintaan XHR dan kemudian menghasilkan HTML dari mereka yang menggunakan semacam templating.

Tetapi mengapa mereka tidak memperhatikan bahwa situsnya lambat?

Mungkin karena mereka memiliki memecache di sana di suatu tempat untuk mempercepat (atau hanya mengandalkan cache filesystem) dan mengukur kesehatan situs mereka menggunakan latensi rata-rata. Dengan demikian objek yang di-cache dikembalikan dengan latensi 6 mircrosecond dan menutupi kenyataan bahwa banyak permintaan GET membutuhkan 5.000 milidetik untuk diselesaikan. Rata-rata harus mati. Hidup penghitungan RTT lebih lama dari batas maksimum yang dapat diterima! Angka itu harus 0 atau, menurut definisi, RTT tidak dapat diterima.

Ya ada beberapa alasan. Salah satu alasannya adalah bahwa perintah untuk mendefinisikan latar belakang atau di atas halaman html sering atau diambil dalam CSS terpisah yang dimuat terlebih dahulu. sebelum isi dokumen dimuat yang berisi teks.

Penyebab lain adalah bahwa meskipun dimungkinkan untuk mengetik ukuran gambar dalam banyak kasus, perancang web tidak menggunakannya. Dan Brouwser harus memuat seluruh gambar terlebih dahulu pada halaman sehingga ia tahu cara membungkus teks di sekitarnya.

Beberapa desainer, juga ingin menunjukkan gambar pertama dan teks berikutnya, mereka mencapainya dengan beberapa javascript jadi misalnya halaman sederhana pertama-tama akan menampilkan banner dan kemudian semua yang lain di atasnya.

Tetapi jika Anda bertanya-tanya mengapa ada begitu banyak barang komersial spam di halaman saya sementara saya hanya ingin membaca berita, maka ada solusi untuk Anda. Anda dapat menggunakan pemblokir spam jika menggunakan firefox. Dengan addon seperti itu, browser web mengetahui situs-situs yang menyediakan spam, dan hanya memblokirnya, menghasilkan pemuatan halaman yang jauh lebih cepat, sementara Anda masih dapat melihat gambar-gambar penting yang berhubungan dengan artikel yang Anda baca.

Saya akan merekomendasikan kepada Anda semua yang berurusan dengan loading halaman lambat untuk mencoba fidler. fidler dapat digunakan dengan IEexplorer atau dengan FireFox (menggunakan fungsi proxy-nya) Fidler sebenarnya akan menunjukkan kepada Anda berapa lama waktu yang dibutuhkan dan ketika bagian-bagian halaman web dimuat. Ini adalah alat debugging HTML.