Как улучшение производительности веб-сайта может помочь спасти планету

Вы можете не часто об этом задумываться, но интернет потребляет колоссальное количество электроэнергии. Это электричество нужно где-то производить. В большинстве стран это означает сжигание ископаемого топлива. Это, в свою очередь, означает, что углеродный след Интернета вырос до такой степени, что он, возможно, затмил глобальные авиаперевозки, и это делает Интернет крупнейшей угольной машиной на Земле.

В отчете Mozilla Internet Health Report 2018 говорится, что — особенно по мере того, как Интернет расширяется на новую территорию — «устойчивое развитие должно быть более важным приоритетом». Но в нынешнем виде веб-сайты становятся все более тучными, а это означает, что потребность Интернета в энергии продолжает расти в геометрической прогрессии.

В то же время последствия изменения климата с каждым годом становятся все более серьезными и многочисленными. Подавляющее большинство ученых-климатологов связывают растущую жестокость и частоту экстремальных погодных явлений во всем мире с изменением климата, которое они в значительной степени связывают с деятельностью человека. В то время как некоторые ставят науку под сомнение, даже крупнейшие нефтяные компании мира теперь принимают ее и признают, что их бизнес-модели должны измениться.

Каждая страна на Земле (за исключением США) подписала Парижское соглашение по климату. Хотя США вышли из соглашения, многие из самых влиятельных лиц, городов, штатов и компаний Америки, представляющие более половины населения и экономики США, сохранили свою приверженность соглашению посредством инициативы America's Pledge.

Как веб-разработчикам понятно, что мы не имеем никакого влияния на этот вопрос, но это не так. Предпринимаются многочисленные попытки улучшить ситуацию в Интернете. Green Web Foundation поддерживает постоянно растущую базу данных веб-хостингов, которые либо полностью питаются от возобновляемых источников энергии, либо, по крайней мере, привержены нейтральному выбросу углерода. В 2013 году A List Apart опубликовал книгу Джеймса Кристи «Устойчивый веб-дизайн». В течение последних трех лет на конференции SustainableUX присутствовали эксперты в области устойчивого развития сети, которые делились своими знаниями по целому ряду веб-дисциплин.

С 2009 года Гринпис оказывает давление на крупные интернет-компании, чтобы они очистили свой энергетический баланс посредством своей кампании Clicking Clean. Частично в результате этой кампании Google объявил в прошлом году, что впервые закупил достаточно возобновляемой энергии, чтобы обеспечить 100% своего глобального потребления для операций.

Итак, помимо питания серверов возобновляемой энергией, что еще могут сделать веб-разработчики в связи с изменением климата?

«Нельзя управлять тем, что нельзя измерить»

Возможно, самая большая победа, когда дело доходит до повышения устойчивости веб-сайтов, заключается в том, что производительность, пользовательский опыт и устойчивость тесно переплетены. Ключевым показателем для измерения устойчивости цифрового продукта является его энергопотребление. Это включает в себя работу, выполняемую сервером, клиентом и промежуточными коммуникационными сетями, которые передают данные между ними.

Имея это в виду, возможно, первое, что нужно рассмотреть, это то, как мы измеряем энергопотребление нашего веб-сайта? На самом деле это более сложная задача, чем вы можете себе представить, и здесь трудно получить точные данные. Однако есть несколько хороших запасных вариантов, которые мы можем использовать, чтобы продемонстрировать использование энергии. К ним относятся передача данных (т. е. сколько данных браузер должен загрузить для отображения вашего веб-сайта) и использование ресурсов оборудования, обслуживающего и принимающего веб-сайт. Очевидной метрикой здесь является использование ЦП, но использование памяти и другие формы хранения данных также играют свою роль.

Передача данных — это то, что мы можем довольно легко измерить. Все основные браузеры предоставляют инструменты для разработчиков, которые позволяют нам измерять сетевую активность. Например, на этом снимке экрана ниже мы видим, что загрузка веб-сайта Smashing Magazine в первый раз требует передачи чуть менее мегабайта данных. Инструменты разработчика Firefox фактически предоставляют нам два числа: первое — это несжатый размер переданных файлов, а второе — сжатый размер.

