Web'deki Karbon Emisyonlarını Azaltma

Diğer pek çok geliştiricide olduğu gibi, son birkaç yılda web'in devasa enerji gereksinimleriyle ilgili raporlar beni kendi web sitelerime bir göz atmaya ve bunların etkilerini en aza indirmek için neler yapabileceğimi görmeye sevk etti. Bu parça, bunu yaparken yaşadığım bazı deneyimleri, ayrıca web sitelerini karbon emisyonları için optimize etme konusundaki mevcut düşüncelerimi ve kendi sayfalarınızı geliştirmek için yapabileceğiniz bazı pratik örnekleri kapsayacaktır.

Ama önce bir itiraf: Web sitelerinin çevresel etkilerini ilk duyduğumda buna pek inanmadım. Sonuçta, dijitalin gezegen için daha iyi olması gerekiyordu, değil mi?

Onlarca yıldır çeşitli yeşil ve çevreci gruplarda yer aldım. Bunca zaman içinde, bilinçli olarak kimsenin web'in olası çevresel etkilerini tartıştığını hatırlamıyorum. Odak noktası her zaman tüketimi azaltmak ve yanan fosil yakıtlardan uzaklaşmaktı. İnternetten yalnızca daha fazla ağaç kesmeye gerek kalmadan birbirleriyle iletişim kurmak veya işe gidip gelmek zorunda kalmadan iletişim kurmak için bir araç olarak bahsedildi.

Bu yüzden, insanlar İnternet'in havayolu endüstrisine benzer karbon emisyonlarına sahip olduğu hakkında konuşmaya başladıklarında, biraz şüpheciydim.

emisyonlar

Bir sunucuya bir sayfa için istek göndermenize ve ardından yanıt almanıza olanak tanıyan devasa donanım ağını görselleştirmek zor olabilir. Çoğumuz veri merkezlerinde yaşamıyoruz ve sinyalleri bir bilgisayardan diğerine taşıyan kablolar genellikle ayaklarımızın altına gömülür. Eylem halindeki bir süreci göremediğinizde, her şey biraz sihir gibi hissedilebilir - bu, bazı şirketlerin ürün adlarına "bulut" ve "sunucusuz" gibi kelimeler ekleme konusundaki ısrarlarının yardımcı olmadığı bir şey.

Bunun bir sonucu olarak, uzun bir süre internete bakış açım biraz geçici, bir tür seraptı. Ancak bu makaleyi yazmaya başladığımda küçük bir düşünce deneyi yaptım: Bir sinyal, yazdığım bilgisayardan evin dışına çıkmak için kaç donanım parçasından geçer?

Cevap oldukça şaşırtıcıydı: 3 kedi kablosu, bir anahtar, 2 elektrik hattı adaptörü, bir yönlendirici ve modem, bir RJ11 kablosu ve birkaç metrelik elektrik tesisatı. Aniden, bu serap daha sağlam görünmeye başladı.

Tabii ki, web (herhangi bir uzantıyla, yaptığımız web siteleri) bir karbon ayak izine sahiptir. İnternetin tüm sunucuları, yönlendiricileri, anahtarları, modemleri, tekrarlayıcıları, telefon dolapları, optikten elektriğe dönüştürücüleri ve uydu yukarı bağlantıları, Dünya'dan çıkarılan metallerden ve ham petrolden arıtılmış plastiklerden yapılmalıdır. Ardından, dünya çapında tahmini 20 milyar bağlı cihaza veri sağlamak için, üretildiğinde karbon salan elektrik tüketmeleri gerekir (fosil yakıtlardan çok daha iyi olmasına rağmen yenilenebilir elektrik bile karbon nötr değildir).

