[Перевод] 2Mb веб страницы — кого винить?
Я надеялся что это было временно. Я надеялся что 2015 год будет годом производительности. Я ошибался. Средний вес веб-страницы возрос на 7.5% за пять месяцев, превысив 2Mb. Для этого же потребуется три 3.5-дюймовые дискеты двойной плотности!
Согласно отчёту на HTTP Archive за 15 мая 2015 статистика, собранная на почти половине миллиона веб-страниц такова:
| технология | конец 2014 | май 2015 | увеличение |
|---|---|---|---|
| HTML | 59Kb | 56Kb | -5% |
| CSS | 57Kb | 63Kb | +11% |
| JavaScript | 295Kb | 329Kb | +12% |
| изображения | 1,243Kb | 1,310Kb | +5% |
| Flash | 76Kb | 90Kb | +18% |
| другое | 223Kb | 251Kb | +13% |
| всего | 1,953Kb | 2,099Kb | +7.5% |
Наибольший рост наблюдается среди CSS, JavaScript, других файлов (в основном шрифты) и неожиданно у Flash. Среднее число запросов на страницу:
- 100 файлов в общем (было 95)
- 7 файлов со стилями (было 6)
- 20 JavaScript файлов (было 18)
- 3 файла со шрифтами (было 2)
Изображения остаются наибольшей проблемой, насчитывая 56 запросов и составляя 62% от общего веса страницы.
И, в конце-концов помните, что это среднестатистические данные. Многие сайты весят значительно больше.
Немного театрально, но всё-таки есть хоть кто-то, кто сочтёт 2Mb приемлемыми? Это сайты публичного просмотра — никаких action игр или тяжеловесных приложений. На некоторых может применяться клиентский фреймворк, который может придать больший вид 'отдельной' странице, но таких сайтов должно быть меньшинство.
Ситуация складывается в ещё худшую сторону для трети пользователей с мобильными устройствами. Иронично, но 2Мб отзывчивый сайт никогда не будет рассматриваться как отзывчивый на более медленном устройстве с ограниченным и, возможно, дорогим мобильным соединением.
В прошлом я обвинял разработчиков, хотя существуют несколько технических оправданий против уменьшения веса страницы. Сегодня я обращаю внимание на клиентов: они делают веб слишком сложным.
Мои клиенты хотят проектировать ПО и разрабатывать представления (views), поскольку хотят реализовать своё собственное видение. У них есть новаторские идеи, на которых можно заработать миллионы — как только каждая из 1001й «жизненно важной» фичи будет реализована в коде. И не важно насколько велик проект, клиент всегда хочет большего. Они:
- ошибочно полагают, что большее кол-во функциональности привлечёт больше клиентов
- заставляют своего разработчика лучше оправдывать денежные затраты
- ничего лучшего придумать не могут
Стратегии, основанные на функциональных возможностях, такие как «выпускай раньше, выпускай чаще» трактуются неверно или вовсе отклоняются.
Каков результат? 2Мб страницы, наполненные неуместным хламом, большим количеством рекламы, навязчивыми виджетами социальных медиа, некачественными реализациями нативных интерфейсов, а также всплывающие окна, которые невозможно закрыть на малых экранах.
Но мы уступаем требованиям клиентов.
Даже если вы не уступаете, то большинство разработчиков уступает — и это вредит всем.
Мы продолжаем отдавать предпочтение функциональным возможностям вместо производительности. Добавить какую-нибудь ерунду несложно и это делает клиента счастливым. Но пользователям не нравится взаимодействовать с web; они жаждут родных мобильных приложений и Мгновенных Статей Facebook. Более того, разработчики знают что это не правильно: Веб против родных приложений: давайте признаем поражение.
Трудно спорить с клиентом, который предлагает плату за ещё один набор бестолковых фич. Клиенты больше фокусируются на своих нуждах, нежели на нуждах своих пользователей. Большее количество рекламы на странице даёт больше доходов. Демонстрация навязчивых pop-up даёт большее количество регистраций. Лучше презентовать 20 продуктов чем 10. Эти методы работают до определённого момента, но как только вы перейдёте черту приемлемости, пользователи покинут сайт. Что инстинктивно делают клиенты при падении доходов? Они добавляют больше всякой всячины.
Создание опыта взаимодействия для несведущего пользователя вместе с улучшенной производительностью всегда уходят на последний план. Возможно, вы бы могли выдвинуть это на первый план, обсудив следующие два подхода к созданию опыта взаимодействия…
Исторически Microsoft разрабатывал ПО при помощи комитета. Множество людей высказывали множество мнений по поводу функциональных возможностей. Плюсы: ПО Microsoft предоставляет каждую мыслимую возможность и весьма хорошо конфигурируемо. Минусы: люди используют лишь часть этой мощи, к тому же это может стать слишком сложно — например, семнадцать способов выключения в Vsita или малопонятное диалоговое окно с опциями Интернета.
У Apple более диктаторский подход, в котором решение принимает относительно небольшое количество человек. Интерфейсы изящны и минималистичны, они содержат лишь те возможности, которые считаются полностью необходимыми. Плюсы: ПО от Apple может считаться простым и элегантным. Минусы: попробуйте убедить Apple добавить определённую фичу, которая вам нужна, желаю удачи.
Ни один из подходов не является полностью ошибочным, однако какая из компаний добилась больших успехов за последние годы? Большинство пользователей ищет простого опыта взаимодействия: приложения должны работать для них — и никаким другим образом. Побеждает простота.
Спросите у своих клиентов какой компанией они хотели бы стать. Затем предложите улучшить продукт, с ориентировкой на частые нужды пользователей, избавлением от редко используемых функциональных возможностей и с приоритетом производительности.
Веб удивителен. Приложения кроссплатформенны, работают в любой точке мира, не требуют инсталляции, автоматически бекапируют данные и позволяют быстро приступить к совместной работе. Объём данных этих страниц уже стал больше и тяжелее чем родные установщики приложений, которые они призваны заменить. 2Мб веб-страницы пересекли грань приемлемости.
Если мы ничего не сделаем, то кризис избыточности будет длиться и дальше. Бороться за простоту нелегко: снизить весь гораздо тяжелее чем его приобрести. Выдержите небольшую боль и вы обретёте здоровое будущее:
- используйте инструменты, содействующие кешированию, сократите HTTP запросы, минимизируйте полезный объём данных и уберите ненужные компоненты — см. Подробное руководство по сокращению веса страницы
- подумайте над идеей Криса Раппела о медленных четвергах, когда ограничивается пропускная способность и вы работаете со своим сайтом/приложением в таких же условиях как и ваши пользователи
Настало время отдать приоритет производительности.
