Чому веб-сайти не одразу показують їх текст сьогодні?

Я помітив, що останнім часом багато веб-сайтів повільно відображають свій текст. Зазвичай тло, зображення та інше завантажуються, але текст немає. Через деякий час текст починає з’являтися тут і там (не завжди все одночасно).

В основному це працює навпаки, як раніше, коли текст був відображений спочатку, потім зображення та решта завантажувались згодом. Які нові технології створюють це питання? Будь-яка ідея?

Зауважте, що я перебуваю на повільному зв’язку, що, ймовірно, підкреслює проблему.

Дивіться приклад нижче - все завантажено, але потрібно пройти ще кілька секунд, перш ніж текст нарешті відобразиться:

Однією з причин є те, що веб-дизайнери сьогодні люблять використовувати веб-шрифти (як правило, у форматі WOFF ), наприклад, через веб-шрифти Google .

Раніше єдиними шрифтами, які вдалося відобразити на сайті, були ті, які користувач встановив локально. Оскільки, наприклад, користувачі Mac та Windows не обов'язково мали однакові шрифти, дизайнери інстинктивно завжди визначали правила як

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

де, якби першого шрифту не було знайдено в системі, браузер шукав би другий, і нарешті, резервний шрифт "sans-serif".

Тепер можна вказати URL-адресу шрифту як правило CSS, щоб браузер міг завантажити шрифт як такий:

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

а потім завантажте шрифт для певного елемента, наприклад:

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

Це дуже популярно, щоб можна було використовувати спеціальні шрифти, але це також призводить до проблеми, що жоден текст не відображається, поки браузер не завантажить ресурс, який включає час завантаження, час завантаження шрифту та час візуалізації. Я очікую, що це артефакт, який ви переживаєте.

Як приклад: одна з моїх національних газет, Dagens Nyheter , використовує веб-шрифти для своїх заголовків, але не їх потенційних клієнтів, тому, коли цей сайт завантажений, я, як правило, спочатку бачу потенційні записи, а через півсекунди всі порожні місця вгорі заповнені з заголовками (це стосується принаймні Chrome і Opera. Не намагалися інші).

(Крім того, дизайнери розповсюджують JavaScript абсолютно скрізь скрізь, тому, можливо, хтось намагається зробити щось розумніше з текстом, саме тому він затягується. Однак це було б дуже специфічно для сайту: загальна тенденція затягування тексту в цих раз - це проблема веб-шрифтів, описана вище, я вважаю.)

Доповнення

Ця відповідь стала дуже прихильною, хоча я не вдавався в деталі, а може, через це. У темі запитань було багато коментарів, тому я спробую трохи розширити (начебто багато коментарів зникли на короткий час після того, як тема була захищена - певний модератор, ймовірно, вручну їх очистив). Також прочитайте інші відповіді в цій темі, оскільки всі вони розширюються по-своєму.

Явище, мабуть, відоме як "спалах нестирного змісту" взагалі та "спалах нестилізованого тексту" зокрема. Пошук "FOUC" та "FOUT" дає більше інформації.

Я можу порекомендувати публікацію веб-дизайнера Пола Ірландського FOUT у зв'язку з веб-шрифтами .

Що можна зазначити, це те, що різні браузери по-різному обробляють це. Я писав вище, що перевіряв Opera і Chrome, які обидва поводилися однаково. Усі ті, що базуються на WebKit (Chrome, Safari тощо), вирішують уникати FOUT, не надаючи текст веб-шрифту з резервним шрифтом протягом періоду завантаження веб-шрифту. Навіть якщо веб-шрифт буде кешовано, буде затримка візуалізації . У цій темі запитань є багато коментарів, які говорять інакше, і що це неправильно, що кешовані шрифти поводяться так, але, наприклад, із наведеного вище посилання:

У яких випадках ви отримаєте ПІДГОТОВКА

• Буде: Завантаження та показ віддаленого ttf / otf / woff
• Буде: Відображення кешованого ttf / otf / woff
• Буде: Завантаження та відображення даних-uri ttf / otf / woff
• Буде: Відображення кешованих даних-uri ttf / otf / woff
• Не буде: Відображення шрифту, який уже встановлений і названий у вашому традиційному стеці шрифту
• Не буде: Відображення встановленого та названого шрифту за допомогою локального () розташування

Оскільки Chrome чекає, поки ризик FOUT не зникне, перш ніж відобразити, це призводить до затримки. В якій мірі ефект помітний (особливо при завантаженні з кешу) , як видається, залежить від числа інших речей , обсяг тексту , який повинен бути наданою , і , можливо , інших факторів, але кешування в повному обсязі усунути ефект.

Ірландський також має деякі оновлення щодо поведінки браузера станом на 2011–04–14 внизу публікації:

• У Firefox (станом на FFb11 та FF4 Final) більше немає ПІДТВОРЕННЯ ! Wooohoo! http://bugzil.la/499292 В основному текст невидимий протягом 3 секунд, а потім він повертає резервний шрифт. Веб-шрифт, ймовірно, завантажується протягом цих трьох секунд, хоча ... сподіваємось ..
• IE9 підтримує WOFF і TTF і OTF (хоча це вимагає вбудовування рішень, встановлених бітом - переважно спот, якщо ви використовуєте WOFF). ЗАРАЗ !!! IE9 має ПІТ. :(
• Webkit має виправлення, яке очікує виходу тексту, який відображатиметься за 0,5 секунди. Настільки ж поведінка, що і FF, але 0,5s замість 3s.
• Додаток : Blink також зареєстрував помилку для цього , але, здається, остаточного консенсусу не було досягнуто щодо того, що з ним робити - на даний момент реалізація, як WebKit.

Якби це питання, призначене для дизайнерів, можна було б вдатися до способів уникнути таких проблем, як webfontloader, але це було б інше питання. Пол Ірландський посилання детальніше деталізується з цього приводу.

Причиною цього є те, що текст, який ви ще не можете прочитати, надається веб-шрифтом, який все ще йде по каналах до вашого браузера.

Крім того, оскільки ваш веб-переглядач - це Google Chrome, який використовує WebKit для візуалізації сторінки, вони вирішили (WebKit, тобто), що вам краще не бачити жодного тексту до завантаження веб-шрифту. Якщо ж ви розробник, який вважає за краще читати текст у відповідному системному шрифті, то для цього ви можете використовувати щось на зразок WebFont Loader від Google .

Коротка відповідь: AJAX або WOFF

Існує кілька причин того, що веб-сайти "повільно відображають свій текст" . Повільність на portableapps.com викликана завантаженням шрифтів WOFF . Однак те, що ви описуєте як "текст починає з'являтися тут і там" , частіше викликається AJAX .

Веб-сайт складається з багатьох частин. Як завантажувати та збирати ці деталі, це вибір дизайну під контролем веб-дизайнера . Повільність викликана тим, як розробник вирішує зібрати такі будівельні блоки:

• Початкова HTML-сторінка
• CSS
• JS
• Зображення
• WOFF шрифти
• AJAX запити
• Маніпуляція DOM

Традиційно веб-сайти:

Традиційно розробникам було прийнято розміщувати текстовий вміст на початковій HTML-сторінці та відображати його, як тільки він був доступний . HTML посилається на кілька ресурсів, які потім будуть завантажені. Потім браузер поступово перемальовує екран, щоб включати стилі та зображення, коли вони стали доступними. AJAX та WOFF були недоступні.

Веб-сайти WOFF:

Шрифти WOFF дозволяють веб-сайту використовувати шрифти, які зазвичай недоступні для браузера, завантажуючи шрифти з веб-сайту . Деякі розробники наказують браузеру не відображати текстовий вміст, поки не будуть завантажені всі шрифти WOFF. На мій досвід, цей підхід ще не отримав дуже широкого використання.

Веб-сайти AJAX:

Деякі розробники вирішують не включати текстовий вміст у початкову сторінку HTML. Натомість вони вирішують завантажити текстовий вміст за допомогою AJAX. Це відбувається після завантаження основної сторінки . На мій досвід, цей метод отримав набагато ширше поширення, ніж шрифти WOFF, і найчастіше є причиною повільності, яку ви описуєте.

Визначення причини

Щоб визначити причину конкретного сайту, потрібен аналіз за допомогою таких інструментів, як Firebug або Chrome Developer Tools . Або ж ви можете відкрити сайт за допомогою Internet Explorer 8 , який підтримує AJAX, але не WOFF. Якщо сайт все ще повільний, проблема AJAX, а не WOFF.

Я часто може бути навмисним вибором, щоб уникнути "спалаху невдоволеного контенту". Якщо текст, який відображається перед завантаженням CSS, ви його коротко побачите як він виглядає сирим, а потім спалах, коли браузер перемальовує його. Вводячи деякі основні стилі вбудованих даних, щоб спочатку приховати вміст, який переосмислюється у фактичному аркуші стилів, або використовуючи JS, розробники уникають цього спалаху.

Як зазначають інші, спеціальні шрифти, ймовірно, сприяють затримці.

Щоб отримати трохи більше фону, браузер робить приблизно наступне, перш ніж він зможе вивести вміст сторінки на екран:

1. отримати HTML (кілька туди і назад для DNS, TCP, запит / відповідь)
2. починайте розбирати HTML, відкривайте для себе зовнішні ресурси, такі як зовнішні CSS та JS. Зауважте, що CSS блокує макет, а JS блоки розбору. Тож зовнішні ресурси, такі як CSS та JS, завантажені на початку документа (наприклад, в голові), сповільнюють час, необхідний для сторінки для відображення вмісту на екрані.
3. отримати зовнішні CSS та JS (кілька туди-назад: DNS та TCP, якщо ці ресурси знаходяться в іншому домені, такому як CDN, а також RTT для запиту / відповіді)
4. як тільки зовнішні CSS та JS закінчують завантаження, розбирають / виконують JS, розбирають / застосовують стилі
5. якщо CSS посилається на користувальницькі шрифти, ці шрифти тепер доведеться завантажувати, що призводить до додаткових затримок у зворотному напрямку, щоб відобразити будь-які частини сторінки, які залежать від користувацьких шрифтів.

Хоча мова йде не про затримки, спричинені спеціально створеними шрифтами, я нещодавно написав допис у блозі, який дає додаткову інформацію про причини затримки візуалізації. Це дає кілька пропозицій, щоб мінімізувати час на перший малюнок для ваших сторінок. Сподіваємось, це корисно для читачів, зацікавлених у тому, щоб їх сторінки швидше відображали вміст, включаючи ті сторінки, які хочуть використовувати спеціальні шрифти: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -одна секунда/

Коротка відповідь: Розробники.

Коли теги посилань та сценаріїв, що посилаються на зовнішні документи (наприклад, .css чи .js-файли), розміщуються в заголовку документа (вище за потоком, ніж тіло та його елементи), вони завантажуються спочатку. JavaScript виконується з розмітки, на яку посилається; якщо код обробляється чимало, або він є громіздким кодом, або частіше, якщо текст, який ви очікуєте побачити, виводиться на сервер і заповнюється в документ при завантаженні - і цей однобічний серверний код також громіздкий, великий або блокуючи введення-виведення через обробку декількох одночасних запитів, ви, звичайно, можете помітити час простою, перш ніж HTML матиме шанс навіть рендерінгу. Деякі розробники вирішують завантажувати JavaScript, не пов’язаний із переглядом, після розмітки та стилів (в кінці тіла),

Швидкість підключення до Інтернету відіграє важливу роль у повільному завантаженні даних. Цілком очевидно, але погано написаний код або погано розроблений стек технологій (для типу веб-сайту) відіграють все більш центральну роль у повільному завантаженні динамічного контенту, оскільки більш швидкі мережеві з'єднання підхід всюдисущий.

Коротше кажучи, занадто багато об'єктів, що завантажуються, які потрібно завантажити з окремих HTTP GET, щоб сторінка відображалася, і надмірна залежність від середньої затримки як показника стану здоров'я сайту.

Перший стосується всіх тих .css, .js та веб-шрифтів, які сторінка завантажує, не кажучи вже про те, що для багатьох сайтів також потрібно отримати JSON-об'єкти viea XHR-запити, а потім генерувати HTML з тих, хто використовує якийсь шаблон.

Але чому вони не помічають, що сайт повільний?

Можливо, тому, що у них десь є пам'ять пам'яті, щоб прискорити роботу (або просто покладатися на кеші файлової системи) і вимірювати стан своїх сайтів за допомогою середньої затримки. Таким чином, кешовані об'єкти повертаються із затримкою 6 дзеркальних секунд і маскують той факт, що для багатьох запитів GET потрібно виконати 5000 мілісекунд. Середні повинні померти. Хай живе підрахунок RTT за допустимий максимальний поріг! Це число повинно бути 0 або, за визначенням, RTT є неприйнятним.

Ну є кілька причин. Однією з причин є також те, що команди для визначення фону або зверху на html-сторінці часто або отримані в окремому CSS, який завантажується першим. перед завантаженням корпусу документа, який містить текст.

Ще одна причина полягає в тому, що хоча ввести розмір зображення в більшості випадків веб-дизайнери не використовують цього. І тому бруузер повинен завантажувати цілі зображення спочатку на сторінки, щоб він міг обернути текст навколо нього.

Деякі дизайнери також хочуть показати перші фотографії та наступний текст, вони досягають цього за допомогою javascript, тому, наприклад, проста сторінка спочатку покаже банер, а потім все інше на ньому.

Але якщо вам цікаво, чому на моїх сторінках так багато комерційних матеріалів про спам, поки я хочу лише читати новини, то для вас є рішення. Якщо ви користуєтеся Firefox, ви можете скористатися блокуючими спаму. З таким доповненням веб-браузер знає сайти, що надають спам, і просто блокує їх, що призводить до набагато швидшого завантаження сторінки, при цьому ви все ще зможете побачити важливі зображення, що стосуються прочитаних статей.

Я рекомендую всім вам, хто займається повільним завантаженням сторінки, щоб спробувати Fidler. Fidler можна використовувати з IEexplorer або з FireFox (використовуючи його функцію проксі) Fidler фактично покаже вам, скільки часу насправді потрібно і коли завантажуються частини веб-сторінки. Це інструмент налагодження HTML.