Bu emisyonların tam olarak ne olduğunu tam olarak ölçmek muhtemelen imkansızdır - her cihaz farklıdır ve onlara güç sağlayan enerji bir gün içinde değişebilir - ancak güç tüketimi, kullanıcı tabanları ve tipik rakamlara bakarak kabaca bir fikir edinebiliriz. yakın zamanda. Tek bir sayfanın karbon emisyonlarını tahmin etmek için bu verileri kullanan bir araç, Web Sitesi Karbon Hesaplayıcıdır. Buna göre, test edilen ortalama sayfa "sayfa görüntüleme başına 1,76 gram CO2 üretir".

Yaptığınız işin çevreye zararsız olduğunu düşünmeye alıştıysanız, bu farkındalık oldukça cesaret kırıcı olabilir. İyi haber şu ki, geliştiriciler olarak bu konuda çok şey yapabiliriz.

Önerilen okuma : Web Sitesi Performansını Geliştirmek Gezegeni Kurtarmaya Nasıl Yardımcı Olabilir

Performans ve Emisyonlar

Web sitelerini görüntülemenin elektrik kullandığını ve elektrik üretmenin karbon saldığını hatırlarsak, bir sayfanın emisyonunun büyük ölçüde hem sunucunun hem de istemcinin sayfayı görüntülemek için yapması gereken iş miktarına bağlı olması gerektiğini biliriz. Ayrıca, sayfa için gereken veri miktarı ve geçmesi gereken rotanın karmaşıklığı, ağın kendisi tarafından salınan karbon miktarını belirleyecektir.

Örneğin, example.com'u indirmek ve oluşturmak, muhtemelen Apple'ın ana sayfasından çok daha az elektrik tüketecek ve ayrıca çok daha hızlı olacaktır. Aslında, yüksek emisyonların ve yavaş sayfa yüklemelerinin aynı temel nedenlerin iki belirtisi olduğunu söylüyoruz.

Elbette bu ilişki hakkında teorik olarak konuşmak çok güzel, ama bunu destekleyecek gerçek dünya verilerine sahip olmak güzel olurdu. Bunu yapmak için küçük bir çalışma yapmaya karar verdim. MOZ'a göre İnternet'teki en popüler 500 web sitesinin bir listesini almak ve ana sayfalarını hem Google'ın PageSpeed ​​Insights hem de Web Sitesi Karbon Hesaplayıcısına göre kontrol etmek için basit bir komut satırı arayüzü programı yazdım.

Bazı kontroller zaman aşımına uğradı (genellikle söz konusu sayfanın yüklenmesi çok uzun sürdüğü için), ancak toplamda, 14 Temmuz 2021'de 400'den fazla sayfa için sonuç toplamayı başardım. Kendinizi incelemek için sonuçların özetini indirebilirsiniz ancak görsel bir gösterge sağlamak için, bunları aşağıdaki çizelgede çizdim:

Gördüğünüz gibi, tek tek web siteleri arasındaki fark çok yüksek olsa da, daha hızlı sayfalardan daha düşük emisyonlara yönelik güçlü bir eğilim var. Sayfa Hızı puanı 100 olan web siteleri için ortalama ortalama emisyon, yaklaşık 1 gram karbondur ve bu, 0 puana sahip web siteleri için öngörülen yaklaşık 6 gramdır. Çok düşük puanlı birçok web sitesi olmasına rağmen, bunu biraz güven verici buluyorum. hızlar ve yüksek emisyonlar, sonuçların çoğu grafiğin sağ alt kısmında kümelenmiştir.

Harekete geçmek

Bir sayfadaki emisyonların çoğunun düşük performanstan kaynaklandığını anladığımızda, bunları azaltmak için adımlar atmaya başlayabiliriz. Bir web sitesinin emisyonlarına katkıda bulunan şeylerin çoğu, geliştiriciler olarak kontrolümüzün ötesindedir. Örneğin, kullanıcılarımızın sayfalarımıza eriştiği cihazları seçemez veya isteklerinin geçtiği ağ altyapısına karar veremeyiz, ancak web sitelerimizin performansını iyileştirmek için adımlar atabiliriz.