Наиболее распространенным инструментом для сжатия ресурсов при их перемещении по сети является gzip, поэтому разница между этими двумя числами обычно является результатом работы gzip. Это последнее число показывает, сколько данных было фактически передано, и за ним нужно следить.

Примечание . Существует множество других инструментов, которые предоставляют нам метрику для передачи данных, включая очень почитаемый WebPagetest.

Для измерения использования ЦП Chrome предоставляет нам детальный диспетчер задач, который показывает объем памяти, использование ЦП и сетевую активность отдельных вкладок. Для более предприимчивых/технических пользователей команда top (таблица процессов) предоставляет аналогичные показатели для большинства Unix-подобных операционных систем, таких как macOS и Ubuntu. Вообще говоря, мы также можем запустить команду top на любом сервере, к которому у нас есть доступ к оболочке.

К счастью, существуют такие проекты, как WebsiteCarbon и Ecograder, которые пытаются преобразовать эти показатели в конкретный показатель CO2 (в случае WebsiteCarbon) или оценку (в случае Ecograder).

Устойчивый веб-дизайн

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

Есть некоторые существующие работы, которые мы можем использовать, чтобы помочь нам здесь. В 2016 году O'Reilly опубликовала книгу Тима Фрика «Дизайн для устойчивого развития». В этой книге Тим расскажет нам о том, почему и как возникает устойчивый дизайн. Но мы также можем опираться на множество существующих идей, докладов на конференциях и статей, которые, хотя и не уделяют явного внимания устойчивому развитию, имеют огромное совпадение с философией устойчивого веб-дизайна. Особенно хорошими примерами здесь являются побочный проект Брэда Фроста «Death To Bullshit», статьи и рассказы Хейдона Пикеринга о том, как писать меньше чертового кода, а также запись в блоге Адама Сильвера «Проектирование для реальной производительности».

Если мы делаем полный редизайн веб-сайта или начинаем новый с нуля, мы можем начать с некоторых вопросов действительно высокого уровня здесь. Например, что на самом деле заслуживает или должно быть на главной странице? А точнее, какую ценность приносит каждый элемент на главной странице? Как говорит Хейдон Пикеринг:

«Самая производительная, доступная и простая в обслуживании функция веб-сайта — это та, которую вы не делаете изначально».

Я работаю в VIP-команде WordPress.com, поэтому в этом ключе я решил бросить себе вызов, создав минималистскую тему WordPress, чтобы увидеть, насколько далеко я могу продвинуться в методах устойчивого веб-дизайна. Результатом стала тема под названием Susty, и ее можно увидеть в действии на сопутствующем веб-сайте, который я создал: sustywp.com. В этом конкретном примере веб-сайт доставляется с передачей данных чуть более 6 КБ, что хорошо, учитывая, что средний размер веб-сайта составляет около 1,5 МБ.

Итак, что я сделал? Хорошо, я скажу вам.

Сокращение сетевых запросов

Как я уже говорил выше, сетевые запросы — это то, что мы можем легко измерить, поэтому они являются хорошей отправной точкой. Собирая Susty, я заметил, что было несколько HTTP-запросов, которые не казались необходимыми. Например, WordPress объединяет некоторые CSS и JavaScript, которые обнаруживают использование смайликов и гарантируют, что они не будут отображаться как недопустимые символы. В этом нет ничего плохого по своей сути, но если вы не планируете использовать смайлики, или вы счастливы и уверены, что различные системные значения по умолчанию помогут вам, вы можете предотвратить их загрузку.

Это представляет собой относительно скудную экономию, но, установив философию удаления нежелательного кода и запросов с наших страниц, мы можем добиться гораздо более значительных улучшений производительности. Например:

• Мы загружаем весь jQuery для некоторых основных операций DOM?
  Можем ли мы достичь тех же целей с помощью чистого JavaScript? Вы можете прочитать о более продвинутом устранении мертвого кода (также известном как встряхивание дерева) в этом посте Джереми Вагнера для Google.
