Web siteleri neden bugünlerde metinlerini hemen görüntülemiyor?

Son zamanlarda pek çok web sitesinin metinlerini görüntülemek için yavaş olduğunu fark ettim. Genellikle, arka plan, resimler vb. Yüklenecek, ancak metin yok. Bir süre sonra metin burada ve orada görünmeye başlar (her zaman aynı anda değil).

Temel olarak, metin önce gösterildiğinde, daha sonra görüntüler ve kalanlar yüklenirken eskisi gibi çalışır. Hangi yeni teknoloji bu sorunu yaratıyor? Herhangi bir fikir?

Yavaş bir bağlantıda olduğumu ve muhtemelen sorunu vurguladığımı unutmayın.

Bir örnek için aşağıya bakın - her şey yüklü, ancak metin sonunda görüntülenmeden önce birkaç saniye daha uzun sürebilir:

Bunun bir nedeni, web tasarımcılarının günümüzde web yazı tiplerini (genellikle WOFF biçiminde), örneğin Google Web yazı tiplerini kullanarak kullanmalarıdır .

Önceden, bir sitede görüntülenebilen yazı tipleri, kullanıcının yerel olarak yüklediği metinlerdi. Örneğin Mac ve Windows kullanıcıları mutlaka aynı fontlara sahip olmadıklarından, tasarımcılar içgüdüsel olarak her zaman kuralları tanımladılar.

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

ilk yazı tipi sistemde bulunmazsa, tarayıcı ikinciyi ve son olarak bir "geri dönüşler" sans-serif "yazı tipini arardı.

Şimdi, biri bir font URL'sini tarayıcının bir fontu indirmesini sağlamak için CSS kuralı olarak verebilir:

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

ve sonra belirli bir öğenin fontunu örneğin:

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

Bu, özel fontları kullanabilmek için çok popülerdir, ancak kaynak indirme işlemi, font yükleme süresi ve oluşturma süresini içeren tarayıcı tarafından yüklenene kadar hiçbir metnin gösterilmemesine neden olur. Bunun yaşadığın eser olduğunu umuyorum.

Örnek olarak: ulusal gazetelerimden biri Dagens Nyheter , başlıkları için web fontları kullanıyor, ancak potansiyel müşterileri için değil, bu yüzden bu site yüklendiğinde genellikle potansiyel müşterileri görüyorum ve yarım saniye sonra yukarıdaki boşluklar dolduruluyor. başlıkları olan (bu, Chrome ve Opera’da geçerlidir, en azından. Başkalarını denemedim).