Performans optimizasyonu geniş bir konu ve bunu okuyanların çoğu muhtemelen benden daha fazla deneyime sahip, ancak son zamanlarda çeşitli sayfaların yükleme hızını ve karbon emisyonlarını optimize ederken gözlemlediğim birkaç şeyden kısaca bahsetmek istiyorum.

İşleme Mobilde Çok Daha Yavaş

Kısa bir süre önce kişisel blogumun tasarımını biraz daha kullanıcı dostu hale getirmek için elden geçirdim. Hobilerimden biri fotoğrafçılık ve web sitesinde daha önce tam yükseklikte bir başlık resmi vardı.

Tasarım, fotoğraflarımı sergilemek için iyi bir iş çıkarsa da, özellikle blog yazılarının sayfalarında gezinirken, gezinmek tam bir acıydı. Bununla birlikte, başlıkta bir fotoğrafın olduğu hissini kaybetmek istemedim ve sonunda onu sayfa başlığı için arka plan olarak kullanmaya karar verdim.

Tam yükseklikte başlık, yüklemeyi olabildiğince hızlı yapmak için srcset kullanıyordu, ancak görüntüler yüksek çözünürlüklü ekranlarda hala çok büyüktü ve mobilde eski tasarım için en uzun içerik dolu boyama (LCP) sürem neredeyse 3'tü. saniye. Yeni tasarımın büyük bir avantajı, görüntüleri çok daha küçük yapmama izin vermesiydi, bu da LCP süresini yaklaşık 1,5 saniyeye indirdi.

Dizüstü ve masaüstü bilgisayarlarda insanlar bir fark görmezdi çünkü her iki sürüm de bir saniyenin altındaydı, ancak çok daha az güçlü mobil cihazlarda oldukça çarpıcıydı. Bu değişikliğin karbon emisyonları üzerindeki etkisi ne oldu? Görünüm başına 0,31 gram öncesi, 0,05 gram sonrası. Görüntülerin kodunu çözme ve oluşturma çok kaynak gerektirir ve bu, görüntüler büyüdükçe katlanarak büyür.

Kod çözme süresi üzerinde etkisi olabilecek tek şey görüntülerin boyutu değildir; biçimi de önemlidir. Google'ın Deniz Feneri, indirilmesi gereken veri miktarını azaltmak için genellikle görüntülerin yeni nesil biçimlerde sunulmasını önerir, ancak yeni biçimlerin kodunun çözülmesi, özellikle mobil cihazlarda genellikle daha yavaştır. Kablo üzerinden daha az veri göndermek çevre için daha iyidir, ancak deşifre etmek için daha fazla enerji tüketmek bu avantajı telafi edebilir. Çoğu şeyde olduğu gibi, test burada anahtardır.

Zola statik site oluşturucusuna AVIF kodlaması için destek eklemeye çalışırken yaptığım kendi testlerimden, aynı kalitede JPG'den çok daha küçük dosya boyutları vaat eden AVIF'in kodlamanın çok daha uzun sürdüğünü buldum; bunny.net'in WebP'nin AVIF'ten 100 kat daha iyi performans gösterdiğine dair gözleminin desteklediği bir şey. Bunu yaparken sunucu elektrik tüketecek ve düşük ziyaretçi sayısına sahip web siteleri için yeni biçime geçişin gerçekten emisyonları artırıp performansı düşürüp düşürmediğini merak ediyorum.

Görüntüler, elbette, işlenmesi uzun zaman alan modern web sayfalarının tek bileşeni değildir. Küçük JavaScript dosyalarının ne yaptıklarına bağlı olarak yürütülmesi uzun zaman alabilir ve görsellerle aynı potansiyel tuzaklar geçerli olacaktır.

Önerilen okuma : The Humble img Element ve Core Web Vitals

Gidiş-Dönüş Toplama