• У нас есть карусель изображений?
  Нам действительно нужны все эти изображения? Значительно ли они улучшают пользовательский опыт? Или мы могли бы сократить его до одного сильного изображения? Или даже случайным образом показывать одно из выбранных изображений, чтобы придать чувство динамизма вернувшимся пользователям? Кстати, проведенное здесь исследование показывает, что большинству пользователей карусели не нравятся и не интересны.
• Если мы используем много изображений, выиграем ли мы от предоставления наших изображений в формате WebP для тех браузеров, которые его поддерживают?
  Долгое время поддержка WebP была разочаровывающе ограниченной. Но с учетом того, что Firefox должен начать поддерживать его в версии 65 (ожидается в январе 2019 года), это только вопрос времени, когда оставшиеся отставшие, такие как Safari, наверстают упущенное.
• Мы загружаем сотни килобайт веб-шрифтов?
  Используем ли мы все загружаемые веб-шрифты? Нужны ли нам вообще веб-шрифты? Большинство устройств в наши дни имеют стек полуприличных шрифтов, можем ли мы просто указать список шрифтов, которые мы хотели бы видеть, упорядоченными по предпочтениям? Если мы должны использовать веб-шрифты, мы должны убедиться, что наши шрифты настолько эффективны, насколько это возможно.
• Встраиваем ли мы видео с YouTube?
  Встроенное видео YouTube обычно добавляет около мегабайта передаваемых данных, прежде чем кто-либо даже взаимодействует с ним. Если только небольшая часть наших пользователей на самом деле собирается сидеть и смотреть встроенное видео на нашем веб-сайте, можем ли мы вместо этого просто дать ссылку на него?

Тщательно все

В этом ключе мы также можем исследовать каждый аспект наших страниц. Что действительно заслуживает того, чтобы быть там? Добавляет ли наша боковая панель какую-либо реальную ценность, или мы просто поместили ее туда, потому что соглашение диктует, что веб-сайты должны иметь боковые панели? Итак, мы добавили один и заполнили его дерьмом.

С Susty я экспериментировал с несколько неортодоксальным подходом к размещению навигации на отдельной странице. Это позволяет мне иметь страницы, которые буквально урезаны до самого необходимого, а дополнительный контент загружается только по явному запросу пользователя. Susty настолько легкий и быстрый, что благодаря некоторым исследованиям пользователей (он же мой партнер) я понял, что загрузка меню на самом деле не похожа на новую страницу, поэтому я решил сделать ее похожей на наложение с крестом на уволить, что на самом деле просто возвращает вас на предыдущую страницу.

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

Пишите CSS как ваша бабушка

Когда дело доходит до серьезного повышения производительности, мы должны помнить, что важен буквально каждый символ кода. Каждый символ представляет собой байт, и даже после того, как они были сжаты с помощью gzip, они все еще имеют вес. CSS — это область, в которой мы часто видим много раздувания. К счастью, растет число все более сложных инструментов, которые могут помочь вам отсеять неиспользуемый CSS. Этот фантастический пост от Сары Даян описывает, как она уменьшила свой пакет CSS с 259 КБ до 9 КБ!

Если мы начинаем с нуля, возможно, нам следует более глубоко подумать о том, как мы пишем CSS. Хейдон Пикеринг написал отличный пост о том, как мы можем писать CSS таким образом, чтобы использовать сильные стороны того, как был разработан синтаксис, и как это может помочь разработчикам предотвратить повторение. Хейдон также указывает, сколько потерь происходит при чрезмерном использовании div и классов — как в HTML, так и в CSS.

Что вы анализируете?

Похоже, что в Интернете стало более или менее повсеместным, чтобы каждый мог анализировать, что делают посетители своего веб-сайта, с помощью таких инструментов, как Google Analytics, KISSmetrics, Piwik и т. д. Хотя я не сомневаюсь, что существуют законные варианты использования, действительно ли мы нужна аналитика на каждом сайте? Я, например, обычно добавляю Google Analytics на каждый сайт, которым я управляю, как само собой разумеющееся. Но относительно недавно до меня дошло, что для большинства рассматриваемых веб-сайтов это было почти совершенно бессмысленным занятием: «О, шесть человек пришли сегодня на этот пост через Facebook». Какая разница?

