Чому веб-сторінки не відразу відображають текст?
Якщо ви схильні до перегляду панелі браузера орлиним оком, ви, мабуть, помітили, що сторінки часто завантажують свої зображення та макет перед завантаженням їхнього тексту - точно протилежний шаблон завантаження, який ми переживали протягом 1990-х. Що відбувається?
Сьогоднішня сесія запитань та відповідей приходить до нас люб'язно SuperUser - підрозділ Stack Exchange, групування веб-сайтів із запитаннями та відповідями на рівні спільноти..
Питання
Читач SuperUser Лоран дуже цікавиться, чому саме сторінки, здається, завантажують елементи зовсім інакше, ніж колись. Він пише:
Я помітив, що останнім часом багато веб-сайтів повільно показують свій текст. Зазвичай, фон, зображення тощо збираються завантажуватися, але жодного тексту немає. Через деякий час текст починає з'являтися тут і там (не завжди все одночасно).
Це в основному працює навпаки, як це було раніше, коли текст був показаний першим, потім зображення, а решта завантажувалося після цього. Яка нова технологія створює цю проблему? Будь-яка ідея?
Зауважте, що я на повільному з'єднанні, що, мабуть, підкреслює проблему.
Для прикладу див. [Вище] - все завантажено, але це займе кілька секунд, перш ніж текст нарешті відобразиться.
Так що ж дає? Лоран, і багато хто з нас, пам'ятають час, коли текст завантажувався спочатку і все інше - гарніс анімовані GIF, плиткові фони, і всі інші артефакти в кінці 90-х в Інтернеті прийшли пізніше. Що обумовлює поточну ситуацію елементів дизайну спочатку, текст пізніше?
Відповідь
Співдоповідач SuperUser Даніель Андерссон пропонує чудову, детальну відповідь, яка виходить на дно загадкової загальної причини:
Однією з причин є те, що веб-дизайнери сьогодні користуються веб-шрифтами (зазвичай у форматі WOFF), наприклад через шрифти Google Web.
Раніше єдиними шрифтами, які можна було відобразити на сайті, були ті, які користувач локально встановив. Так як напр. Користувачі Mac і Windows не обов'язково мали однакові шрифти, дизайнери інстинктивно завжди визначали правила як
сімейство шрифтів: Arial, Helvetica, sans-serif;де, якщо перший шрифт не був знайдений у системі, переглядач буде шукати другий шрифт, і, нарешті, запасний шрифт sans-serif.
Тепер можна надати URL-адресу шрифту як правило CSS, щоб завантажити веб-переглядач шрифтом як такий:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700);а потім завантажують шрифт для конкретного елемента, наприклад:
сімейство шрифтів: 'Droid Serif', без засічок;Це дуже популярно, щоб мати можливість використовувати спеціальні шрифти, але це також призводить до проблеми, що жоден текст не відображається, поки ресурс не буде завантажено браузером, що включає час завантаження, час завантаження шрифту та час візуалізації. Я очікую, що це артефакт, який ви переживаєте.
Як приклад: одна з моїх національних газет, Dagens Nyheter, використовує веб-шрифти для своїх заголовків, але не їхні провідники, тому, коли цей сайт завантажується, я зазвичай бачу провідні перші, а через півсекунди всі пробіли вище заповнені з заголовками (принаймні, це стосується Chrome і Opera. Не пробували інші).
(Крім того, дизайнери посипають JavaScript абсолютно всюди в ці дні, так що, можливо, хтось намагається зробити щось розумне з текстом, тому його затримують. час - це проблема веб-шрифтів, описана вище.)
Додаток:
Ця відповідь стала дуже висвітленою, хоча я не вдавалася докладно, а може бути оскільки це. У темі запитань було багато коментарів, тому я спробую трохи розширити […]
Це явище, мабуть, відоме як «спалах неститованого контенту» в цілому, і, зокрема, «спалах непромененого тексту». Пошук "FOUC" і "FOUT" дає більше інформації.
Я можу порекомендувати публікацію веб-дизайнера Пола Ірландця на FOUT у зв'язку з веб-шрифтами.
Можна відзначити, що різні браузери обробляють це по-різному. Я писав вище, що перевірив Opera і Chrome, які обидва поводилися подібним чином. Усі засновані на WebKit (Chrome, Safari та ін.) Вирішують уникати FOUT ні рендеринга тексту веб-шрифт з запасний шрифт під час завантаження веб-шрифтів. Навіть якщо веб-шрифт кешується там волі бути затримкою візуалізації. Існує багато коментарів у цій темі запитань, інакше кажучи, що неправильно, що кешовані шрифти ведуть себе так, але, наприклад, з наведеного вище посилання:
У яких випадках ви отримаєте FOUT
- Буде: Завантаження та відображення віддаленого ttf / otf / woff
- Буде: Відображення кешованого ttf / otf / woff
- Буде: Завантаження та відображення даних uri ttf / otf / woff
- Буде: Відображення кешованих даних uri ttf / otf / woff
- Не буде: Відображення шрифту, вже встановленого і названого у вашому традиційному стеку шрифтів
- Не буде: Відображення шрифту, який встановлено та названо за допомогою локального () розташування
Оскільки Chrome чекає, поки ризик FOUT піде до рендеринга, це дає затримку. До якої мірою ефект є видимим (особливо при завантаженні з кешу), здається, залежить, серед іншого, від кількості тексту, який потрібно візуалізувати, і, можливо, від інших факторів, але кешування не повністю знімає ефект.
Ірландська також має деякі оновлення щодо поведінки веб-переглядача станом на 2011-04-14 у нижній частині повідомлення:
- Firefox (станом на FFb11 і FF4 Final) більше не має FOUT! Wooohoo! Http: //bugzil.la/499292 В основному текст невидимий протягом 3 секунд, а потім він повертає запасний шрифт. Webfont певно навантажують в межах цих трьох секунд хоч… hopefully…
- IE9 підтримує WOFF і TTF і OTF (хоча для цього потрібно вбудовування бітсета - в основному спірне, якщо ви використовуєте WOFF). ТАК! IE9 має FOUT. :(
- Webkit має патч, який очікує приземлення, щоб показати запасний текст через 0,5 секунди. Так само поведінка як FF але 0.5s замість 3s.
Якби це було питання для дизайнерів, можна було б піти на шляху, щоб уникнути таких проблем, як
webfontloader, але це було б інше питання. Посилання ірландця Павла переходить до подальших деталей з цього питання.
Маєте щось додати до пояснення? Звучить в коментарях. Хочете прочитати більше відповідей від інших технологічних користувачів Stack Exchange? Перегляньте повний потік обговорення тут.