Performans ve emisyonlar üzerinde şaşırtıcı bir etkisi olabilecek başka bir şey de verilerinizin nereden geldiğidir. Geleneksel görüş, uzun zamandır merkezi bir içerik dağıtım ağından (CDN) çerçeveler gibi varlıklara hizmet etmenin performansı artıracağını söylüyor çünkü yerel düğümlerden veri almak genellikle kullanıcılar için merkezi bir sunucudan daha hızlıdır. Örneğin jQuery, bir CDN'den yükleme seçeneğine sahiptir ve bunun sahipleri bunun performansı artırabileceğini söylüyor, ancak Harry Roberts tarafından yapılan gerçek dünya testleri, kendi kendini barındıran varlıkların genellikle daha hızlı olduğunu göstermiştir.

Bu benim de deneyimim oldu. Geçenlerde bir oyun web sitesinin performansını iyileştirmesine yardımcı oldum. Web sitesi oldukça büyük bir CSS çerçevesi kullanıyor ve tüm üçüncü taraf varlıklarını bir CDN aracılığıyla yüklüyordu. Tüm varlıkları kendi kendine barındırmaya geçtik ve kullanılmayan bileşenleri çerçeveden kaldırdık.

Optimizasyonların hiçbiri web sitesinde herhangi bir görsel değişiklikle sonuçlanmadı, ancak birlikte Lighthouse puanını 72'den 98'e yükseltti ve karbon emisyonlarını görüntüleme başına 0,26 gramdan 0,15'e düşürdü.

Yalnızca İhtiyacınız Olanı Gönderin

Bu, kullanıcılara yalnızca gerçekten ihtiyaç duydukları verileri gönderme konusuna güzel bir şekilde yol açar. Birbirlerine gülümseyen takım elbiseli insanların stok görüntülerinin hakim olduğu birçok web sitesinde çalıştım (ve ziyaret ettim). Bazı kuruluşlar arasında, yaptıklarının gerçekten sıkıcı olduğu ve fotoğraf eklemenin bir şekilde genel halkı aksine ikna edeceğine dair bir zihniyet var gibi görünüyor.

Bunun arkasındaki düşünceyi anlayabiliyorum çünkü insanların okumaya ayırdıkları zamanın nasıl azaldığına dair sayısız eser var. Bize defalarca söylenen metnin modası geçiyor; şimdi tüm insanların ilgilendiği videolar ve etkileşimli deneyimler.

Bu açıdan bakıldığında, stok fotoğraflar sayfaları canlandırmak için yararlı bir araç olarak görülebilir, ancak göz izleme çalışmaları, insanların alakasız görüntüleri görmezden geldiğini gösteriyor. İnsanlar resimlerinize bakmadığında, resimler boş alan da olabilir. Ve her bayt paraya mal olduğunda, iklim değişikliğine katkıda bulunduğunda ve yükleme sürelerini yavaşlattığında, gerçekten öyle olsaydı herkes için daha iyi olurdu.

Yine görseller için söylenebilecekler, sayfanın ana içeriği olmayan her şey için söylenebilir. Bir şey kullanıcının deneyimine anlamlı bir şekilde katkıda bulunmuyorsa, orada olmamalıdır. Hepimizin stilsiz sayfalar sunmaya başladığımızı bir an bile savunmuyorum - disleksi olanlar gibi bazı insanlar büyük metin bloklarını okumayı zor buluyor ve diğer kullanıcılar neredeyse kesinlikle bu tür sayfaları sıkıcı bulup başka yerlere gidecekler - ama web sitelerimizin her bölümüne eleştirel bir gözle bakmamız ve onların geçimlerini sağlayıp sağlamadıklarını değerlendirmemiz gerekir .

Erişilebilirlik ve Çevre

Performans ve emisyonların birleştiği bir diğer alan da erişilebilirlik alanıdır. Web sitelerini erişilebilir hale getirmenin bir sayfaya aria öznitelikleri ve JavaScript eklemeyi içerdiğine dair yaygın bir yanılgı vardır, ancak genellikle dışarıda bıraktıklarınız, koyduğunuzdan daha önemlidir ve erişilebilir bir web sitesini nispeten hafif ve performanslı hale getirir.

