Практические способы ускорить ваш медленный сайт
Ни для кого не секрет, что пользователи чрезвычайно чувствительны к веб-производительности. Малейшее изменение времени загрузки веб-сайта может повлиять на то, останется ли пользователь или уйдет. Крупные корпорации опубликовали множество исследований, которые дают количественную оценку ценности веб-производительности. Amazon обнаружил, что дополнительные 100 мс задержки эквивалентны потере 1% продаж. Walmart опубликовал исследование, показывающее увеличение конверсии на 2% за каждую секунду, сэкономленную во время загрузки. Google также обнаружил, что каждые «400 мс увеличения времени загрузки соответствуют 0,44% потерянных сеансов поиска. Я думаю, что эти цифры хорошо отражают ощутимые эффекты веб-производительности и служат веским аргументом в пользу того, что вы хорошо разбираетесь в оптимизации вашего веб-приложения. Если вы работаете в Amazon и пишете res.redirect(), что может легко занять 200 мс для перезагрузки страницы и еще одного поиска в DNS, это 2% продаж… в масштабе сотен миллионов долларов. Имея это в виду, давайте немного узнаем о веб-производительности.
Веб-производительность на самом деле является общим термином, который охватывает несколько аспектов одного веб-сайта. Обычно, когда мы говорим о веб-производительности, мы имеем в виду одно из двух измерений: время "завершения документа" или время "полного рендеринга". Эти показатели важно понимать. Думайте о времени завершения документа как о времени, которое требуется для загрузки страницы, прежде чем вы сможете начать щелкать или вводить данные. Весь контент может быть еще не там, но вы можете взаимодействовать со страницей. Думайте о времени полного рендеринга как о времени, которое требуется для загрузки и отображения всех изображений, рекламных объявлений и всего остального, что необходимо загрузить вашему сайту. Таким образом, чтобы оптимизировать наш веб-сайт, нам нужно знать, как сократить время взаимодействия или время рендеринга.
Стабильность сайта также должна быть частью разговора о веб-производительности. Наличие надежного веб-сайта, который не дает сбоев, важно для того, как пользователи воспринимают ваш бренд. Если у вас большие масштабы, вероятно, неплохо было бы иметь резервного поставщика DNS. В 2016 году около половины интернета было отключено (лишь небольшое преувеличение) из-за массированной DDoS-атаки на DNS-провайдера Dyn. Вы даже не могли твитнуть о своем разочаровании, потому что Twitter не работал. Это, безусловно, предостерегающая история для компаний, которые масштабируются с большим пользовательским трафиком и полностью зависят от одного поставщика DNS.
Веб-производительность также может означать, что нужно думать о пользователях, у которых нет доступа к молниеносному интернету, к которому мы так привыкли в США. Не у всех в мире есть высокоскоростной интернет 4G. За пределами Кремниевой долины и за пределами США, если у вас плохой тарифный план, загрузка CNN может стоить 30 долларов. Разработчики должны учитывать всех пользователей, использующих их приложения, а это означает, что нужно учитывать пользователей, у которых скорость интернета ниже оптимальной. Это часть мотивации Вторника 2g в Facebook, когда разработчики могут подписаться на симуляцию того, как миллионы людей в развивающихся странах пытаются получить доступ к их веб-сайту. Точно так же у Netflix есть серверы, к которым могут подключаться разработчики, которые имитируют использование своего сайта в сети 2G. Если вы хотите увидеть, как ваш веб-сайт работает в неоптимальных условиях, просто откройте инструменты разработчика Chrome и перейдите на вкладку сети, где вы можете регулировать скорость своего интернета.
Веб-производительность также может иметь другие, более косвенные последствия для вашей компании, о которых вы, вероятно, не подозреваете. Например, рейтинг страниц в Google учитывает производительность сети или «время загрузки страницы». Google не уточнил значение, которое его алгоритм придает времени загрузки веб-сайта, но мы знаем, что это влияет на то, будет ли ваш веб-сайт отображаться на первой или второй странице… и никто не хочет быть на второй. страница. Еще одна причина всегда думать о веб-производительности.
Итак, теперь, когда мы знаем, что влечет за собой веб-производительность и почему это важно, как мы можем начать оптимизировать производительность? Прежде чем приступать к какой-либо упреждающей оптимизации (наихудший вид), нам нужно немного покопаться и оценить состояние нашего веб-сайта. Слепая оптимизация неэффективна или неэффективна. Вам нужно начать процесс оптимизации с поиска узких мест — конкретных болевых точек вашего веб-сайта, которые замедляют время, необходимое для отображения/взаимодействия с вашим сайтом. страница. Хорошим местом для поиска этих узких мест является вкладка сети в инструментах разработчика Chrome. Итак, давайте поднимем их!
Посмотрите внизу DOMContentLoaded. Если это число необычно велико (более 8 секунд), обратите внимание на скрипты, которые задерживают загрузку и синтаксический анализ основного документа. Когда браузер встречает тег <script>, он должен приостановить рендеринг, чтобы немедленно выполнить скрипт. Это то, что люди имеют в виду, когда говорят «не помещайте медленный код в стек», потому что он блокирует рендеринг. Найдите скрипты, которые не нужны для загрузки страницы, и пометьте их как асинхронные или отложите их выполнение, чтобы ускорить загрузку.
Кроме того, следите за большими сетевыми запросами, такими как загрузка 20 изображений в сверхвысоком разрешении. Они не блокируют рендеринг браузера, но для загрузки и отображения контента требуется время, что может привести к тому, что ваш веб-сайт будет выглядеть медленным (а производительность часто зависит от внешнего вида). После того, как вы определили большие запросы, подумайте, нужны ли они полностью или их можно загружать отложенно. Отложенная загрузка (в отличие от быстрой загрузки) — отличный способ оптимизировать сайт. Это включает в себя разделение вашего кода на логические точки останова, а затем его загрузку после того, как пользователь сделал что-то, что требует или потребует новый блок кода. Это ускоряет первоначальную загрузку приложения и снижает его общий вес, поскольку некоторые блоки могут вообще не загружаться. Таким образом, с отложенной загрузкой вы амортизируете время загрузки в ходе работы вашего приложения, а также сокращаете неиспользуемую информацию.
Существуют также аспекты производительности, о которых следует помнить на протяжении всего жизненного цикла проекта. Например, примите во внимание оптимизацию CSS, особенно если вы работаете над большим проектом. CSS может быстро складываться. Наличие такого количества селекторов и селекторов-потомков может сказаться на производительности. Некоторые разработчики могут счесть это микрооптимизацией, но в определенный момент, если ваша кодовая база достаточно велика, раздувание CSS может стать серьезной проблемой. Никто не хочет рефакторить CSS, но иногда это необходимо сделать. Если вы пишете действительно чистый Sass, взгляните на транспилированный CSS, и вы, возможно, удивитесь. Поэтому, если вы пишете Sass или LESS, знайте, во что транспилируется ваш код.
Кроме того, используйте ловушки жизненного цикла вашего процесса сборки и убедитесь, что вы всегда минимизируете свой JavaScript и CSS для производства. Если вы не знакомы, минификация — это процесс удаления ненужных или избыточных данных, не влияющий на то, как ваш код обрабатывается браузером. комментарии и форматирование кода, удаление неиспользуемого кода, использование более коротких имен переменных и функций и т. д.
А теперь одна из самых важных тем… изображения! Изображения часто составляют большую часть загруженных байтов на странице. Вы всегда должны помнить о производительности, когда используете изображения. Изображения в сверхвысоком разрешении/слишком много изображений — одна из основных причин медленной работы сайтов. Таким образом, оптимизация изображений часто позволяет добиться наибольшей экономии байтов и повышения производительности: чем меньше байтов загружает браузер, тем меньше конкуренция за пропускную способность клиента и тем быстрее браузер может загружать и отображать контент на экран. Изображения следует обрезать, сохранить для Интернета, а затем сжать. Всегда. Без исключений. И когда вы можете использовать SVG вместо изображений. SVG могут полностью заменить любые значки или логотипы, они просто состоят из кода и отображаются браузером, поэтому занимают меньше места.
Наконец, убедитесь, что вы получаете несложные результаты: используйте кэширование браузера, включите gzip и не злоупотребляйте переадресацией.
Чтобы использовать кеширование вашего браузера, как правило, вы можете указать, как долго веб-браузеры должны хранить изображения, CSS и JS локально. Таким образом, браузер пользователя будет загружать меньше данных при навигации по вашим страницам, что повысит скорость загрузки вашего веб-сайта. Если вы используете веб-пакет, ознакомьтесь с документацией по кэшированию и разделению кода. У Heroku также есть подробная статья для дальнейшего чтения.
GZIP — это универсальный компрессор, который можно применять к любому потоку байтов. Под капотом он запоминает часть ранее просмотренного контента и пытается найти и заменить повторяющиеся фрагменты данных эффективным способом. Все современные браузеры поддерживают и автоматически согласовывают сжатие GZIP для всех HTTP-запросов. Однако вы должны убедиться, что сервер правильно настроен для обслуживания сжатого ресурса. Наконец, хотя большинство серверов автоматически сжимают ресурсы для вас при предоставлении их пользователю, некоторые CDN требуют особого внимания и ручных усилий. чтобы убедиться, что актив GZIP обслуживается. Проведите аудит своего сайта и убедитесь, что ваши активы действительно сжимаются. Если вы используете экспресс-сервер, настроить GZIP так же просто, как несколько строк кода.
const compression = require('compression');
const express = require('express');
const app = express();
app.use(compression());Наконец, не злоупотребляйте редиректами. Перенаправления запускают дополнительный цикл HTTP-запрос-ответ и задерживают отображение страницы. В лучшем случае каждое перенаправление добавит одну обратную связь (HTTP-запрос-ответ), а в худшем может привести к нескольким дополнительным двусторонним операциям для выполнения поиска DNS, рукопожатия TCP и согласования TLS в дополнение к дополнительный цикл HTTP-запрос-ответ. В результате вы должны свести к минимуму использование перенаправлений для повышения производительности сайта.
Если ваш сайт кажется медленным, возможно, он слишком медленный. Вот почему вы всегда должны настраивать показатели, которые будут измерять производительность для вас, а не субъективно оценивать производительность вашего сайта. Цифры важны, особенно когда вы пытаетесь оценить, действительно ли ваша оптимизация ускорила TTI или TTR вашего сайта. По этой причине рассмотрите возможность настройки автоматических тестов, которые предупреждают вас, если ваша страница не достигает определенных показателей, прежде чем они станут проблемой.