(Ayrıca, tasarımcılar bugünlerde her yere JavaScript'i serpiştiriyorlar, bu yüzden belki birileri metinle zekice bir şeyler yapmaya çalışıyor, bu yüzden gecikiyor. Yukarıda belirtilen web fontları sayısının sorun olduğunu düşünüyorum.)

İlave

Ben ya da belki, fazla detaya gitmedi gerçi Bu cevap, çok upvoted oldu çünkü bu. Soru başlığında birçok yorum yapıldı, bu yüzden biraz genişletmeye çalışacağım (konu korunduktan kısa bir süre sonra birçok yorum kaybolmuş gibi görünüyor - bazı moderatörler onları manuel olarak temizledi). Ayrıca, bu konudaki diğer cevapları, hepsi kendi yöntemleriyle genişledikçe okuyun.

Görünüşe göre fenomen genel olarak "stilize edilmemiş içeriğin flaşı" ve özellikle "stilize edilmemiş metnin flaşı" olarak bilinir. "FOUC" ve "FOUT" kelimelerinin aranması daha fazla bilgi verir.

Ben tavsiye edebilir web yazı tipleri ile bağlantılı olarak Fout web tasarımcısı Paul İrlandaca adlı kullanıcının yayınını .

Not edebileceği şey, farklı tarayıcıların bunu farklı şekilde ele alması. Yukarıda, her ikisinde de aynı şekilde davranan Opera ve Chrome'u test ettiğimi yazdım. Tüm WebKit tabanlı olanlar (Chrome, Safari, vb) tarafından Fout önlemek için tercih değil , web yazı yükleme süresi boyunca bir geri dönüş yazı ile web yazı metninin oluşturulmasında. Bile web yazı önbelleğe alınır, orada olacak bir hale gecikme . Bu soru başlığında başka türlü söylenen çok fazla yorum var ve önbelleğe alınmış yazı tiplerinin bu şekilde davranmasının yanlış olduğu açık, ancak örneğin yukarıdaki bağlantıdan:

Hangi durumlarda bir FOUT alacaksınız

• Will: Uzak bir ttf / otf / woff uzaktan indirme ve görüntüleme
• Will: Önbelleğe alınmış bir ttf / otf / woff gösterilmesi
• Will: Bir veri uri ttf / otf / woff veri indirme ve görüntüleme
• Will: Önbelleğe alınmış veri gösteriliyor-uri ttf / otf / woff
• Olmayacak: Zaten yüklü ve geleneksel yazı tipi yığınınıza adlandırılmış bir yazı tipi görüntülemek
• Olmayacak: local () konumu kullanılarak yüklenmiş ve adlandırılmış bir font görüntülemek

Chrome, FOUT riski oluşturma işleminden önce kaybolana kadar beklediğinden, bu bir gecikme sağlar. Hangi için ne ölçüde etki görülebilir (özellikle önbellekten yüklerken) gerektiren metinler miktarı işlenecek diğer şeyler ve belki diğer faktörlerin yanı sıra bağımlı gibi görünüyor, ama önbelleğe alma tamamen etkisi kaldırmaz.

İrlanda’da, yazının altında 2011–04–14 arası tarayıcı davranışlarıyla ilgili bazı güncellemeler de var:

• Firefox (FFb11 ve FF4 Finalinden itibaren) artık bir FOUT! Wooohoo! http://bugzil.la/499292 Temel olarak metin 3 saniye görünmez ve sonra geri dönüş fontunu geri getirir. Webfont muhtemelen bu üç saniye içerisinde yüklenecek… umarım ..
• IE9, WOFF ve TTF ve OTF'yi destekler ( gömülü bir bit set işi gerektirse de , çoğunlukla WOFF kullanıyorsanız, moot). ANCAK!!! IE9’da bir DÜNYA vardır. :(
• Webkit'in 0,5 saniye sonra geri dönüş metni göstermesi için inmeyi bekleyen bir yama var . Yani FF ile aynı davranış ancak 3s yerine 0.5s.
• Ekleme : Blink'in de bunun için kayıtlı bir hatası var , ancak şu anda WebKit ile aynı uygulamada yapılması gerekenler konusunda nihai bir fikir birliğine varılmadığı görülüyor.

Bu, tasarımcılara yönelik bir soru olsaydı, bu tür sorunlardan kaçınmanın yollarını bulabilirdik webfontloader, ama bu başka bir soru olurdu. Paul Irish bağlantısı bu konuda daha fazla ayrıntıya giriyor.

Bunun nedeni, henüz okuyamadığınız metnin , tarayıcınıza yönlendirilmeye devam eden bir web fontu ile sunulmasıdır.

WebKit'i kullanan tarayıcınızın olan Google Chrome, sayfayı oluşturmak için çünkü Ayrıca, onlar tarafından karar verildi web yazı indirilene kadar size hiç bir metni görmek için değil en iyi olduğunu (bir WebKit). Ancak, metnin uygun bir geri dönüş sistemi fontunda okunabilir olmasını tercih eden bir geliştiriciyseniz, bunun için Google WebFont Yükleyicisi gibi bir şey kullanabilirsiniz .

Kısa cevap: AJAX veya WOFF

Web sitelerinin "metinlerini görüntülemek için yavaş" olmasının birkaç nedeni vardır . Üzerinde yavaşlık portableapps.com indirerek kaynaklanır woff fontları. Ancak, "metin burada ve orada görünmeye başlar" olarak tanımladığınız şey daha çok AJAX'tan kaynaklanmaktadır .

Bir web sitesi birçok bölümden oluşur. Bu parçaların nasıl indirilip birleştirildiği, web tasarımcısının kontrolü altında bir tasarım tercihidir . Yavaşlık, geliştiricinin aşağıdaki yapı taşlarını birleştirmeyi nasıl seçtiğinden kaynaklanır:

• İlk HTML sayfası
• CSS
• JS
• Görüntüler
• WOFF yazı tipleri
• AJAX istekleri
• DOM manipülasyonu

Geleneksel olarak web siteleri:

Geleneksel olarak, geliştiricilerin metin içeriğini ilk HTML sayfasına koymaları ve mümkün olan en kısa sürede göstermeleri yaygındı . HTML, daha sonra indirilecek olan birkaç kaynağa referans verecektir. Tarayıcı daha sonra , stilleri ve görüntüleri mevcut olduklarında eklemek için aşamalı olarak ekranı yeniden çizer . AJAX ve WOFF mevcut değildi.

WOFF Web Siteleri:

WOFF fontları, bir web sitesinin , web sitesi ile fontları indirerek , normalde tarayıcıda bulunmayan fontları kullanmasına izin verir . Bazı geliştiriciler, tarayıcıya tüm WOFF yazı tipleri indirilene kadar metin içeriğini göstermemesini söyler. Tecrübelerime göre, bu yaklaşım henüz çok geniş bir kullanım alanı kazanmamıştır.

AJAX Web Siteleri:

Bazı geliştiriciler, metin içeriğini ilk HTML sayfasına eklememeyi seçer. Bunun yerine, metin içeriğini AJAX kullanarak indirmeyi seçtiler. Bu , temel sayfa yüklendikten sonra gerçekleşir . Tecrübelerime göre, bu yöntem WOFF yazı tiplerinden çok daha geniş bir kullanım alanı kazanmıştır ve çoğunlukla tarif ettiğiniz yavaşlığın nedenidir.

Nedeni Belirleme

Belirli bir sitenin nedenini belirlemek için Firebug veya Chrome Geliştirici Araçları gibi araçlar kullanarak analiz yapılması gerekir . Veya alternatif olarak, siteyi AJAX'ı destekleyen ancak WOFF'yi olmayan Internet Explorer 8'i kullanarak açabilirsiniz . Site hala yavaşsa, sorun AJAX'dır ve WOFF değildir.

Sık sık "stilize edilmemiş içeriğin yanıp sönmesinden" kaçınmak için bilinçli bir seçim olabilirim. CSS yüklenmeden önce görüntülenen metin, göründüğü kadar kısa bir süre görürsünüz ve ardından tarayıcı yeniden çizilirken yanıp söner. Geliştiriciler, asıl stil sayfasında geçersiz kılınan içeriği ilk olarak gizlemek için bazı temel satır içi stilleri koyarak veya JS kullanarak, geliştiriciler bu flaştan kaçınır.

Diğerlerinin de belirttiği gibi, özel fontlar muhtemelen gecikmeye katkıda bulunuyor.

Biraz daha arka plan vermek için, tarayıcı sayfa içeriğini ekrana getirmeden önce kabaca aşağıdakini yapıyor:

1. HTML getir (DNS, TCP, istek / yanıt için birkaç tur)
2. HTML'yi ayrıştırmaya başlayın, harici CSS ve JS gibi harici kaynakları keşfedin. CSS’nin yerleşimi ve JS’nin ayrıştırmayı engellediğini Bu nedenle, belgeye erken yüklenen CSS ve JS gibi harici kaynaklar (örneğin kafada) bir sayfanın içeriği ekranda göstermesi için geçen süreyi yavaşlatır.
3. Harici CSS ve JS'yi getirme (birkaç tur gezisi: Bu kaynaklar CDN gibi farklı bir etki alanındaysa DNS ve TCP ile istek / yanıt için bir RTT)
4. Harici CSS ve JS yükleme işlemini tamamladıktan sonra, JS'yi ayrıştırma / yürütme, stilleri ayrıştırma / uygulama
5. CSS özel yazı tiplerine gönderme yaparsa, bu yazı tiplerinin de indirilmeleri gerekir; bu nedenle, özel yazı tiplerine bağlı olarak sayfanın herhangi bir bölümünü işlemek için ek gidiş dönüş gecikmeleriyle sonuçlanır

Özel yazı tiplerinin neden olduğu gecikmelerle ilgili olmasa da, son zamanlarda oluşturma gecikmelerinin nedenleri hakkında ek bilgi veren bir blog yazısı yazdım. Sayfalarınız için ilk boya süresini azaltmak için bazı önerilerde bulunur. Umarım bu, özel fontlar kullanmak isteyen sayfalar da dahil olmak üzere sayfalarının içeriğini daha hızlı göstermesini isteyen okuyucular için yararlıdır: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -bir saniye/

Kısa cevap: Geliştiriciler.

Harici belgelere (.css veya .js dosyaları gibi) gönderme yapan link ve script etiketleri, belgenin başlığına yerleştirildiğinde (akış, gövdeden ve öğelerinin akışından daha yüksek), önce yüklenir. JavaScript kendisine başvuran biçimlendirmeden çalışır; işlenmesi gereken çok sayıda kod varsa veya bu çok zor bir kodsa veya daha genel olarak görmeyi beklediğiniz metin bir sunucuda gösteriliyorsa ve yük altında belgeye dolduruluyorsa - ve bu sunucu taraflı kod da Çok sayıda eşzamanlı isteğin işlenmesi nedeniyle büyük veya engelleyen G / Ç'lerde, HTML'nin bile işleme koyma şansı olmadan önce kesinti olduğunu fark edebilirsiniz. Bazı geliştiriciler, işaretlemenin ve stillerin ardından görünüme bağlı olmayan JavaScript’i yüklemeyi seçer (gövdenin sonunda),

İnternet bağlantısı hızı, verilerin yavaş indirilmesinde, açıkça, ancak kötü yazılmış kodun veya kötü tasarlanmış teknoloji yığınlarının (web sitesi türü için), daha hızlı ağ bağlantıları olarak dinamik içeriğin yavaş yüklenmesinde giderek daha merkezi bir rol oynamaktadır. her yerde yaklaşım.

Özet olarak, sayfa görüntülenmeden önce ayrı HTTP GET'lerden yüklenmesi gereken çok fazla yüklenebilir nesne ve site sağlığının bir ölçüsü olarak ortalama gecikmeye aşırı güveniyor.

Birincisi, sayfanın yüklediği tüm bu .css.

Peki neden sitenin yavaş olduğunu fark etmiyorlar?

Muhtemelen işleri hızlandırmak (ya da sadece dosya sistemi önbelleklerine güvenmek) için orada bir yerde memecache bulunduğundan ve sitelerin sağlığını ortalama gecikmeyle ölçüyorlar. Bu nedenle, önbelleğe alınmış nesneler 6 mircrosecond gecikmeyle döndürülür ve birçok GET isteğinin 5000 milisaniyeyi tamamlaması gerektiği gerçeğini gizler. Ortalamalar ölmeli. Yaşasın RTT'leri kabul edilebilir bir azami eşiğin üzerinde saymak! Bu sayı 0 olmalı veya tanım gereği RTT kabul edilemez.

Peki, birçok sebep var. Bunun bir nedeni de sık sık bir arka plan tanımlamak veya bir html sayfasının tepesinde sık sık komut vermek ya da ilk önce yüklenen ayrı bir CSS'de alınan komuttur. metni içeren belgenin gövdesi yüklenmeden önce.

Diğer bir sebep de, çoğu durumda web tasarımcılarının bunu kullanmaması bir görüntünün boyutunu yazmak mümkün olmasına rağmen. Ve böylece brouwser tüm görüntüleri ilk önce sayfalara yüklemek zorunda kalıyor, böylece etrafındaki metni nasıl sarılacağını biliyor.

Bazı tasarımcılar ilk resimleri ve sonraki metni de göstermek isterler, örneğin bazı javascriptlerle basit bir sayfa önce bir pankart gösterecek, sonra da başka bir şey gösterecek.

Ancak neden sadece haberleri okumak istediğimde sayfalarımda neden bu kadar çok spam reklamı olduğunu merak ediyorsanız, o zaman sizin için bir çözüm var. Firefox kullanıyorsanız spam engelleyicileri kullanabilirsiniz. Böylesi bir addon ile web tarayıcısı spam sağlayan siteleri bilir ve basitçe engeller, böylece daha hızlı bir sayfa yüklenmesine neden olur, oysa okuduğunuz makalelerle ilgili önemli resimleri görmeye devam edebilirsiniz.

Fidler'ı denemek için yavaş sayfa yükleme ile ilgilenen herkese tavsiye ederim. fidler IEexplorer veya FireFox ile kullanılabilir (proxy işlevini kullanarak) Fidler size gerçekte ne kadar sürdüğünü ve bir web sayfasının bölümlerinin yüklendiğini gösterir. Bu bir HTML hata ayıklama aracıdır.