Standart Öğeleri Kullanma

MDN Web Docs, erişilebilirlikle ilgili çok iyi öğreticilere sahiptir. "HTML: Erişilebilirlik için İyi Bir Temel" bölümünde, erişilebilir bir web sitesinin en iyi temelinin içerik için doğru HTML öğelerini kullanmakta yattığını ele alıyorlar. Makalenin en ilginç bölümlerinden biri, bir div ve özel JavaScript kullanarak bir button öğesinin işlevselliğini yeniden oluşturmaya çalıştıkları yerdir.

Bu açıkça minimal bir örnek, ancak bu düğme sürümünün boyutunu standart HTML öğelerini kullanan bir sürümle karşılaştırmanın ilginç olacağını düşündüm. Bu durumda sahte düğme örneği, sıkıştırılmamış halde yaklaşık 1.403 bayt ağırlığındayken, daha az JavaScript içeren ve stili olmayan gerçek bir button 746 bayt ağırlığındadır. div düğmesi de anlamsal olarak anlamsız olacaktır ve bu nedenle ekran okuyucuları olan kişilerin kullanması ve botların ayrıştırması çok daha zor olacaktır.

Önerilen okuma : Erişilebilir SVG'ler: Ekran Okuyucu Kullanıcıları İçin Mükemmel Modeller

Büyütüldüğünde, bu tür şeyler bir fark yaratır. Minimal biçimlendirme ve JavaScript'i ayrıştırmak, geliştiriciler için daha kolay olduğu gibi bir tarayıcı için de daha kolaydır.

Daha büyük ölçekte, son zamanlarda üzerinde çalıştığım bir web sitesinin HTML'sini yeniden düzenledim - gereksiz başlık niteliklerini kaldırmak ve div 'leri daha anlamsal eşdeğerlerle değiştirmek gibi şeyler yapıyordum. Orijinal sayfa aşağıdaki gibi bir yapıya sahipti (gizlilik ve kısalık için içerik kaldırıldı):

 <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>

Tam içerikle, bu 34.168 bayt ağırlığındaydı.

Yeniden düzenlemeden sonra yapı şuna benziyordu:

 <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 bayt ağırlığındaydı.

Değişiklikler şu anda devam ediyor, ancak işaretlemeye WebAIM, Lighthouse ve manuel testlere göre çok daha erişilebilir. Dosya boyutu da azaldı ve Chrome'daki beş profilden ortalama süre alınırken HTML'yi ayrıştırma süresi yaklaşık 2 milisaniye azaldı.

Bunlar açıkça küçük değişikliklerdir ve muhtemelen kullanıcılar için herhangi bir algısal fark yaratmayacaktır. Ancak, her baytın kullanıcılara ve çevreye mal olduğunu bilmek güzel - bir web sitesini erişilebilir kılmak aynı zamanda onu biraz daha hafif hale getirebilir.

Videolar

Project Gutenberg'in The Complete Works of William Shakespeare'in HTML versiyonu sıkıştırılmamış yaklaşık 7,4 MB'dir. "YouTube Aslında Ne Kadar Veri Kullanıyor?" başlıklı Android Authority'ye göre, 360p bir YouTube videosunun ağırlığı dakikada yaklaşık 5 ila 7,5 MB ve 1080p yaklaşık 50 ila 68 arasındadır. Yani, Shakespeare'in tüm oyunlarıyla aynı miktarda bant genişliği için , yalnızca yaklaşık 7 saniyelik yüksek çözünürlüklü video elde edersiniz. Videonun kodlanması ve kodunun çözülmesi de oldukça yoğundur ve bu muhtemelen Netflix'in karbon emisyonlarının saatte 3,2 KG kadar yüksek olduğu tahminlerine önemli bir katkıda bulunan faktördür.