Если вам это действительно не нужно, и вы собираетесь анализировать и действовать на основе данных, просто откажитесь от аналитики и найдите лучший способ провести время, чем смотреть на обыденность того, сколько людей посетило сайт X сегодня.

Помимо увеличения веса вашей страницы, использование чего-то вроде Google Analytics поднимает этические вопросы в отношении данных, которые вы собираете о своих пользователях от имени Google, т.е. есть причина, по которой Google предоставляет вам Analytics бесплатно.

Не забываем об основах

В наши дни так много информации о следующем, но мы никогда не должны расслабляться и забывать о них. Наряду со всем вышеперечисленным, мы всегда должны минимизировать HTML, CSS и JavaScript и объединять их там, где это необходимо. Мы также должны сжимать все изображения, чтобы они были как можно меньше, использовать правильные форматы с правильными настройками и использовать прогрессивный рендеринг.

Производительность на стороне сервера

До сих пор наше внимание было почти полностью сосредоточено на внешнем интерфейсе, но многое из этого становится неактуальным, если мы также не оптимизируем вещи на стороне сервера. Я уже упоминал об этом пару раз, но мы всегда должны включать сжатие gzip.

Мы должны максимально упростить обслуживание нашего веб-сайта для нашего сервера. Я в основном использую Nginx, и мне особенно нравится кеш FastCGI, и я обнаружил, что он особенно эффективен. Если у вас есть доступ к собственному серверу через оболочку, вот пост, в котором объясняется, как его настроить. Есть меньше технических вариантов, если у вас нет (или вы не хотите) такого большого контроля над своим сервером. Особым фаворитом в пространстве WordPress является WP Super Cache.

Мы должны использовать HTTP2 вместо HTTPS. Использование HTTPS открывает целый мир новых веб-технологий, таких как сервис-воркеры, которые позволяют нам относиться к самой сети как к чему-то приятному. Если вы хотите узнать об этом больше, я настоятельно рекомендую новую книгу Джереми Кейта «Выход в офлайн».

Примечание . Вы также можете изучить модуль Google PageSpeed, доступный как для Apache, так и для Nginx.

Наконец, самое большое влияние, которое мы можем здесь оказать, — это размещение наших веб-сайтов в центрах обработки данных, работающих на возобновляемых источниках энергии. В Великобритании я очень рекомендую Krystal и Kualo как компании, в которых я напрямую размещаю свои сайты. (Полный каталог зеленых веб-хостов можно найти на The Green Web Foundation.)

В заключение

Надеюсь, я убедил вас, что стоит приложить усилия, чтобы сделать наши веб-сайты более устойчивыми. Тем более, что в процессе мы также делаем наши сайты:

• Более производительный,
• Более удобный,
• Более доступный,
• Более удобный для сервера,
• Лучше оптимизирован для поисковых систем.

Реакция некоторых людей на идею устойчивого веб-дизайна — что вполне разумно — заключается в том, что это кажется очень небольшой уступкой делу защиты окружающей среды. Конечно, степень влияния, которое вы можете оказать, зависит от того, насколько загружены веб-сайты, над которыми вы работаете. Но помимо того, что он помогает Интернету стать немного более экологичным, устойчивый веб-дизайн — это, по сути, лучшая практика веб-дизайна.

Также стоит подумать о компенсации выбросов углерода, которых вы не можете избежать. Углеродную компенсацию иногда высмеивают, и на то есть веские причины. Основная проблема с компенсацией заключается в том, что обычно срок, в течение которого будет компенсироваться углерод, довольно велик. Например, при посадке деревьев цифра, приводимая для количества связывания углерода, обычно основана на 100-летнем периоде. Итак, с точки зрения сокращения выбросов углерода сейчас это не совсем решение. Но это лучше, чем ничего.

Девиз myclimate — делать все возможное и компенсировать все остальное. Я написал сообщение в блоге о внедрении вашей собственной схемы компенсации выбросов углерода. Я также настоятельно рекомендую инициативу 1% For The Planet. Наконец, если вы являетесь владельцем бизнеса и хотели бы присоединиться к альянсу компаний, которые хотят добиться большей социальной, экологической и экономической справедливости, ознакомьтесь со схемой сертифицированной корпорации B.