Dlaczego strony internetowe nie wyświetlają teraz swojego tekstu?

Zauważyłem, że ostatnio wiele stron internetowych wolno wyświetla swój tekst. Zwykle tło, obrazy i tak dalej są ładowane, ale bez tekstu. Po pewnym czasie tekst zaczyna się pojawiać tu i tam (nie zawsze wszystkie w tym samym czasie).

Zasadniczo działa odwrotnie, jak kiedyś, gdy tekst był wyświetlany jako pierwszy, a następnie ładowano obrazy i resztę. Jakie nowe technologie tworzą ten problem? Dowolny pomysł?

Pamiętaj, że mam wolne połączenie, co prawdopodobnie podkreśla problem.

Zobacz przykład - wszystko jest wczytane, ale tekst pojawia się jeszcze kilka sekund:

Jednym z powodów jest to, że projektanci stron internetowych lubią obecnie używać czcionek internetowych (zwykle w formacie WOFF ), np. Za pomocą czcionek internetowych Google .

Wcześniej jedynymi czcionkami, które mogły być wyświetlane w witrynie, były te, które użytkownik zainstalował lokalnie. Ponieważ np. Użytkownicy komputerów Mac i Windows niekoniecznie mieli te same czcionki, projektanci instynktownie zawsze definiowali reguły jako

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

gdzie, jeśli pierwsza czcionka nie zostałaby znaleziona w systemie, przeglądarka szuka drugiej, a na końcu rezerwowej czcionki „sans-serif”.

Teraz można podać adres URL czcionki jako regułę CSS, aby przeglądarka mogła pobrać czcionkę:

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

a następnie załaduj czcionkę dla określonego elementu, np .:

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

Jest to bardzo popularne, aby móc używać niestandardowych czcionek, ale prowadzi również do problemu, że tekst nie jest wyświetlany, dopóki zasób nie zostanie załadowany przez przeglądarkę, co obejmuje czas pobierania, czas ładowania czcionki i czas renderowania. Oczekuję, że to artefakt, którego doświadczasz.

Jako przykład: jedna z moich krajowych gazet, Dagens Nyheter , używa czcionek internetowych do swoich nagłówków, ale nie prowadzi, więc kiedy ta strona jest załadowana, zwykle widzę pierwsze, a pół sekundy później wszystkie puste miejsca powyżej są zapełniane z nagłówkami (przynajmniej w Chrome i Operze. Nie próbowałem jeszcze innych).

(Poza tym projektanci rozsypują JavaScript absolutnie wszędzie, więc może ktoś próbuje zrobić coś sprytnego z tekstem, dlatego jest opóźniony. To byłoby bardzo specyficzne dla strony: ogólna tendencja do opóźniania tekstu w tych tekstach czasy to opisany powyżej problem z czcionkami internetowymi).

Dodanie

Ta odpowiedź stała się bardzo pozytywna, choć nie wdałem się w szczegóły, a może właśnie z tego powodu . W wątku pytania było wiele komentarzy, więc postaram się trochę rozwinąć (wydaje się, że wiele komentarzy zniknęło krótko po tym, jak temat został zabezpieczony - prawdopodobnie jakiś moderator oczyścił je ręcznie). Przeczytaj także inne odpowiedzi w tym wątku, ponieważ wszystkie rozwijają się na swój własny sposób.

Zjawisko to jest najwyraźniej znane jako „flash niestylizowanej treści” w ogóle, a „flash niestylizowanego tekstu” w szczególności. Wyszukiwanie „FOUC” i „FOUT” daje więcej informacji.

Mogę polecić post projektanta sieci Paula Irish'a na FOUT w związku z czcionkami internetowymi .

Należy zauważyć, że różne przeglądarki radzą sobie z tym inaczej. Napisałem powyżej, że przetestowałem Operę i Chrome, które zachowały się podobnie. Wszystkie te oparte WebKit (Chrome, Safari, itp) wybrać, aby uniknąć FOUT przez nie renderowania tekstu czcionki internetowej z awaryjnej czcionki w okresie internetowej załadunku czcionki. Nawet jeśli czcionka internetowa jest buforowana, nastąpi opóźnienie renderowania . W tym wątku pytania jest wiele komentarzy mówiących inaczej i że błędem jest, że buforowane czcionki zachowują się w ten sposób, ale np. Z powyższego linku:

W jakich przypadkach otrzymasz FOUT

• Will: Pobieranie i wyświetlanie zdalnego ttf / otf / woff
• Will: Wyświetlanie buforowanego pliku ttf / otf / woff
• Will: Pobieranie i wyświetlanie danych-uri ttf / otf / woff
• Will: Wyświetlanie buforowanych danych uri ttf / otf / woff
• Nie będzie: wyświetlanie czcionki, która jest już zainstalowana i nazwana w tradycyjnym stosie czcionek
• Nie będzie: wyświetlanie czcionki, która jest zainstalowana i nazwana przy użyciu lokalizacji local ()

Ponieważ Chrome czeka na zniknięcie ryzyka FOUT przed renderowaniem, powoduje to opóźnienie. W jakim stopniu efekt jest widoczny (szczególnie podczas ładowania z pamięci podręcznej) wydaje się zależeć między innymi od ilości tekstu, który należy renderować, i być może innych czynników, ale buforowanie nie usuwa całkowicie efektu.

W dolnej części postu Irlandczycy mają także kilka aktualizacji dotyczących zachowania przeglądarki z lat 2011–04–14:

• Firefox (od FFb11 i FF4 Final) nie ma już FOUT! Wooohoo! http://bugzil.la/499292 Zasadniczo tekst jest niewidoczny przez 3 sekundy, a następnie przywraca czcionkę zastępczą. Webfont prawdopodobnie załaduje się w ciągu tych trzech sekund, choć… mam nadzieję…
• IE9 obsługuje WOFF, TTF i OTF (choć wymaga osadzenia zestawu bitów - głównie spornego, jeśli używasz WOFF). JEDNAK!!! IE9 ma FOUT. :(
• Webkit ma łatkę czekającą na wylądowanie, aby wyświetlić tekst zastępczy po 0,5 sekundy. Takie samo zachowanie jak FF, ale 0,5 s zamiast 3 s.
• Dodatek : Blink ma również zarejestrowany błąd , ale wydaje się, że nie osiągnięto ostatecznego konsensusu co do tego, co z tym zrobić - obecnie taka sama implementacja jak WebKit.

Gdyby było to pytanie skierowane do projektantów, można by na wiele sposobów uniknąć tego rodzaju problemów webfontloader, ale byłoby to inne pytanie. Link do irlandzkiego Paula zawiera dalsze szczegóły na ten temat.

Powodem tego jest fakt, że tekst, którego nie można jeszcze odczytać, jest renderowany za pomocą czcionki internetowej, która wciąż jest w drodze do potoków przeglądarki.

Ponadto, ponieważ twoją przeglądarką jest Google Chrome, która korzysta z WebKit do renderowania strony, postanowili (to znaczy WebKit), że najlepiej jest nie widzieć żadnego tekstu, dopóki czcionka internetowa nie zostanie pobrana. Jeśli jednak jesteś programistą, który wolałby, aby tekst był czytelny w odpowiedniej zastępczej czcionce systemowej, możesz użyć czegoś takiego jak Google WebFont Loader, aby to osiągnąć.

Krótka odpowiedź: AJAX lub WOFF

Istnieje kilka przyczyn witryn będących „slow aby wyświetlić ich tekst” . Powolność na portableapps.com jest spowodowana pobieraniem czcionek WOFF . Jednak to, co opisujesz jako „tekst zaczyna się pojawiać tu i tam”, jest częściej powodowane przez AJAX .

Witryna składa się z wielu części. Sposób pobierania i składania tych części jest wyborem projektu pod kontrolą projektanta stron internetowych . Powolność jest spowodowana sposobem, w jaki deweloper decyduje się na montaż następujących elementów:

• Początkowa strona HTML
• CSS
• JS
• Zdjęcia
• Czcionki WOFF
• Żądania AJAX
• Manipulacja DOM

Tradycyjnie strony internetowe:

Tradycyjnie programiści często umieszczali treść tekstową na początkowej stronie HTML i wyświetlali ją, gdy tylko będzie dostępna . HTML odwoła się do kilku zasobów, które następnie zostaną pobrane. Przeglądarka będzie następnie stopniowo przerysowywać ekran, aby uwzględnić style i obrazy w miarę ich udostępniania. AJAX i WOFF nie były dostępne.

Strony internetowe WOFF:

Czcionki WOFF pozwalają witrynie używać czcionek, które normalnie nie są dostępne dla przeglądarki, pobierając czcionki ze strony internetowej . Niektórzy programiści zalecają przeglądarce, aby nie wyświetlała zawartości tekstowej, dopóki nie zostaną pobrane wszystkie czcionki WOFF. Z mojego doświadczenia wynika, że ​​takie podejście nie zyskało jeszcze szerokiego zastosowania.

Strony internetowe AJAX:

Niektórzy programiści nie włączają treści tekstowej na początkowej stronie HTML. Zamiast tego decydują się pobrać zawartość tekstową za pomocą AJAX. Dzieje się tak po załadowaniu strony podstawowej . Z mojego doświadczenia wynika, że ​​metoda ta zyskała znacznie szersze zastosowanie niż czcionki WOFF i jest najczęściej przyczyną opisywanej powolności.

Ustalenie przyczyny

Aby ustalić przyczynę określonej witryny, należy przeprowadzić analizę przy użyciu narzędzi takich jak Firebug lub Chrome Developer Tools . Możesz też otworzyć witrynę za pomocą programu Internet Explorer 8 , który obsługuje AJAX, ale nie WOFF. Jeśli strona jest nadal wolna, problemem jest AJAX, a nie WOFF.

Często może to być celowy wybór, aby uniknąć „flashowania niestylizowanej treści”. Jeśli tekst wyświetlany przed załadowaniem CSS, zobaczysz go na krótko, tak jak wygląda na surowy, a następnie flash, gdy przeglądarka go przerysuje. Wstawiając niektóre podstawowe style wbudowane w celu początkowego ukrycia treści, które są zastępowane w rzeczywistym arkuszu stylów, lub używając JS, programiści unikają tego flashowania.

Jak zauważyli inni, niestandardowe czcionki prawdopodobnie przyczyniają się do opóźnienia.

Aby dać nieco więcej tła, przeglądarka wykonuje mniej więcej następujące czynności, zanim będzie mogła renderować zawartość strony na ekranie:

1. pobierz HTML (kilka podróży w obie strony dla DNS, TCP, żądanie / odpowiedź)
2. zacznij analizować HTML, odkrywaj zewnętrzne zasoby, takie jak zewnętrzny CSS i JS. Zauważ, że układ bloków CSS i parsowanie bloków JS. Tak więc zasoby zewnętrzne, takie jak CSS i JS ładowane na początku dokumentu (np. W głowie), spowalniają czas potrzebny na wyświetlenie strony na ekranie.
3. pobierz zewnętrzny CSS i JS (kilka podróży w obie strony: DNS i TCP, jeśli te zasoby znajdują się w innej domenie, takiej jak CDN, a także RTT dla żądania / odpowiedzi)
4. po zakończeniu ładowania zewnętrznego CSS i JS przeanalizuj / uruchom JS, przeanalizuj / zastosuj style
5. jeśli CSS odwołuje się do czcionek niestandardowych, czcionki te należy teraz również pobrać, co powoduje dodatkowe opóźnienia w obie strony w celu renderowania dowolnych części strony zależnych od czcionek niestandardowych

Chociaż nie chodzi o opóźnienia spowodowane konkretnymi czcionkami niestandardowymi, niedawno napisałem post na blogu, który zawiera dodatkowe informacje o przyczynach opóźnień renderowania. Daje sugestie, aby zminimalizować czas do pierwszego malowania stron. Mamy nadzieję, że jest to przydatne dla czytelników zainteresowanych szybszym wyświetlaniem zawartości na swoich stronach, w tym stron, które chcą używać niestandardowych czcionek: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -sekundę/

Krótka odpowiedź: programiści.

Kiedy znaczniki linku i skryptu odnoszące się do dokumentów zewnętrznych (takich jak pliki .css lub .js) są umieszczane w nagłówku dokumentu (wyżej w toku niż treść i jej elementy), są ładowane jako pierwsze. JavaScript wykonuje się ze znaczników, które się do niego odwołują; jeśli jest dużo kodu do przetworzenia lub jest to nieporęczny kod, lub częściej, jeśli oczekiwany tekst jest renderowany na serwerze i wprowadzany do dokumentu po załadowaniu - i ten kod po stronie serwera jest również kłopotliwy, duże lub blokujące operacje wejścia / wyjścia z powodu przetwarzania kilku równoczesnych żądań, możesz z pewnością zauważyć przestoje, zanim HTML będzie miał szansę nawet renderować. Niektórzy programiści wybierają ładowanie kodu JavaScript niezwiązanego z widokiem po znacznikach i stylach (na końcu treści),

Szybkość połączenia internetowego odgrywa istotną rolę w powolnym pobieraniu danych, oczywiście, ale źle napisany kod lub źle zaprojektowane stosy technologii (dla typu strony internetowej) odgrywają coraz większą rolę w powolnym ładowaniu dynamicznej zawartości, ponieważ szybsze połączenia sieciowe zbliżyć się do wszechobecności.

W skrócie, zbyt wiele ładowalnych obiektów, które muszą zostać załadowane z oddzielnych HTTP GET, zanim strona będzie mogła zostać wyświetlona, ​​oraz nadmierne poleganie na średnim opóźnieniu jako mierniku stanu witryny.

Pierwszy odnosi się do wszystkich plików .css, .js i stron WWW ładowanych przez stronę, nie wspominając o tym, że wiele witryn musi również pobierać obiekty JSON za pomocą żądań XHR, a następnie generować HTML z tych, które korzystają z pewnego rodzaju szablonów.

Ale dlaczego nie zauważą, że strona jest powolna?

Prawdopodobnie dlatego, że mają tam pamięć podręczną, aby przyspieszyć (lub polegać tylko na pamięci podręcznej systemu plików) i mierzą kondycję swojej witryny przy użyciu średniego opóźnienia. W ten sposób buforowane obiekty są zwracane z 6-cio milisekundowym opóźnieniem i maskują fakt, że wiele żądań GET zajmuje 5000 milisekund. Średnie muszą umrzeć. Niech żyje zliczanie RTT powyżej akceptowalnego maksymalnego progu! Liczba ta powinna wynosić 0 lub, z definicji, RTT jest niedopuszczalny.

Jest wiele powodów. Jednym z powodów jest również to, że polecenia do definiowania tła lub na górze strony HTML często są pobierane w osobnym CSS, który jest ładowany jako pierwszy. przed załadowaniem treści dokumentu zawierającego tekst.

Inną przyczyną jest to, że chociaż możliwe jest wpisanie rozmiaru obrazu, w większości przypadków projektanci stron internetowych z niego nie korzystają. I tak brouwser musi najpierw załadować całe obrazy na strony, aby wiedział, jak owinąć wokół niego tekst.

Niektórzy projektanci również chcą pokazać pierwsze zdjęcia i następny tekst, osiągają to za pomocą jakiegoś javascript, więc na przykład prosta strona najpierw pokaże baner, a następnie wszystko inne na nim.

Ale jeśli zastanawiasz się, dlaczego na moich stronach jest tak dużo spamu, a ja chcę tylko czytać wiadomości, istnieje rozwiązanie dla Ciebie. Możesz korzystać z programów blokujących spam, jeśli używasz Firefoxa. Dzięki takiemu dodatkowi przeglądarka zna strony, które dostarczają spam, i po prostu je blokuje, co powoduje znacznie szybsze ładowanie strony, a Ty nadal widzisz ważne obrazy związane z czytanymi artykułami.

Polecam wszystkim, którzy zajmują się powolnym ładowaniem strony, aby spróbować skrzypka. fidler może być używany z IEexplorer lub FireFox (używając jego funkcji proxy) Fidler pokaże Ci, ile czasu to faktycznie zajmuje i kiedy ładowane są części strony. Jest to narzędzie do debugowania HTML.