Время от времени плоды инноваций приносят свои плоды в виде улучшений основополагающих слоев сети. В 2015 году HTTP / 2 стал опубликованным стандартом в попытке обновить протокол устаревания. Это было как необходимо, так и давно, так как HTTP / 1 отображал производительность сети как загадочную дисциплину в виде странного обхода ограничений. Хотя распространение HTTP / 2 не является абсолютным — и есть еще какие-то изюминки, которые еще предстоит решить — я не думаю, что будет слишком сложно сказать, что сеть лучше из-за этого.
К сожалению, развертывание HTTP / 2 привело к увеличению среднего числа байтов, передаваемых по мобильному телефону, на 102% за последние четыре года. Если мы посмотрим на 90 -й процентиль того же набора данных — потому что это действительно длинный хвост производительности, для которого нам нужно оптимизировать, — мы увидим увеличение на 239% . С 2016 года (предупреждение в формате PDF) до 2019 года средняя скорость мобильной загрузки в США увеличилась на 73%. В Бразилии и Индии средняя скорость загрузки с мобильных устройств увеличилась на 75% и 28%, соответственно, за тот же период времени.
Хотя один только вес страницы не обязательно рассказывает всю историю взаимодействия с пользователем, это, по меньшей мере, очень слабо связанный феномен, который угрожает коллективному опыту пользователя , Историю, которую HTTPArchive рассказывает через данные, полученные из Chrome User Experience Export (CrUX), можно интерпретировать множеством разных способов, но этот факт является стойким и неумолимым: большинство метрик, полученных из CrUX за последние пару лет, показывают мало, если любое улучшение, несмотря на различные улучшения в браузерах, протоколе HTTP и самой сети.
Учитывая эти тенденции, все, что можно сказать о влиянии этих улучшений на данный момент, заключается в том, что оно помогло остановить волну наших излишеств, но очень мало, чтобы уменьшить их. Несмотря на все существенные улучшения, лежащие в основе Интернета и сетей, через которые мы к нему обращаемся, мы продолжаем развивать его таким образом, чтобы предполагать, что мы удовлетворены бесконечным парадоксом Джевонса, в котором мы трудимся.
Если мы хотим добиться прогресса в создании более быстрой сети для всех, мы должны признать некоторые препятствия для достижения этой цели:
- Непрекращающееся желание монетизировать каждый квадратный дюйм сети, а также армию сторонних поставщиков, которые подпитывают исследования, проводимые такими лихорадочными усилиями.
- Культуры на рабочем месте которые поддерживают неограниченное развитие, основанное на особенностях. Эта практика добавляет — но редко отнимает — то, что мы связываем с пользователями.
- Удобства разработчика которые облегчают работу разработчика, но могут привести к увеличению затрат на клиент.
Неудобно, владельцы зрелых кодовых баз, которые воплощают некоторые или все эти черты, продолжают идти по тому же неустойчивому пути к прибыльности, что и всегда. Они делают это на свой страх и риск, вместо того, чтобы признать неоднократно установленный факт, что методы разработки, ориентированные на производительность, сделают столько же — или больше — для их итоговой прибыли и опыта пользователя.
Именно с этим пониманием я пришел к выводу, что наш нынешний подход к исправлению низкой производительности в основном состоит из технических приемов, которые проистекают из вредных последствий нашего бизнеса, управления продукцией и инженерных практик. Мы хороши в применении турникетов, но не так хороши в зашивании глубоких ран.
Становится все более очевидным, что производительность сети — это не просто инженерная проблема, а проблема людей . Это непривлекательная оценка отчасти потому, что технические решения сравнительно неоспоримы. Сжатие контента работает. Минификация работ. Встряхивание деревьев работает. Разделение кода работает . Они, несомненно, эффективные решения, что может показаться, что полностью технические проблемы.
С другой стороны, пересечение веб-производительности и людей беспорядочно и неудобно. В отличие от технического решения, столь же выгодного, как HTTP / 2, как мы можем определить, как выглядят успешные культуры производительности? Как мы квалифицируем успешные подходы, чтобы туда попасть? Я не знаю точно как это выглядит, но я считаю, что хорошим шаблоном является следующий брак культурных и инженерных принципов:
- Организация не может быть успешной в расстановке приоритетов производительности, если она не может обеспечить поддержку своих лидеров . Без этого важного элемента организациям становится чрезвычайно трудно создать культуру, в которой производительность является основной характеристикой их продукта.
- Даже при поддержке руководства эффективность не может быть эффективно расставлена по приоритетам, если телеметрия не на месте, чтобы измерить это. Без измерения невозможно объяснить, как разработка продукта влияет на производительность. Если у вас нет цифр, никто не будет заботиться о производительности, пока она не станет очевидным кризисом.
- Когда у вас есть поддержка руководства, чтобы сделать производительность приоритетной и телеметрия в место, чтобы измерить его, вы до сих пор не сможете добраться до тех пор, пока вся ваша организация не поймет производительность сети. Это время, когда вы разрабатываете и внедряете обучение, документацию, лучшие практики и стандарты, которые может принять организация. В некотором смысле это пространство, в котором организации уже потратили много времени, но сложной задачей является создание петель обратной связи для оценки того, насколько хорошо они понимают и применяют эти знания.
- Когда все другие части, наконец, на месте, вы можете начать создавать подотчетность в организации в отношении производительности. Подотчетность приходит не в форме репрессий, когда ваша телеметрия сообщает вам, что производительность снизилась с течением времени, а в виде ограждений, установленных в процессе развертывания, чтобы предупредить вас, когда пороги будут преодолены.
Теперь придет кикер: даже если все эти вещи собираются вместе на вашем рабочем месте, хорошие результаты не гарантированы. Запрет на какое-то регулирование, которое вынуждает нас обращаться к плохо работающим веб-сайтам, за которые мы отвечаем — подобно тому, как ADA держит нас в тонусе в отношении доступности, — нам потребуется постоянное благовестие и давление, чтобы обеспечить эффективность a приоритет. Как и большая часть работы, которую мы выполняем в Интернете, работа по поддержанию хорошего пользовательского опыта в развитии кодовых баз никогда не выполняется. Я надеюсь, что 2020 год — это год, в котором мы осознанно признаем, что эффективность работы связана с людьми, и соответствующим образом адаптируемся.
По мере появления технологических новшеств, таких как HTTP / 3 и 5G, мы должны позаботиться о том, чтобы не почивать на лаврах, и просто предположить, что они излечат наши беды раз и навсегда. Если мы это сделаем, у нас наверняка снова возникнет эта дискуссия, когда появятся преемники этих технологий. Одни только инновации не могут поддерживать работу в Интернете, потому что создание сети быстро — и сохранение таким образом — это тяжелая работа, которую мы можем выполнить, только работая вместе.
Загрузка...
