Если вы видите макет сайта, вы должны одновременно видеть его текст. Если вы этого не сделаете, отправьте им эту статью.

Остановите меня, если вы видели это раньше: вы нажимаете на статью, и кажется, что она загружена, включая макет и цвета, но вы не видите текст, который хотели прочитать. Оказывается, вы ждете загрузки шрифтов. Хорошие новости: я объясню, как издатели могут избегать создания сайтов, которые ведут себя подобным образом, если только они не хотят, чтобы посетители сдались, закрыли страницу и вернулись в Facebook.

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

Учимся уменьшать количество сетевых запросов

Недавно я работал над улучшением веб-производительности в Smart Blogger. Используя webpagetest.org среди других инструментов, Тим Гэри и я начали сокращать время, необходимое для начала рендеринга страницы. В этом контексте, когда вам осталось менее 5 секунд, каждая десятая часть секунды (0,1 с) уменьшается в качестве прогресса.

Пробуя различные варианты оптимизации, я узнал кое-что новое: учитывается количество ресурсов HTTP, а не только их размеры. Другими словами, скорость страницы зависит от перегрузки сети, а не только от пропускной способности. Это остается верным даже при наличии HTTP / 2 и соединений keep-alive.

Например, статьи на Smart Blogger содержат комментарии с изображениями профиля, известными как Gravatars. Мы наблюдали, используя инструменты разработчика, как открытие статьи запускало поток сетевых запросов на Gravatars, что замедляло получение ресурсов, блокирующих рендеринг, таких как таблицы стилей в заголовке документа. Это не имело смысла: изображения с низким приоритетом, которые видны только после нескольких экранов прокрутки, не должны задерживать отображение заголовка статьи.

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

1. Ленивая загрузка

Шрифты

Благодаря веб-шрифтам онлайн-типографика за это десятилетие вышла далеко за пределы Джорджии и Верданы. Сегодня сайт The New Yorker выглядит почти как журнал. Однако за этот прогресс пришлось заплатить горячо обсуждаемую цену: неудачный опыт вспышки невидимого текста при загрузке шрифтов.

В этом конфликте нет необходимости. Мы можем добиться как хорошей типографики, так и быстрых страниц за счет асинхронной загрузки шрифтов: новые посетители получают резервные шрифты до тех пор, пока веб-шрифты не загрузятся, а вернувшиеся посетители получают веб-шрифты сразу из кеша браузера.

Коды асинхронной загрузки доступны у популярных поставщиков веб-шрифтов.

Загрузчик веб-шрифтов можно использовать для шрифтов, размещенных в разных местах: « Загрузка веб-шрифтов с помощью загрузчика веб-шрифтов ». Другой вариант - использовать библиотеку Font Face Observer, как описано в Повторная загрузка шрифта с событиями шрифта.

Дополнительная информация: Анализ производительности веб-шрифтов.

Изображений

Концепция большинства методов отложенной загрузки изображений заключается в создании в разметке изображения-заполнителя, которое заменяется предполагаемым изображением, когда эта часть страницы прокручивается в область просмотра. Заполнитель имеет временный атрибут src, который позже перезаписывается URL-адресом предполагаемого изображения, что побуждает браузер получить новое изображение в этой точке.

Используемый код зависит от вашей конкретной настройки, но в Интернете доступно множество примеров. Для WordPress мы использовали плагин a3 Lazy Load.

Примечание. Поскольку отложенная загрузка зависит от JavaScript, используйте теги noscript, чтобы предоставить теги изображения с предполагаемым URL-адресом для клиентов, не использующих JavaScript, таких как поисковая система. роботы. В нашем случае с этим справился плагин a3 Lazy Load.

2. Объедините несколько файлов CSS и JavaScript.

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

Мы использовали плагин Autoptimize для WordPress. У него много функций; мы использовали его только для объединения файлов CSS.

Примечание. Будьте осторожны при объединении файлов, чтобы не допустить появления ошибок. Например, как каскадные программы CSS, так и программы на JavaScript могут зависеть от расположения кода в определенном порядке. Кроме того, если CSS или JS различаются на разных страницах вашего сайта, вы можете предпочесть хранить некоторые файлы отдельно, чтобы их можно было кэшировать для повторных посетителей, вместо того, чтобы создавать различные комбинации.

3. Ракетный загрузчик CloudFlare

В то время как большинство техник веб-производительности похожи на скальпель, замысловато настраивающий ваш код и ресурсы, Rocket Loader - это молоток. Он практически останавливает весь JavaScript до тех пор, пока не будет загружена начальная страница. Если ваша страница включает внешние виджеты, такие как аналитика, кнопки обмена в социальных сетях и формы регистрации, Rocket Loader, вероятно, будет очень эффективным и сократит несколько секунд времени до первого рендеринга.

Rocket Loader может быть проинструктирован игнорировать определенные скрипты, которые мы должны были указать для скриптов загрузки шрифтов среди прочего кода.

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

Примечание. Вероятно, вы не захотите использовать Rocket Loader на веб-страницах, которые отображают только разметку на стороне клиента, например одностраничные приложения, работающие на платформах JavaScript, таких как React, Angular или Ember.

Возможные проблемы

Оплавление

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

Этот вопрос подробно рассматривается в статье Наши лучшие практики убивают производительность мобильного Интернета.

Браузеры должны поддерживать нативную отложенную загрузку

Современные методы отложенной загрузки используют обходные пути JavaScript. Это добавляет сложности, поскольку отсутствует стандартный код или метод, и если вы хотите, чтобы элементы с отложенной загрузкой также существовали в незашифрованном HTML-документе, вам необходимо предоставить альтернативную разметку в тегах noscript.

Я бы рекомендовал, чтобы производители браузеров поддерживали атрибут типа lazyload в таких элементах, как img, script и link только для получить ресурсы, указанные с помощью этого атрибута, после загрузки исходного документа. (Элемент script имеет атрибуты defer и async, но на самом деле они не задерживают HTTP-запрос на выборку скрипта.)

Резюме

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

Следующие шаги

Если вы нашли эту статью полезной, мы будем благодарны за советы Paypal.

Если вашему веб-сайту или организации требуется улучшение веб-производительности, свяжитесь с нами (напишите в gmail) - мы с коллегами можем помочь.

Вопросы или отзывы? Напишите в комментариях.

Была ли статья полезной? Приветствуются советы Paypal.

Я работаю над приложением для поиска подкастов. Подпишитесь на обновления на niceasthis.com или следите за twitter.com/niceasthis и facebook.com/niceasthis

Я также ищу проекты веб-разработки, желательно связанные с WordPress или React; некоторая информация о моем прошлом в LinkedIn.

Вы можете связаться со мной в Twitter, LinkedIn или через gmail

Другие мои записи, которые могут вам понравиться:

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.

Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!