К сожалению, веб-сайты не так безвредны для окружающей среды, как нам хотелось бы. Эта статья содержит некоторые мысли и опыт попыток их очистить.
Как и в случае со многими другими разработчиками, отчеты за последние несколько лет об огромных потребностях Интернета в энергии побудили меня взглянуть на мои собственные веб-сайты и посмотреть, что я могу сделать, чтобы минимизировать их влияние. В этой статье я расскажу о моем опыте в этой области, а также о моих текущих мыслях по поводу оптимизации веб-сайтов для сокращения выбросов углерода и некоторых практических примерах того, что вы можете сделать, чтобы улучшить свои собственные страницы.
Но сначала признание: когда я впервые услышал о воздействии веб-сайтов на окружающую среду, я не совсем поверил этому. В конце концов, цифровые технологии должны быть лучше для планеты, не так ли?
Я участвовал в различных экологических и экологических группах на протяжении десятилетий. За все это время я не могу сознательно припомнить, чтобы кто-нибудь когда-либо обсуждал возможное воздействие Интернета на окружающую среду . В центре внимания всегда было сокращение потребления и отказ от сжигания ископаемого топлива. Единственный раз, когда Интернет был упомянут как инструмент для общения друг с другом без необходимости рубить больше деревьев или для работы без поездок на работу.
Итак, когда люди впервые заговорили о выбросах углерода в Интернете, аналогичных выбросам в авиационной отрасли, я был настроен немного скептически.
Содержание статьи
Выбросы
Трудно представить себе огромную сеть оборудования, которая позволяет отправить запрос страницы на сервер, а затем получить ответ. Большинство из нас не живет в центрах обработки данных, и кабели, по которым передаются сигналы от одного компьютера к другому, часто проложены под нашими ногами. Когда вы не можете увидеть процесс в действии, все это может показаться немного волшебным — чему-то не способствует настойчивость некоторых компаний в добавлении таких слов, как «облако» и «безсерверный», в названия своих продуктов.
В результате мой взгляд на Интернет долгое время был немного эфемерным, своего рода миражом. Однако когда я начал писать эту статью, я провел небольшой мысленный эксперимент: Через сколько аппаратных средств проходит сигнал от компьютера, на котором я пишу, чтобы выйти из дома?
Ответ был шокирующим: 3 кабеля для кошек, коммутатор, 2 адаптера Powerline, маршрутизатор и модем, кабель RJ11 и несколько метров электропроводки. Внезапно этот мираж стал выглядеть более солидным.
Конечно, Интернет (любой, в более широком смысле, веб-сайты, которые мы делаем) действительно имеет углеродный след. Все серверы, маршрутизаторы, коммутаторы, модемы, ретрансляторы, телефонные шкафы, оптико-электрические преобразователи и спутниковые каналы связи Интернета должны быть построены из металлов, добытых с Земли, и из пластмасс, очищенных из сырой нефти. Чтобы затем предоставить данные примерно 20 миллиардам подключенных устройств по всему миру, им необходимо потреблять электроэнергию, которая также выделяет углерод при его генерации (даже возобновляемая электроэнергия не является углеродно-нейтральной, хотя она намного лучше, чем ископаемое топливо).
Точно измерить, что это за выбросы, вероятно, невозможно — каждое устройство отличается и энергия, которая питает их, может изменяться в течение дня — но мы можем получить приблизительное представление, посмотрев на типичные цифры по энергопотреблению, пользовательским базам и так далее. Одним из инструментов, который использует эти данные для оценки выбросов углерода на одной странице, является Калькулятор углерода веб-сайта. Согласно ему, средняя протестированная страница «производит 1,76 грамма CO2 на просмотр страницы».
Если вы привыкли думать о своей работе, как о безвредной для окружающей среды, это осознание может вас очень обескуражить. Хорошая новость в том, что мы, разработчики, можем очень многое с этим поделать.
Рекомендуемая литература : Как повышение производительности веб-сайта может помочь спасти планету
Производительность и выбросы
Если мы вспомним, что при просмотре веб-сайтов используется электричество, а при его производстве выделяется углерод, то мы будем знать, что выбросы страницы должны сильно зависеть от объема работы, которую сервер и клиент должны выполнить, чтобы отобразить страница. Кроме того, объем данных, необходимых для страницы, и сложность маршрута, по которому она должна пройти, будут определять количество углерода, выделяемого самой сетью.
Например, загрузка и рендеринг example.com, вероятно, будет потреблять гораздо меньше электроэнергии, чем домашняя страница Apple, а также будет намного быстрее. По сути, мы говорим, что высокая эмиссия и медленная загрузка страниц — это всего лишь два симптома одних и тех же основных причин.
Конечно, можно говорить об этой взаимосвязи теоретически, но было бы неплохо иметь некоторые реальные данные для их подтверждения. Для этого я решил провести небольшое исследование. Я написал простую программу с интерфейсом командной строки, чтобы взять список из 500 самых популярных веб-сайтов в Интернете, согласно MOZ, и сравнить их домашние страницы с помощью Google PageSpeed Insights и Website Carbon Calculator.
Время ожидания некоторых проверок истекло (часто из-за того, что рассматриваемая страница просто загружалась слишком долго), но в целом 14 июля 2021 года мне удалось собрать результаты для более чем 400 страниц. Вы можете загрузить сводку результатов по адресу проверьте себя, но для визуального представления я нанес их на диаграмму ниже:
Как видите, хотя различия между отдельными веб-сайтами очень велики, существует сильная тенденция к снижению выбросов от более быстрых страниц. Среднее значение выбросов для веб-сайтов с оценкой PageSpeed 100 составляет около 1 грамма углерода, что возрастает до прогнозируемых почти 6 граммов для веб-сайтов с оценкой 0. Я нахожу это немного обнадеживающим, несмотря на то, что существует множество веб-сайтов с очень низким скорости и высоких выбросов, большинство результатов сгруппированы в правом нижнем углу диаграммы.
Принятие мер
Как только мы понимаем, что большая часть эмиссии страниц происходит из-за низкой производительности, мы можем начать принимать меры по их снижению. Многие из факторов, влияющих на эмиссию веб-сайта, находятся вне нашего контроля как разработчиков. Мы не можем, например, выбирать устройства, с которых наши пользователи получают доступ к нашим страницам, или определять сетевую инфраструктуру, через которую проходят их запросы, но мы можем предпринять шаги для повышения производительности наших веб-сайтов.
Оптимизация производительности — это обширная тема, и многие из вас, читающих это, вероятно, имеют больше опыта, чем я, но я хотел бы вкратце упомянуть несколько вещей, которые я недавно наблюдал при оптимизации различных страниц » скорость погрузки и выбросы углерода.
На мобильных устройствах рендеринг выполняется намного медленнее
Недавно я переработал дизайн своего личного блога, чтобы сделать его немного более удобным для пользователей. Одно из моих хобби — фотография, и раньше на сайте было полноразмерное изображение заголовка.
Несмотря на то, что дизайн хорошо справлялся с демонстрацией моих фотографий, прокручивать прошлое было очень сложно, особенно при перемещении по страницам сообщений в блогах. Однако я не хотел терять ощущение фотографии в заголовке и в конце концов решил использовать ее в качестве фона для заголовка страницы.
Полноразмерный заголовок использовал srcset чтобы сделать загрузку как можно быстрее, но изображения все еще были очень большими на экранах с высоким разрешением, и мои самые длинные Время рисования контента (LCP) на мобильном устройстве для старого дизайна составляло почти 3 секунды. Большим преимуществом нового дизайна было то, что он позволил мне сделать изображения намного меньше, что сократило время LCP примерно до 1,5 секунды.
На ноутбуках и настольных компьютерах люди не заметили бы разницы, потому что обе версии были меньше секунды, но на гораздо менее мощных мобильных устройствах это было довольно драматично. Как это изменение повлияло на выбросы углерода? 0,31 грамма на просмотр до, 0,05 грамма после. Декодирование и рендеринг изображений являются очень ресурсоемкими и их количество растет экспоненциально по мере увеличения изображения.
Размер изображений — не единственное, что может повлиять на время декодирования; формат тоже важен. Google Lighthouse часто рекомендует предоставлять изображения в форматах следующего поколения, чтобы уменьшить объем данных, которые необходимо загружать, но новые форматы часто медленнее декодируются, особенно на мобильных устройствах. Отправка меньшего количества данных по сети лучше для окружающей среды, но возможно, что потребление большего количества энергии для декодирования может компенсировать это преимущество. Как и в большинстве случаев, здесь ключевым моментом является тестирование.
В ходе моего собственного тестирования при попытке добавить поддержку кодирования AVIF в генератор статических сайтов Zola я обнаружил, что кодирование AVIF, которое обещает гораздо меньшие размеры файлов, чем JPG, при том же качестве, потребовало на порядки больше времени для кодирования; что-то, что подтверждает наблюдение bunny.net о том, что WebP превосходит AVIF в 100 раз. При этом сервер будет потреблять электроэнергию, и мне интересно, действительно ли переход на новый формат для веб-сайтов с низким числом посетителей приведет к увеличению выбросов и снижению производительности.
Разумеется, изображения — не единственный компонент современных веб-страниц, обработка которых занимает много времени. Небольшие файлы JavaScript, в зависимости от того, что они делают, могут занимать много времени для выполнения и могут иметь те же потенциальные ловушки, что и изображения.
Рекомендуемая литература : The Humble img Element And Core Web Vitals
Суммарные поездки туда и обратно
Еще одна вещь, которая может оказать неожиданное влияние на производительность и выбросы, — это то, откуда берутся ваши данные. Традиционная мудрость давно гласит, что обслуживание таких активов, как фреймворки, из центральной сети доставки контента (CDN) повысит производительность, потому что получение данных с локальных узлов обычно происходит быстрее для пользователей, чем с центрального сервера. Например, jQuery имеет возможность загружаться из CDN, и его сопровождающие говорят, что это может улучшить производительность, но реальное тестирование, проведенное Гарри Робертсом, показало, что ресурсы с самостоятельным размещением обычно выполняются быстрее.
Это тоже был мой опыт. Недавно я помог игровому сайту улучшить его производительность. Веб-сайт использовал довольно большую структуру CSS и загружал все свои сторонние ресурсы через CDN. Мы перешли на самостоятельный хостинг всех ресурсов и удалили неиспользуемые компоненты из фреймворка.
Ни одна из оптимизаций не привела к каким-либо визуальным изменениям на веб-сайте, но вместе они увеличили оценку Lighthouse с 72 до 98 и снизили выбросы углерода с 0,26 грамма на просмотр до 0,15.
Отправляйте только то, что вам нужно
Это хорошо подводит нас к теме отправки пользователям только тех данных, которые им действительно нужны. Я работал (и посетил) на многих-многих веб-сайтах, на которых преобладают стоковые изображения людей в костюмах, улыбающихся друг другу. Похоже, некоторые организации считают, что то, что они делают, действительно скучно и что добавление фотографий каким-то образом убедит широкую публику в обратном.
Я могу отчасти понять, что за этим стоит, потому что есть множество статей о том, как количество времени, которое люди тратят на чтение, сокращается. Нам неоднократно говорят, что текст выходит из моды; все, что сейчас интересует людей, — это видео и интерактивные опыты.
С этой точки зрения стоковые фотографии можно рассматривать как полезный инструмент для оживления страниц, но исследования слежения за глазами показывают, что люди игнорируют изображения, которые не имеют отношения к делу. Когда люди не смотрят на ваши изображения, они могут быть пустым пространством. И когда каждый байт стоит денег, способствует изменению климата и замедляет время загрузки, для всех было бы лучше, если бы они действительно были такими.
Опять же, то, что можно сказать об изображениях, можно сказать и обо всем остальном, что не является основным содержанием страницы. Если что-то не способствует удобству работы пользователя значимым образом, этого не должно быть. Я ни на минуту не выступаю за то, чтобы мы все начали обслуживать нестилированные страницы — некоторые люди, например, страдающие дислексией, действительно находят большие блоки текста трудными для чтения, а другие пользователи почти наверняка сочтут такие страницы скучными и уйдут в другое место — но мы должны критически взглянуть на каждую часть наших веб-сайтов чтобы понять, зарабатывают ли они себе на жизнь.
Доступность и окружающая среда
Еще одна область, где сходятся характеристики и выбросы, — это доступность. Существует распространенное заблуждение, что для обеспечения доступности веб-сайтов необходимо добавить на страницу атрибуты aria и JavaScript, но часто то, что вы не учитываете, важнее, чем то, что вы добавляете, что делает доступный веб-сайт относительно легким и производительным.
Использование стандартных элементов
В MDN Web Docs есть несколько очень хороших руководств по доступности. В «HTML: хорошая основа для доступности» они рассказывают, как лучшая основа доступного веб-сайта заключается в использовании правильных элементов HTML для содержания. Один из самых интересных разделов статьи — попытка воссоздать функциональность элемента button с помощью div и пользовательского JavaScript.
Это, очевидно, минимальный пример, но я подумал, что было бы интересно сравнить размер этой версии кнопки с версией, использующей стандартные элементы HTML. Пример поддельной кнопки в этом случае весит около 1403 байтов без сжатия, тогда как фактическая кнопка с меньшим количеством JavaScript и без стиля весит 746 байтов. Кнопка div также будет семантически бессмысленной и, следовательно, будет намного труднее использовать людям с программами чтения с экрана и ботам для синтаксического анализа.
Рекомендуемая литература : Доступные SVG: идеальные шаблоны для пользователей программ чтения с экрана
При увеличении масштаба такие вещи имеют значение. Анализировать минимальную разметку и JavaScript проще для браузера, как и для разработчиков.
В более крупном масштабе я недавно реорганизовал HTML-код веб-сайта над которым я работаю, — делал такие вещи, как удаление избыточных атрибутов заголовка и замена div на более семантические эквиваленты. Исходная страница имела следующую структуру (содержимое удалено для конфиденциальности и краткости):
Заголовок материала
Некоторые предметы;
Пункт 1
Пункт 2
Пункт 3
С полным содержимым это весило 34 168 байт.
После рефакторинга структура выглядела примерно так:
Заголовок материала
Некоторые предметы;
- Пункт 1
- Пункт 2
- Пункт 3
Он весил 32 805 байт.
В настоящее время изменения продолжаются, но разметка уже стала более доступной по данным WebAIM, Lighthouse и ручного тестирования. Размер файла также уменьшился, и при усреднении времени из пяти профилей в Chrome время синтаксического анализа HTML сократилось примерно на 2 миллисекунды.
Очевидно, что это небольшие изменения, которые, вероятно, не повлияют на восприятие пользователей. Однако приятно осознавать, что каждый байт стоит пользователей и окружающей среды — делая веб-сайт доступным, также можно сделать его немного легче.
Видео
HTML-версия Полного собрания сочинений Уильяма Шекспира проекта Гутенберга занимает примерно 7,4 МБ без сжатия. Согласно данным Android Authority в статье «Сколько данных на самом деле использует YouTube?», Видео с разрешением 360p на YouTube весит от 5 до 7,5 МБ в минуту, а 1080p — от 50 до 68. Таким образом, при той же пропускной способности, что и все пьесы Шекспира , вы получите всего около 7 секунд видео высокой четкости. Видео также очень сложно кодировать и декодировать, и это, вероятно, является одним из основных факторов, влияющих на оценки выбросов углерода Netflix, которые достигают 3,2 кг в час.
Большинство видео полагаются как на визуальные, так и на слуховые компоненты для передачи своего сообщения, а файлы большого размера требуют определенного уровня связи . Это, очевидно, накладывает ограничения на то, кто может извлечь выгоду из такого контента. Сделать видео доступным можно, но это далеко не так просто, и многие веб-сайты просто не беспокоят его.
Если бы видео когда-либо рассматривалось только как форма прогрессивного улучшения, это, возможно, не было бы проблемой, но я потерял счет, сколько раз я искал что-то в Интернете, и единственный способ найти я хотел получить информацию, просмотрев видео. Среднее количество пользователей YouTube в месяц выросло с 20 миллионов в 2006 году до 2 миллиардов в 2020 году. Vimeo также имеет постоянно растущую базу пользователей.
Несмотря на огромное количество посетителей веб-сайтов по обмену видео, многие из самых популярных, похоже, не полностью соответствуют законодательству о доступности. В отличие от этого, многочисленные типы вспомогательных технологий предназначены для того, чтобы сделать простой текст доступным как можно большему количеству людей. Текст также легко преобразовать из одного формата в другой, поэтому его можно использовать в различных контекстах.
Как мы видим на примере Шекспира, простой текст также невероятно эффективен с точки зрения пространства и имеет гораздо меньший углеродный след, чем любая другая форма удобной для человека информации, передаваемой в сети.
Видео может быть отличным, и многие люди лучше всего учатся, наблюдая за процессом в действии, но оно также оставляет некоторых людей в стороне и наносит ущерб окружающей среде. Чтобы наши веб-сайты были как можно более легкими и инклюзивными, мы должны по возможности относиться к тексту как к основной форме общения и предлагать такие вещи, как аудио и видео, в качестве дополнительных.
Рекомендуемая литература : Оптимизация видео по размеру и качеству
Заключение
Надеюсь, этот краткий обзор моего опыта в попытках сделать веб-сайты более благоприятными для окружающей среды дал вам несколько идей, которые можно попробовать на своих собственных веб-сайтах. Может быть очень обидно прогнать страницу через калькулятор углерода на веб-сайте и услышать, что он может выделять сотни килограммов CO2 в год. К счастью, огромный размер сети может усиливать как положительные, так и отрицательные изменения, и даже небольшие улучшения вскоре накапливаются на веб-сайтах с тысячами посетителей в неделю.
Несмотря на то, что мы видим такие вещи, как веб-сайт 25-летней давности, увеличивающийся в размере в 39 раз после редизайна, мы также видим, что веб-сайты используют как можно меньше данных, и умные люди выясняют, как предоставлять WordPress в 7 КБ. Итак, чтобы сократить выбросы углекислого газа на наших веб-сайтах, нам нужно сделать их быстрее — и это принесет пользу всем .
Дополнительная литература
(vf, yk, il, al)
Загрузка...
