Создание быстро загружаемого блога с очень простым бэкендом

Создание быстро загружаемого блога с очень простым бэкендом

Часть 2: Оптимизация

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

Первая часть касалась бэкенда. Теперь пришло время пройти шаги, которые я предпринял, чтобы сделать это как можно быстрее.

Шрифты

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

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

Это известно как FOIT: вспышка невидимого текста.

Такое поведение заставляет сайт чувствовать себя медленнее, чем он может быть на самом деле, поскольку пользователю приходится ждать появления текста, даже если он уже находится в DOM.

FOUT

Решение FOUT: Flash Of Unstyled Text. Короче говоря, сначала используйте стандартный шрифт, а после загрузки измените его на веб-шрифт.

Дизайнер может не быть большим поклонником этого, так как это может выглядеть немного странно, когда меняется шрифт, но это самый быстрый способ доставки контента для потребления пользователем.

Выполнение

Я использую в блоге веб-шрифт Aladin, и он загружается с помощью скрипта Web Font Loader от Typekit. После того как скрипт загрузил шрифт, он добавляет класс к элементу html. Вы можете управлять шрифтами, написав свой CSS следующим образом:

body {
  font-family: sans-serif;
}
.wf-aladin-n4-active body {
  font-family: 'Aladin';
}

Таким образом, текст всегда будет виден пользователю. Сначала шрифт будет без засечек, но после загрузки он изменится на Aladin. Пользователю не нужно ждать, пока он сможет прочитать текст.

Модули JavaScript

В блоге используется не так много JavaScript, но используется несколько скриптов:

• Загрузчик веб-шрифтов
• ленивые размеры
• Скрипт пользовательского счетчика

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

Например, может потребоваться загрузить jQuery, а вместе с jQuery поставляется ползунок и модальный плагин. Они, вероятно, заключены в классическую функцию jQuery(document).ready(), что означает, что они будут инициализированы одновременно. Это может даже не понадобиться, поскольку мы не знаем, содержит ли текущая страница ползунок или модальное окно.

Вместо этого лучше отложить инициализацию скриптов как можно дольше. Чем меньше скриптов нужно запускать, тем быстрее будет работать сайт.
Еще лучше, если скрипты можно будет скачать позже, а не все сразу.

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

Однако сценарий счетчика является второстепенным. Для начала может даже не понадобиться скачивать. Это потому, что он должен считать только время, когда мы в данный момент охотились. Если мы не охотимся за моментом, сценарий не нужен.

Автооптимизация

Отличный плагин WordPress Autoptimize просто необходим.

Он заботится о:

• Минификация
• Конкатенация
• Критический CSS
• Добавляет атрибут async к <script> тегам
• Создает <link> с атрибутом preload для таблицы стилей.

Кэш

Это довольно прямолинейно. Когда дело доходит до кэширования, я часто использую плагин WP Super Cache.

Сервисный работник

Чтобы создать действительно быстро загружаемый веб-сайт, добавление сценария сервисного работника является более или менее обязательным требованием.

Для этого я использую библиотеку сервис-воркеров Workbox.

Workbox позволяет настроить ряд «маршрутов» с помощью регулярных выражений. У меня есть следующие в моем сервис-воркере:

• Домашняя страница: /
• Папка для загрузок: wp-content/uploads/
• Активы темы: wp-content/themes/my-theme/assets/
• Автооптимизация файлов: wp-content/cache/autoptimize/

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

Эти функции обратного вызова также называются «стратегиями». В зависимости от того, какую стратегию вы выберете, Workbox будет обрабатывать активы по-разному.

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

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

Существует также стратегия cacheFirst, которая сначала ищет актив в кеше и использует сеть в качестве запасного варианта.

Из документации:
Эта стратегия сначала проверяет кеш на наличие ответа и использует его, если он доступен. Если запроса нет в кеше, будет использоваться сеть, и любой действительный ответ будет добавлен в кеш перед передачей в браузер.

Вы можете использовать разные стратегии для разных маршрутов. Я использовал это:

• Домашняя страница: networkFirst()
• Папка для загрузок: cacheFirst()
• Активы темы: staleWhileRevalidate()
• Автооптимизировать файлы: staleWhileRevalidate()

Поскольку сайт представляет собой блог, я всегда хочу доставлять свежий контент с сервера, поэтому стратегия networkFirst().
Ресурсы из папки «Загрузки» вряд ли изменятся, поэтому используется стратегия cacheFirst().

А как насчет третьей стратегии, staleWhileRevalidate() ? Это своего рода комбинация между двумя другими. Сервисный работник будет предоставлять пользователю активы из кеша, но позже загрузит с сервера свежую версию того же самого актива.
Это означает, что при следующем посещении сайта пользователем будет показана обновленная версия ресурса. Эта стратегия хороша для активов, которые должны быть достаточно актуальными, но это не критично. Таблицы стилей — прекрасный пример!

Из документации:
Эта стратегия будет использовать кешированный ответ на запрос, если он доступен, и обновлять кеш в фоновом режиме с помощью ответа из сети. (Если он не кэширован, он будет ждать ответа сети и использовать его). Это довольно безопасная стратегия, поскольку она означает, что пользователи регулярно обновляют свой кеш. Недостатком этой стратегии является то, что она всегда запрашивает актив из сети, используя пропускную способность пользователя.

Вот полный скрипт сервис-воркера:

Числа

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

Тестовая оценка из PageSpeed ​​Insights непостоянна, но кажется, что она составляет около 90 баллов.

Webpagetest дает немного лучшие результаты теста:

• Первый байт: 0,2 с
• Старт рендера: 0,6с
• Индекс скорости: 0,695 с

Вот и все! Я надеюсь, что вы нашли это полезным, если это так, поставьте лайк и подпишитесь yada yada yada…