Влияние удаления jQuery на производительность нашего веб-сайта
В первом сообщении в блоге мы рассмотрели «Как и почему мы удалили jQuery из GOV.UK», а теперь давайте обратим внимание на то, как это повлияло на производительность для пользователей. Прочтите эту запись в блоге перед этой.
Данные изображения по сравнению со сжатыми данными
Как упоминалось ранее, библиотека jQuery была 9Только 0011 32 КБ сжатого и минимизированного (когда из кода удалены пробелы и заменены повторяющиеся слова) JavaScript. Теперь я знаю, что вы можете подумать: это не похоже на много данных, особенно по сравнению с изображениями, которые могут иметь размер в несколько мегабайт. Но когда он есть на каждой странице, с точки зрения веб-производительности это означает большой объем данных. Также стоит упомянуть, что существует большая разница между данными изображения и сжатыми данными JavaScript. Браузеры и устройства по-разному обрабатывают эти два типа данных.
JavaScript известен как ресурс, блокирующий рендеринг.
Это означает, что когда браузер сталкивается с JavaScript, он проходит через многоэтапный процесс, который включает загрузку, затем распаковку, прежде чем он будет окончательно проанализирован и выполнен. Все это происходит в доступном центральном процессоре (ЦП) и памяти устройства. Эти задачи могут быть очень медленными и энергоемкими в зависимости от устройства и соединения.
К сожалению, в это время собственно отрисовку пикселей на экран устройства приходится приостанавливать до завершения выполнения JavaScript. По завершении браузер может продолжить рисовать пиксели для остальной части страницы.
Изображения и данные изображений не блокируют рендеринг, то есть части веб-страницы могут быть перерисованы на странице, в то время как дополнительные данные изображений загружаются параллельно. Таким образом, изображение размером 32 КБ оказывает гораздо меньшее влияние на производительность, чем 32 КБ сжатого кода JavaScript. Это особенно актуально для пользователей устройств с низкими характеристиками, которые, как правило, медленнее, старше и дешевле.
Мы сосредоточимся на этих пользователях в оставшейся части сообщения в блоге.
Помощь пользователям с устройствами с низкими характеристиками
Устройства с более низкими характеристиками часто считаются старыми ноутбуками и планшетами или «бюджетными» мобильными устройствами (часто устройствами Android с ограниченным тарифным планом).
Поскольку у этих пользователей самые медленные устройства, им потребуется максимальная помощь, чтобы их посещение GOV.UK было максимально быстрым, эффективным и дешевым. В октябре прошлого года, по оценкам Ofcom, 2 миллиона домохозяйств «испытывали проблемы с доступностью фиксированного широкополосного доступа и/или смартфона», поэтому наша работа здесь может снизить их расходы на Интернет.
На этом этапе стоит упомянуть, что анонимные данные Real User Monitoring (RUM), которые мы собираем с пользовательских устройств, показывают, что GOV.UK уже является очень быстрым веб-сайтом. Для большинства пользователей сайт загружается менее чем за 1 секунду.
Но график распределения (см. выше) также показывает, что некоторые пользователи видят время загрузки страницы до 2,35 секунды. Более внимательно изучив данные о производительности RUM для этих пользователей, мы увидим:
- 75% пользователей находятся в Великобритании
- 35% пользователей используют Android-устройства
- для отображения первых пикселей страницы на их экранах требуется почти 2 секунды (это называется метрикой начала рендеринга)
Исходя из приведенной выше статистики, мы можем предположить, что многие из этих пользователей Android используют устройства с низкими характеристиками, где скорость процессора и объем памяти ограничены.
Учитывая это предположение, какое влияние на производительность окажет удаление 32 КБ сжатого кода JavaScript?
Тестирование влияния
Именно здесь наши «лабораторные» тесты производительности очень полезны. Мы проводим тесты каждый день на страницах GOV.UK, используя определенные смоделированные устройства и скорости соединения.
Поскольку мы можем повторять эти тесты каждый день, это позволяет нам отслеживать, как изменения, которые мы вносим на сайт, влияют на реальных пользователей, посещающих GOV.UK.
Например, для смоделированного пользователя, посещающего стартовую страницу Universal Credit на устройстве с низкими характеристиками и мобильном соединении 2G, мы можем ясно увидеть на графике, где было сделано изменение jQuery.
Причина, по которой была выбрана страница Universal Credit, заключается в том, что это самая посещаемая страница на GOV.UK согласно нашим аналитическим данным, поэтому важно, чтобы она быстро загружалась для всех пользователей, независимо от того, какое устройство или подключение они используют. с использованием. Как видно из приведенного выше графика, время, необходимое странице для полного отображения пикселей на экране (визуальное завершение), сократилось с 11,3 секунды до 9,4 секунды (улучшение на 17%).
Помимо визуально полных улучшений, также были четко видны улучшения времени загрузки страницы.
На приведенном ниже графике показано, что время до полной загрузки страницы сократилось с 20,42 секунды до 18,75 секунды (улучшение на 8%), а общее время загрузки страницы сократилось с 19 секунд.с 0,44 секунды до 17,75 секунды (улучшение на 9%).
Наконец, мы также видим значительное улучшение показателей интерактивной производительности страницы, что означает, что пользователь может взаимодействовать со страницей намного раньше. Показатели интерактивности важны для пользователей, поскольку они показывают, когда пользователь может впервые взаимодействовать со страницей. Возможность взаимодействовать со страницей дает пользователям уверенность в том, что страница все еще работает.
График ниже показывает, что время до интерактивности сократилось с 11,34 до 9 секунд.0,43 секунды (улучшение на 17%), а время бездействия ЦП устройств First сократилось с 11,32 секунды до 9,42 секунды (улучшение на 17%).
Улучшение GOV.UK для всех
Повышение производительности Интернета часто состоит из множества небольших постепенных изменений с течением времени.