Çoğu video, mesajlarını iletmek için hem görsel hem de işitsel bileşenlere güvenir ve büyük dosya boyutları belirli bir düzeyde bağlantı gerektirir . Bu açıkçası, bu tür içerikten kimlerin yararlanabileceği konusunda sınırlamalar getiriyor. Videoyu erişilebilir kılmak mümkündür ancak basit olmaktan uzaktır ve birçok web sitesi zahmetsizce uğraşmaz.

Videoya yalnızca aşamalı bir geliştirme biçimi olarak davranılsaydı, bu belki bir sorun olmazdı, ancak web'de bir şeyi kaç kez aradığımı ve aradığım bilgiyi bulmanın tek yolunu unuttum. bir video izlemek istedim. YouTube'da, aylık ortalama kullanıcı sayısı 2006'da 20 milyondan 2020'de 2 milyara yükseldi. Vimeo'nun ayrıca sürekli büyüyen bir kullanıcı tabanı var.

Video paylaşım sitelerinin çok sayıda ziyaretçisine rağmen, en popüler sitelerin çoğu erişilebilirlik mevzuatına tam olarak uygun görünmüyor. Bunun aksine, düz metni mümkün olduğunca çok sayıda insan için erişilebilir kılmak için çok sayıda yardımcı teknoloji tasarlanmıştır. Metnin bir biçimden diğerine dönüştürülmesi de kolaydır, bu nedenle bir dizi farklı bağlamda kullanılabilir.

Shakespeare örneğinden de görebileceğimiz gibi, düz metin aynı zamanda alan açısından inanılmaz derecede verimlidir ve web'de iletilen diğer insan dostu bilgilerden çok daha düşük karbon ayak izine sahiptir.

Video harika olabilir ve birçok insan en iyi şekilde bir süreci çalışırken izleyerek öğrenir, ancak aynı zamanda bazı insanları dışarıda bırakır ve çevresel bir maliyeti vardır. Web sitelerimizi olabildiğince hafif ve kapsayıcı tutmak için, metni mümkün olan her yerde birincil iletişim biçimi olarak görmeli ve ses ve video gibi şeyleri ekstra olarak sunmalıyız.

Önerilen Okuma : Videoyu Boyut ve Kalite İçin Optimize Etme

Sonuç olarak

Umarım, web sitelerini çevre için daha iyi hale getirmeye çalışırken edindiğim deneyimlere bu kısa bakış, size kendi web sitelerinizde deneyebileceğiniz şeyler için bazı fikirler vermiştir. Web Sitesi Karbon Hesaplayıcı aracılığıyla bir sayfa çalıştırmak ve bunun yılda yüzlerce kilogram CO2 saldığını söylemek oldukça cesaret kırıcı olabilir. Neyse ki, web'in büyüklüğü, olumsuz değişikliklerin yanı sıra olumlu değişiklikleri de artırabilir ve hatta küçük iyileştirmeler bile, haftada binlerce ziyaretçisi olan web sitelerinde kısa sürede eklenir .

25 yıllık bir web sitesinin yeniden tasarımdan sonra 39 kat arttığını görsek de, web sitelerinin mümkün olduğunca az veri kullanacak şekilde yapıldığını ve akıllı insanların 7'de WordPress'i nasıl sunacağını çözdüğünü görüyoruz. KB. Bu nedenle, web sitelerimizin karbon emisyonlarını azaltabilmemiz için onları daha hızlı hale getirmemiz gerekiyor - bu da herkesin yararına.

Daha fazla okuma

• Dünya Çapında Atık, Gerry McGovern
• "WebP Gerçekten JPEG'den Daha İyi mi?", Johannes Siipola
• “Jamstack'i Yavaşla? Meydan Okuma Kabul Edildi.”, Steve Keep, CSS-Tricks
• “İnternet Hiç Yeşil Olabilir mi?”, İklim Sorusu, BBC
• “Veri Merkeziniz Sadece Web Sitenize Güç Vermekle Kalmaz, Salatanızı da Büyütebilir mi?”, Tom Greenwood, Wholegrain Digital
• Better Web Alliance (kendi projem)
• Sürdürülebilir Web Manifestosu