Средний размер веб-страниц увеличился на 32% в 2013 году

Данная статья является переводом поста Average Page Weights Increase by 32% in 2013 с сайта SitePoint. Мои комментарии выделены курсивом, а также вынесены в отдельные блоки с желтым фоном.

HTTP Archive опубликовал ежегодный отчёт, информация которого основывается на данных, полученных с 300 000 самых популярных веб-сайтов. Средний размер веб-страницы увеличился на 32% за год и достиг более 1700Кб (1,7Мб); теперь для загрузки страниц требуется в среднем 96 запросов HTTP. Это хуже, чем ситуация в 2012 году, когда средний размер страниц увеличился на 30%.

Частично это может быть объяснено тем, что электронной коммерции и рекламы стало больше, когда люди начали искать подарки (имеется ввиду, что в декабре люди готовились к Новому году). Однако страницы немногих веб-сайтов стали весить меньше в январе; более того, в основном они лишь набирали вес в течение года.

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

технология конец 2012 конец 2013 прирост
HTML 54Кб 57Кб +6%
CSS 35Кб 46Кб +31%
JavaScript 211Кб 276Кб +31%
Изображения 793Кб 1,030Кб +30%
Flash 92Кб 87Кб -5%
Прочее 101Кб 205Кб +103%
Всего 1,286Кб 1,701Кб +32%

Прирост HTML оказался незначительным, хотя и это довольно неожиданно, учитывая тенденцию к уменьшению количества контента и использованию более простого, "плоского" дизайна ("flat design" в английском варианте). 57Кб - это достаточно много для одного только контента.

Размер таблиц стилей CSS в среднем увеличился на 11Кб. Кто-то может объяснить это использованием респонсивного веб-дизайна и эффектами CSS3, но разве не помогло снижение количества требуемых вендорных префиксов?

Респонсивный дизайн (responsive design) означает то, что с веб-сайтом будет удобно работать на различных устройствах с разными размерами дисплея. Если лет 10 назад ещё частенько встречались сайты, которые были оптимизированы под конкретное разрешение экрана (обычно 1024x768) и иногда под определённый браузер, а о мобильных устройствах, естественно, никто не думал, потому что смартфонов, фактически, не было, то сейчас такой подход неприемлем. Люди всё чаще заходят на веб-ресурсы со своих мобильных устройств, с планшетов, с небольших ноутбуков, то есть просматривают страницы на маленьких дисплеях. Если не позаботиться о том, чтобы дизайн веб-сайта был респонсивный (то есть его элементы правильно перестраивались в зависимости от размера экрана; кроме того, может изменяться размер шрифта, изображений; некоторые элементы могут быть вовсе скрыты и т.д.), то удобство его использования с точки зрения пользователя снижается. Однако респонсивный дизайн требует дополнительной работы от разработчика: необходимо написать отдельные стили, которые будут применяться только при определённых условиях (самое простое - если ширина экрана не более заданной величины). Это приводит к тому, что размер файлов со стилями CSS будет увеличиваться, о чём и говорит автор статьи.

Вендорные префиксы (vendor prefixes; "vendor" означает "разработчик") используются при записи некоторых экспериментальных свойств CSS, которые поддерживаются не во всех браузерах и которые не были стандартизованы. Например, запись -moz-border-radius: 5px; говорит о том, что для некоего элемента мы задаём радиус скругления его углов в 5px и работать это будет только в Firefox (Mozilla). Аналогично, -ms-border-radius: 5px; значит тоже самое, но для Internet Explorer (Microsoft). Такие экспериментальные свойства могут долгое время поддерживаться только одним-двумя браузерами, а могут быть и вовсе убраны и изменены со временем. Использование вендорных префиксов приводит к тому, что для описания одного свойства в разных браузерах требуется громоздкая конструкция вот такого рода:

.my_element {
   background-image: -webkit-linear-gradient(#fff, #000);
   background-image: -moz-linear-gradient(#fff, #000);
   background-image: -ms-linear-gradient(#fff, #000);
   background-image: -o-linear-gradient(#fff, #000);
   background-image: linear-gradient(#fff, #000);
}

Здесь мы просто задаём градиентную заливку для фона. Соответственно, из-за этого размер файлов со стилями CSS растёт. Однако даже если использовать вендорный префикс для какого-то свойства более не требуется, код, подобный указанному выше, всё равно будет работать, то есть разработчикам нет нужды возвращаться к своим стилям и их поправлять. А учитывая то, что многие разработчики не очень любят держать свой код "в форме", есть подозрение, что немногие удалили ненужные более вендорные префиксы. Кроме того, многие оставляют подобные инструкции CSS просто "на всякий случай", а в худшем случае - просто потому, что так было в книге по CSS (примере в Интернете или на другом сайте), то есть "культ карго". Другая причина - разработчик более не имеет отношения к созданному когда-то им сайту. То есть он в качестве фрилансера сделал сайт для клиента, и дальнейшей поддержкой не занимается. Поэтому аргумент автора статьи о том, что снижение количества требуемых вендорных префиксов должно было привести к снижению размеров файлов со стилями CSS, представляется достаточно слабым.

Однако подобный прирост размера HTML и CSS может быть нивелирован уменьшением объёма кода JavaScript. Стало меньше причин использовать объёмные библиотеки JS, ведь всё больше свойств CSS поддерживается во всех современных браузерах; кроме того, в CSS3 появилась возможность анимировать элементы. Однако этого не случилось и веб-страницы подгружают в среднем 18 файлов JS; сжатие кода JavaScript и объединение файлов сильно поправило бы положение.

Неудивительно, что размер Flash в среднем уменьшился на несколько килобайт; процент страниц, использующих данную технологию, упал с 37% до 32%. В основном Flash используется в рекламе, но появляются также альтернативы, использующие HTML5.

Размер "прочих" файлов увеличился вдвое. Треть этого прироста может быть атрибутирована файлам со шрифтами и иконками, и такая ситуация вполне приемлема, если это уменьшит размер и количество используемых изображений... но этого не произошло. Возможно, использование фотографий с большой плотностью пикселов (которые ориентированы на дисплеи Retina - обычные фотографии на них выглядят расплывчато; большая плотность пикселов означает больший размер файла с изображением) может частично объяснить это явление, но кто загружает по мегабиту изображений на каждой странице?

Эти данные шокируют ещё больше тогда, когда ты понимаешь, что они усреднены. То есть примерно половина проанализированных страниц веб-сайтов ещё более объёмная. Мы, веб-разработчики, должны со стыда взяться за голову.

Причины

Кого нам винить? Мои основные догадки:

  • Объёмные шаблоны для CMS. Стандартная тема для WordPress переполнена различными функциями. Во многом она может состоять из сторонних стилей и виджетов, которые автор добавил, чтобы сделать тему более полезной и привлекательной для покупателей. Многие функции не будут использоваться, но файлы всё равно останутся.
  • Использование шаблонов HTML5 Boilerplate. Шаблоны HTML5 Boilerplate могут сэкономить время, но важно понимать, что они предоставляют лишь основу. Стили и скрипты могут содержать функции, которые вы никогда не будете использовать, а разметка HTML может быть сложной, со множеством вложенных элементов и длинными названиями классов. Немногие разработчики заботятся о том, чтобы убрать лишний код.
  • Безразличие. Разработчики по своей сути ленивы (вот именно - про это я и говорил, когда комментировал ситуацию с вендорными префиксами); мы пишем программы, чтобы сделать решение определённых задач проще. Однако если вы не задумываетесь о негативных последствиях увеличения размеров веб-страниц, у вас следует отозвать лицензию.

Сюда также можно дописать: использование фреймворков CSS (Twitter Bootstrap, Zurb Foundation и проч.). В них также входит очень много функций, из которых используется в лучшем случае треть (ситуация улучшается, если перед загрузкой файлов фреймворка разработчик выбирает, какие компоненты ему нужны).

Если даже мы забудем о поисковой оптимизации веб-страниц, эффективности программного обеспечения и времени отклика для пользователей, надо понимать, что каждый пятый визит веб-страницы осуществляется с телефона. На самой эффективной мобильной сети страница весом 1.7Мб будет загружаться минуту - если устройство рендерит элементы достаточно быстро. Будет ли готов потенциальный посетитель ждать столько времени?

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

Я в ужасе. Надо сказать, что я начинал разработку во времена диал-апа, когда размер веб-страницы в 100Кб считался чрезмерным, но действительно ли современные веб-страницы в 17 раз лучше тех, чтобы были тогда?

Будет ли уменьшаться средний размер страниц? Страдает ли ваш сайт "ожирением"? И как он дошёл до такого состояния?

Follow me on Twitter to get updates about new articles >>

Comments

Please authorize via one of the following social networks to leave a comment: