Web上での炭素排出量の削減

他の多くの開発者の場合と同様に、Webの膨大なエネルギー要件に関する過去数年間のレポートにより、私は自分のWebサイトを調べて、その影響を最小限に抑えるために何ができるかを確認するようになりました。 この記事では、これを行った私の経験の一部、およびWebサイトの炭素排出量の最適化に関する現在の考え、および自分のページを改善するために実行できるいくつかの実用的な例について説明します。

しかし、最初に、告白：ウェブサイトの環境への影響について最初に聞いたとき、私はそれをまったく信じていませんでした。 結局のところ、デジタルは地球にとってより良いはずですよね？

私は何十年もの間、さまざまな環境保護団体に参加してきました。 その間ずっと、ウェブが環境に与える可能性のある影響について話し合った人を意識的に思い出すことはできません。 焦点は常に消費の削減と化石燃料の燃焼からの脱却にありました。 インターネットが言及されたのは、木を切り倒さずに相互に通信したり、通勤せずに作業したりするためのツールとしてのみでした。

ですから、人々が最初に航空業界と同様の炭素排出量を持つインターネットについて話し始めたとき、私は少し懐疑的でした。

排出量

ページのリクエストをサーバーに送信してから応答を受信できるハードウェアの巨大なネットワークを視覚化するのは難しい場合があります。 私たちのほとんどはデータセンターに住んでおらず、あるコンピューターから別のコンピューターに信号を運ぶケーブルは、しばしば私たちの足元に埋もれています。 プロセスが実際に動作しているのを見ることができない場合、全体が魔法のように感じることがあります。これは、特定の企業が製品名に「クラウド」や「サーバーレス」などの単語を追加することを主張することによって助けられないものです。

その結果、私のインターネットに対する長い間の見方は、ちょっと短命で、一種の蜃気楼でした。 しかし、この記事を書き始めたとき、私は少し考えて実験を行いました。家の外に出るために、書いているコンピューターから信号がいくつのハードウェアを通過するのでしょうか。

答えは非常に衝撃的でした。3本の猫ケーブル、スイッチ、2本の電力線アダプタ、ルーターとモデム、RJ11ケーブル、および数メートルの電気配線です。 突然、その蜃気楼はかなり堅実に見え始めました。

もちろん、Web（ひいては私たちが作成するWebサイト）には二酸化炭素排出量があります。 インターネットのすべてのサーバー、ルーター、スイッチ、モデム、リピーター、電話キャビネット、光から電気へのコンバーター、および衛星アップリンクは、地球から抽出された金属、および原油から精製されたプラスチックから構築する必要があります。 次に、世界中の推定200億の接続デバイスにデータを提供するには、電力を消費する必要があります。電力は、生成時に炭素も放出します（再生可能電力でさえ、化石燃料よりもはるかに優れていますが、カーボンニュートラルではありません）。

これらの排出量を正確に測定することはおそらく不可能です。各デバイスは異なり、それらに電力を供給するエネルギーは1日を通して変化する可能性がありますが、消費電力、ユーザーベース、およびすぐ。 このデータを使用して単一ページの炭素排出量を推定するツールの1つは、Webサイトの炭素計算機です。 それによると、テストされた平均的なページは「ページビューあたり1.76グラムのCO2を生成します」。

自分が行っている作業を環境に本質的に無害であると考えることに慣れている場合、この認識は非常に失望する可能性があります。 良いニュースは、開発者として、私たちはそれについて非常に多くのことを行うことができるということです。

推奨読書：ウェブサイトのパフォーマンスを改善することが地球を救うのにどのように役立つか

パフォーマンスと排出量

Webサイトを表示すると電気が使用され、電気を生成すると炭素が放出されることを思い出すと、ページの排出量は、ページを表示するためにサーバーとクライアントの両方が実行する必要のある作業量に大きく依存する必要があることがわかります。 また、ページに必要なデータの量、およびページが通過する必要のあるルートの複雑さによって、ネットワーク自体から放出される炭素の量が決まります。

たとえば、example.comのダウンロードとレンダリングは、Appleのホームページよりもはるかに少ない電力を消費する可能性が高く、また、はるかに高速になります。 事実上、私たちが言っているのは、高排出量と遅いページ読み込みは、同じ根本的な原因の2つの症状にすぎないということです。

もちろん、理論的にはこの関係について話すのは非常に良いことですが、それをバックアップするための実際のデータがあると便利です。 そのために、少し勉強することにしました。 MOZによると、インターネット上で最も人気のある500のWebサイトのリストを取得し、それらのホームページをGoogleのPageSpeedInsightsとWebsiteCarbonCalculatorの両方と照合する簡単なコマンドラインインターフェイスプログラムを作成しました。

一部のチェックがタイムアウトしましたが（多くの場合、問題のページの読み込みに時間がかかりすぎたため）、2021年7月14日に合計で400ページを超える結果を収集できました。結果の概要をダウンロードして自分自身を調べることができますが、視覚的な表示を提供するために、以下のチャートにそれらをプロットしました。

ご覧のとおり、個々のWebサイト間のばらつきは非常に大きいものの、より高速なページからの排出量が少なくなる傾向が強くなっています。 PageSpeedスコアが100のWebサイトの平均排出量は約1グラムの炭素であり、スコアが0のWebサイトの予測値は約6グラムになります。非常に低いWebサイトが多数あるにもかかわらず、少し安心できます。速度と高排出量の場合、ほとんどの結果はチャートの右下にまとめられています。

行動を起こします

ページの排出量の多くがパフォーマンスの低下に起因することを理解したら、それらを削減するための措置を講じることができます。 ウェブサイトの排出に寄与するものの多くは、開発者としての私たちの制御を超えています。 たとえば、ユーザーがページにアクセスするデバイスを選択したり、リクエストが通過するネットワークインフラストラクチャを決定したりすることはできませんが、Webサイトのパフォーマンスを向上させるための措置を講じることはできます。

パフォーマンスの最適化は幅広いトピックであり、これを読んでいる多くの人は私よりも経験が豊富ですが、さまざまなページの読み込み速度と炭素排出量を最適化するときに最近観察したいくつかのことを簡単に説明します。

モバイルでのレンダリングははるかに遅い

私は最近、個人ブログのデザインをもう少しユーザーフレンドリーにするために作り直しました。 私の趣味の1つは写真撮影で、ウェブサイトには以前はフルハイトのヘッダー画像が掲載されていました。

デザインは私の写真をうまく紹介するのに役立ちましたが、特にブログ投稿のページを移動するときは、スクロールして通り過ぎるのは完全に苦痛でした。 しかし、ヘッダーに写真があるという感覚を失いたくなかったので、最終的にはそれをページタイトルの背景として使用することにしました。

フルハイトヘッダーは、読み込みをできるだけ速くするためにsrcsetを使用していましたが、高解像度の画面では画像が依然として非常に大きく、古いデザインのモバイルでの最長のコンテンツペイント（LCP）時間はほぼ3でした秒。 新しいデザインの大きな利点は、画像をはるかに小さくできることでした。これにより、LCP時間が約1.5秒に短縮されました。

ラップトップとデスクトップでは、どちらのバージョンも1秒未満であるため、人々は違いに気付かなかったでしょうが、はるかに強力でないモバイルデバイスでは、それは非常に劇的でした。 この変更が炭酸ガス放出にどのような影響を及ぼしましたか？ 前はビューあたり0.31グラム、後は0.05グラム。 画像のデコードとレンダリングは非常に多くのリソースを消費し、画像が大きくなるにつれて指数関数的に増加します。

デコード時間に影響を与える可能性があるのは、画像のサイズだけではありません。 フォーマットも重要です。 GoogleのLighthouseは、ダウンロードする必要のあるデータの量を減らすために、次世代フォーマットで画像を提供することを推奨することがよくありますが、新しいフォーマットは、特にモバイルでは、デコードに時間がかかることがよくあります。 有線で送信するデータが少ない方が環境には適していますが、デコードに多くのエネルギーを消費すると、そのメリットが相殺される可能性があります。 ほとんどのものと同様に、ここではテストが重要です。

Zola静的サイトジェネレーターにAVIFエンコーディングのサポートを追加しようとした私自身のテストから、同じ品質でJPGよりもはるかに小さいファイルサイズを約束するAVIFは、エンコードに桁違いに時間がかかることがわかりました。 WebPがAVIFを100倍も上回っているというbunny.netの観察はこれをサポートしています。 その間、サーバーは電力を消費します。訪問者数が少ないWebサイトの場合、新しい形式に切り替えると、実際に排出量が増加し、パフォーマンスが低下する可能性があるのではないかと思います。

もちろん、処理に長い時間がかかる最新のWebページのコンポーネントは画像だけではありません。 小さなJavaScriptファイルは、実行内容によっては実行に時間がかかる場合があり、画像と同じ潜在的な落とし穴が適用されます。

推奨読書：謙虚img要素とコアWebバイタル

ラウンドトリップの合計

パフォーマンスと排出量に驚くべき影響を与える可能性のあるもう1つのことは、データの出所です。 ローカルノードからのデータの取得は一般に中央サーバーからのデータよりも高速であるため、従来の知識では、中央コンテンツ配信ネットワーク（CDN）からフレームワークなどのアセットを提供するとパフォーマンスが向上すると長い間言われてきました。 たとえば、jQueryにはCDNからロードするオプションがあり、そのメンテナはこれによりパフォーマンスが向上すると述べていますが、Harry Robertsによる実際のテストでは、セルフホスティングアセットの方が一般的に高速であることが示されています。

これも私の経験です。 私は最近、ゲームのWebサイトのパフォーマンスを向上させるのを手伝いました。 このWebサイトは、かなり大きなCSSフレームワークを使用しており、CDNを介してすべてのサードパーティアセットをロードしていました。 すべてのアセットをセルフホスティングに切り替え、フレームワークから未使用のコンポーネントを削除しました。

最適化のいずれもウェブサイトに視覚的な変更をもたらしませんでしたが、一緒にそれらは灯台スコアを72から98に増やし、炭素排出量をビューあたり0.26グラムから0.15に減らしました。

必要なものだけを送信する

これは、ユーザーが実際に必要なデータのみを送信するというテーマにうまくつながります。 私は、スーツを着た人々がお互いに微笑んでいるストック画像によって支配されている多くのWebサイトに取り組んできました（そして訪問しました）。 特定の組織の間には、彼らがしていることは本当に退屈であり、写真を追加することはどういうわけか一般大衆を納得させるだろうという考え方があるようです。

人々が読書に費やす時間がどのように減少しているかについての多くの部分があるので、私はこの背後にある考え方をある程度理解することができます。 繰り返し言われているように、テキストは時代遅れになっています。 今興味を持っているのは、ビデオとインタラクティブな体験だけです。

その観点から、ストックフォトはページを活気づけるための便利なツールと見なすことができますが、視線追跡の研究は、人々が関連性のない画像を無視していることを示しています。 人々があなたの画像を見ていないとき、画像は空のスペースである可能性もあります。 そして、すべてのバイトにお金がかかり、気候変動に寄与し、読み込み時間が遅くなる場合、実際にそうだったとしたら、誰にとっても良いでしょう。

繰り返しになりますが、画像について言えることは、ページのコアコンテンツではない他のすべてについても言えます。 何かが意味のある方法でユーザーエクスペリエンスに貢献していない場合、それはそこにあるべきではありません。 私は今のところ、私たち全員がスタイルのないページを提供し始めることを主張していません。失読症の人など、テキストの大きなブロックが読みにくいと感じる人もいれば、そのようなページが退屈で他の場所に行く人もいるでしょう。私たちは、ウェブサイトのすべての部分を批判的に見て、それらが維持されているかどうかを検討する必要があります。

アクセシビリティと環境

パフォーマンスと排出量が収束するもう1つの分野は、アクセシビリティの分野です。 ウェブサイトをアクセシブルにすることは、ページにaria属性とJavaScriptを追加することを含むという一般的な誤解がありますが、多くの場合、アクセシブルなWebサイトを比較的軽量でパフォーマンスの高いものにするために、省略したものが入力したものよりも重要です。

標準要素の使用

MDN Web Docsには、アクセシビリティに関する非常に優れたチュートリアルがいくつかあります。 「HTML：アクセシビリティの優れた基礎」では、コンテンツに適切なHTML要素を使用することで、アクセシブルなWebサイトの最良の基盤がどのように確立されるかについて説明しています。 この記事の最も興味深いセクションの1つは、 divとカスタムJavaScriptを使用してbutton要素の機能を再現しようとするところです。

これは明らかに最小限の例ですが、このボタンバージョンのサイズを標準のHTML要素を使用したものと比較するのは興味深いと思いました。 この場合の偽のボタンの例は、圧縮されていない状態で約1,403バイトの重さがありますが、JavaScriptが少なく、スタイルが設定されていない実際のbuttonの重さは746バイトです。 divボタンも意味的に無意味であるため、スクリーンリーダーを使用しているユーザーやボットが解析するのははるかに困難です。

推奨読書：アクセシブルなSVG：スクリーンリーダーユーザーに最適なパターン

スケールアップすると、これらの種類のものが違いを生みます。 最小限のマークアップとJavaScriptの解析は、開発者にとっても簡単であるのと同様に、ブラウザーにとっても簡単です。

大規模な場合、私は最近、作業中のWebサイトのHTMLをリファクタリングしていました。たとえば、冗長なタイトル属性を削除したり、 divをよりセマンティックな同等のものに置き換えたりしていました。 元のページは次のような構造でした（プライバシーと簡潔さのためにコンテンツは削除されました）。

 <div class="container"> <section> <div class="row"> <div class="col-md-3"> <aside> <!-- Sidebar content here --> </aside> </div> <div class="col-md-9"> <!-- Main content here --> <h4>Content piece heading</h4> <p> Some items;<br> Item 1 <br> Item 2 <br> Item 3 <br> <br> </p> <!-- More main content here --> </div> </div> </section> </div>

完全なコンテンツで、これは34,168バイトの重さでした。

リファクタリング後の構造は次のようになりました。

 <div class="container"> <div class="row"> <main class="col-md-9 col-md-push-3"> <!-- Main content here --> <h3>Content piece heading</h3> <p>Some items;</p> <ul> <li>Item 1</li> <li>Item 2</li> <li>Item 3</li> </ul> <!-- More main content here --> </main> <aside class="col-md-3 col-md-pull-9"> <!-- Sidebar content here --> </aside> </div> </div>

重さは32,805バイトでした。

変更は現在進行中ですが、WebAIM、Lighthouse、および手動テストによれば、マークアップはすでにはるかにアクセスしやすくなっています。 ファイルサイズも小さくなり、Chromeの5つのプロファイルの時間を平均すると、HTMLの解析時間が約2ミリ秒短縮されました。

これらは明らかに小さな変更であり、おそらくユーザーに知覚上の違いをもたらすことはありません。 ただし、 1バイトごとにユーザーと環境にコストがかかることを知っておくと便利です。Webサイトにアクセスできるようにすることで、Webサイトを少し軽くすることもできます。

ビデオ

プロジェクト・グーテンベルクの『シェイクスピア全集』のHTMLバージョンは、非圧縮で約7.4MBです。 Android Authorityの「YouTubeは実際にどのくらいのデータを使用していますか？」によると、360pのYouTubeビデオの重量は1分あたり約5〜7.5 MB、1080pの重量は約50〜68です。したがって、シェイクスピアのすべての再生と同じ帯域幅で、高解像度ビデオは約7秒しか得られません。 ビデオもエンコードとデコードに非常に集中しており、これはおそらくNetflixの炭素排出量が1時間あたり3.2KGと高いと推定される主な要因です。

ほとんどのビデオは、メッセージを伝達するために視覚と聴覚の両方のコンポーネントに依存しており、大きなファイルサイズには一定レベルの接続が必要です。 これは明らかに、そのようなコンテンツから利益を得ることができる人に制限を課します。 ビデオをアクセシブルにすることは可能ですが、単純ではありません。多くのWebサイトは単に気にしません。

ビデオがプログレッシブエンハンスメントの形式としてのみ扱われた場合、これはおそらく問題ではありませんが、Webで何かを検索した回数のカウントを失い、情報を見つける唯一の方法です。欲しかったのはビデオを見ることでした。 YouTubeの月間平均ユーザー数は、2006年の2,000万人から2020年には20億人に増加しました。また、Vimeoのユーザーベースは継続的に増加しています。

ビデオ共有Webサイトへの訪問者の数が非常に多いにもかかわらず、最も人気のあるWebサイトの多くは、アクセシビリティに関する法律に完全には準拠していないようです。 これとは対照的に、多くの種類の支援技術は、可能な限り幅広い人々がプレーンテキストにアクセスできるように設計されています。 テキストは、ある形式から別の形式に簡単に変換できるため、さまざまなコンテキストで使用できます。

シェイクスピアの例からわかるように、プレーンテキストも非常にスペース効率が高く、Web上で送信される他の形式の人間に優しい情報よりもはるかに二酸化炭素排出量が少なくなっています。

ビデオは素晴らしいものになる可能性があり、多くの人は実際のプロセスを見ることで最もよく学ぶことができますが、一部の人を除外し、環境コストもかかります。 ウェブサイトを可能な限り軽量で包括的なものに保つために、可能な限りテキストを主要なコミュニケーション手段として扱い、オーディオやビデオなどを追加で提供する必要があります。

推奨読書：サイズと品質のためのビデオの最適化

結論は

うまくいけば、環境に合わせてWebサイトを改善しようとした私の経験を簡単に見て、自分のWebサイトで試すことについていくつかのアイデアが得られたと思います。 WebサイトのCarbonCalculatorでページを実行し、年間数百キログラムのCO2を排出する可能性があると言われると、非常にがっかりする可能性があります。 幸いなことに、Webのサイズが非常に大きいため、マイナスの変化だけでなくプラスの変化も増幅される可能性があります。また、週に数千人の訪問者がいるWebサイトでは、わずかな改善でもすぐに追加されます。

再設計後、25年前のWebサイトのサイズが39倍に拡大するなどの状況が見られますが、Webサイトのデータ使用量が可能な限り少なくなり、賢い人々がWordPressを7で配信する方法を模索しています。 KB。 したがって、Webサイトの炭素排出量を削減するには、Webサイトを高速化する必要があります。これは、すべての人にメリットをもたらします。

参考文献

• ワールドワイドウェイスト、ジェリーマガバーン
• 「WebPは本当にJPEGよりも優れていますか？」、Johannes Siipola
• 「Jamstackを遅くしますか？ チャレンジが受け入れられました。」、Steve Keep、CSS-トリック
• 「インターネットはこれまでにグリーンになることができますか？」、気候問題、BBC
• 「データセンターはウェブサイトに電力を供給するだけでなく、サラダも成長させることができますか？」、Tom Greenwood、Wholegrain Digital
• Better Web Alliance（私自身のプロジェクト）
• 持続可能なウェブマニフェスト