Mengurangi Emisi Karbon Di Web

Seperti halnya dengan banyak pengembang lain, laporan selama beberapa tahun terakhir tentang kebutuhan energi web yang sangat besar telah mendorong saya untuk melihat situs web saya sendiri dan melihat apa yang dapat saya lakukan untuk meminimalkan dampaknya. Bagian ini akan mencakup beberapa pengalaman saya dalam melakukan ini, serta pemikiran saya saat ini tentang mengoptimalkan situs web untuk emisi karbon , dan beberapa contoh praktis dari hal-hal yang dapat Anda lakukan untuk meningkatkan halaman Anda sendiri.

Tapi pertama-tama, sebuah pengakuan: Ketika saya pertama kali mendengar tentang dampak lingkungan dari situs web, saya tidak begitu percaya. Bagaimanapun, digital seharusnya lebih baik untuk planet ini, bukan?

Saya telah terlibat dalam berbagai kelompok hijau dan lingkungan selama beberapa dekade. Selama itu, saya tidak dapat secara sadar mengingat siapa pun yang pernah mendiskusikan kemungkinan dampak lingkungan dari web . Fokusnya selalu pada pengurangan konsumsi dan menjauhi pembakaran bahan bakar fosil. Satu-satunya waktu Internet disebutkan adalah sebagai alat untuk berkomunikasi satu sama lain tanpa perlu menebang lebih banyak pohon, atau untuk bekerja tanpa perjalanan.

Jadi, ketika orang pertama kali mulai berbicara tentang Internet yang memiliki emisi karbon serupa dengan industri penerbangan, saya agak skeptis.

Emisi

Mungkin sulit untuk memvisualisasikan jaringan besar perangkat keras yang memungkinkan Anda mengirim permintaan halaman ke server dan kemudian menerima tanggapan kembali. Sebagian besar dari kita tidak tinggal di pusat data, dan kabel yang membawa sinyal dari satu komputer ke komputer lain sering terkubur di bawah kaki kita. Ketika Anda tidak dapat melihat proses dalam tindakan, semuanya bisa terasa sedikit seperti keajaiban — sesuatu yang tidak terbantu oleh desakan perusahaan tertentu untuk menambahkan kata-kata seperti "cloud" dan "tanpa server" ke nama produk mereka.

Akibatnya, pandangan saya tentang Internet untuk waktu yang lama sedikit fana, semacam fatamorgana. Namun, ketika saya mulai menulis artikel ini, saya melakukan sedikit eksperimen pemikiran: Berapa banyak perangkat keras yang dilalui sinyal dari komputer tempat saya menulis untuk keluar dari rumah?

Jawabannya cukup mengejutkan: 3 kabel cat, switch, 2 adaptor powerline, router dan modem, kabel RJ11, dan kabel listrik beberapa meter. Tiba-tiba, fatamorgana itu mulai terlihat lebih kokoh.

Tentu saja, web (apa pun, dengan ekstensi, situs web yang kami buat) memang memiliki jejak karbon. Semua server, router, sakelar, modem, repeater, lemari telepon, konverter optik-ke-listrik, dan tautan satelit Internet harus dibuat dari logam yang diekstraksi dari Bumi, dan dari plastik yang dimurnikan dari minyak mentah. Untuk kemudian menyediakan data ke sekitar 20 miliar perangkat yang terhubung di seluruh dunia, mereka perlu mengkonsumsi listrik, yang juga melepaskan karbon ketika dihasilkan (bahkan listrik terbarukan tidak netral karbon, meskipun jauh lebih baik daripada bahan bakar fosil).

Mengukur secara akurat berapa emisi itu mungkin tidak mungkin — setiap perangkat berbeda dan energi yang memberi daya dapat bervariasi sepanjang hari — tetapi kita bisa mendapatkan gambaran kasar dengan melihat angka tipikal untuk konsumsi daya, basis pengguna, dan segera. Salah satu alat yang menggunakan data ini untuk memperkirakan emisi karbon dari satu halaman adalah Kalkulator Karbon Situs Web. Menurutnya, rata-rata halaman yang diuji “menghasilkan 1,76 gram CO2 per tampilan halaman”.

Jika Anda sudah terbiasa menganggap pekerjaan yang Anda lakukan pada dasarnya tidak berbahaya bagi lingkungan, realisasi ini bisa sangat mengecewakan. Kabar baiknya adalah, sebagai pengembang, kita dapat melakukan banyak hal tentang hal itu.

Bacaan yang disarankan : Bagaimana Meningkatkan Kinerja Situs Web Dapat Membantu Menyelamatkan Planet

Kinerja Dan Emisi

Jika kita ingat bahwa melihat situs web menggunakan listrik dan menghasilkan listrik melepaskan karbon, maka kita akan tahu bahwa emisi halaman harus sangat bergantung pada jumlah pekerjaan yang harus dilakukan server dan klien untuk menampilkan halaman. Juga, jumlah data yang diperlukan untuk halaman tersebut, dan kerumitan rute yang harus dilaluinya, akan menentukan jumlah karbon yang dilepaskan oleh jaringan itu sendiri.

Misalnya, mengunduh dan merender example.com kemungkinan akan mengonsumsi listrik jauh lebih sedikit daripada beranda Apple, dan juga akan jauh lebih cepat. Akibatnya, apa yang kami katakan adalah bahwa emisi tinggi dan pemuatan halaman yang lambat hanyalah dua gejala dari penyebab mendasar yang sama.

Tentu saja sangat baik untuk membicarakan hubungan ini secara teori, tetapi memiliki beberapa data dunia nyata untuk mendukungnya akan menyenangkan. Untuk melakukan hal itu, saya memutuskan untuk melakukan sedikit penelitian. Saya menulis program antarmuka baris perintah sederhana untuk mengambil daftar 500 situs web paling populer di Internet, menurut MOZ, dan memeriksa beranda mereka terhadap PageSpeed ​​Insights Google dan Kalkulator Karbon Situs Web.

Beberapa pemeriksaan kehabisan waktu (seringkali karena halaman yang dipermasalahkan terlalu lama untuk dimuat), tetapi secara total, saya berhasil mengumpulkan hasil untuk lebih dari 400 halaman pada 14 Juli 2021. Anda dapat mengunduh ringkasan hasil untuk memeriksa diri sendiri tetapi untuk memberikan indikasi visual, saya telah memplotnya dalam bagan di bawah ini:

Seperti yang Anda lihat, meskipun variasi antar situs web individual sangat tinggi, ada kecenderungan kuat menuju emisi yang lebih rendah dari halaman yang lebih cepat. Rata-rata emisi untuk situs web dengan skor PageSpeed ​​100 adalah sekitar 1 gram karbon, yang meningkat menjadi hampir 6 gram diproyeksikan untuk situs web dengan skor 0. Saya merasa sedikit meyakinkan bahwa, meskipun ada banyak situs web dengan sangat rendah kecepatan dan emisi tinggi, sebagian besar hasil dikelompokkan di kanan bawah grafik.

Mengambil Tindakan

Setelah kami memahami bahwa sebagian besar emisi laman berasal dari kinerja yang buruk, kami dapat mulai mengambil langkah-langkah untuk menguranginya. Banyak hal yang berkontribusi pada emisi situs web berada di luar kendali kami sebagai pengembang. Kami tidak dapat, misalnya, memilih perangkat tempat pengguna mengakses halaman kami atau memutuskan infrastruktur jaringan yang dilalui permintaan mereka, tetapi kami dapat mengambil langkah-langkah untuk meningkatkan kinerja situs web kami.

Optimalisasi kinerja adalah topik yang luas, dan banyak dari Anda yang membaca ini mungkin memiliki lebih banyak pengalaman daripada saya, tetapi saya ingin menyebutkan secara singkat beberapa hal yang telah saya amati baru-baru ini ketika mengoptimalkan kecepatan pemuatan berbagai halaman dan emisi karbon.

Rendering Jauh Lebih Lambat di Seluler

Saya baru-baru ini mengerjakan ulang desain blog pribadi saya agar sedikit lebih ramah pengguna. Salah satu hobi saya adalah fotografi, dan situs web tersebut sebelumnya telah menampilkan gambar header tinggi penuh.

Sementara desain melakukan pekerjaan yang baik untuk menampilkan foto-foto saya, itu adalah rasa sakit untuk menggulir melewati, terutama ketika bergerak melalui halaman posting blog. Namun, saya tidak ingin kehilangan perasaan memiliki foto di header, dan akhirnya memutuskan untuk menggunakannya sebagai latar belakang untuk judul halaman.

Header full-height telah menggunakan srcset untuk membuat pemuatan secepat mungkin, tetapi gambarnya masih sangat besar di layar resolusi tinggi, dan waktu contentful paint (LCP) terlama saya di ponsel untuk desain lama hampir 3 detik. Keuntungan besar dari desain baru ini adalah memungkinkan saya untuk membuat gambar jauh lebih kecil, yang mengurangi waktu LCP menjadi sekitar 1,5 detik.

Pada laptop dan desktop, orang tidak akan melihat perbedaan, karena kedua versi kurang dari satu detik, tetapi pada perangkat seluler yang jauh lebih kuat, itu cukup dramatis. Apa efek dari perubahan ini pada emisi karbon? 0,31 gram per tampilan sebelum, 0,05 gram setelahnya. Decoding dan rendering gambar sangat memakan sumber daya , dan ini tumbuh secara eksponensial saat gambar menjadi lebih besar.

Ukuran gambar bukan satu-satunya hal yang dapat berdampak pada waktu untuk memecahkan kode; formatnya juga penting. Mercusuar Google sering merekomendasikan penyajian gambar dalam format generasi berikutnya untuk mengurangi jumlah data yang perlu diunduh, tetapi format baru seringkali lebih lambat untuk didekode, terutama di seluler. Mengirim lebih sedikit data melalui kabel lebih baik bagi lingkungan, tetapi ada kemungkinan bahwa mengkonsumsi lebih banyak energi untuk memecahkan kode dapat mengimbangi manfaat itu. Seperti kebanyakan hal, pengujian adalah kuncinya di sini.

Dari pengujian saya sendiri dalam mencoba menambahkan dukungan untuk pengkodean AVIF ke generator situs statis Zola, saya menemukan bahwa AVIF, yang menjanjikan ukuran file yang jauh lebih kecil daripada JPG dengan kualitas yang sama, membutuhkan waktu lebih lama untuk dikodekan; sesuatu yang menurut pengamatan bunny.net bahwa WebP mengungguli AVIF sebanyak 100 kali mendukung. Saat melakukan ini, server akan mengkonsumsi listrik, dan saya bertanya-tanya apakah, untuk situs web dengan jumlah pengunjung rendah, beralih ke format baru mungkin benar-benar akan meningkatkan emisi dan mengurangi kinerja.

Gambar, tentu saja, bukan satu-satunya komponen halaman web modern yang membutuhkan waktu lama untuk diproses. File JavaScript kecil, tergantung pada apa yang mereka lakukan, dapat memakan waktu lama untuk dieksekusi dan potensi jebakan yang sama seperti gambar akan berlaku.

Bacaan yang disarankan : Elemen img Rendah Hati Dan Vital Web Inti

Penambahan Perjalanan Pulang-Pergi

Hal lain yang dapat memberikan dampak mengejutkan pada kinerja dan emisi adalah dari mana data Anda berasal. Kebijaksanaan konvensional telah lama mengatakan bahwa melayani aset seperti kerangka kerja dari jaringan pengiriman konten pusat (CDN) akan meningkatkan kinerja karena mendapatkan data dari node lokal umumnya lebih cepat bagi pengguna daripada dari server pusat. jQuery, misalnya, memiliki opsi untuk dimuat dari CDN, dan pengelolanya mengatakan bahwa ini dapat meningkatkan kinerja, tetapi pengujian dunia nyata oleh Harry Roberts telah menunjukkan bahwa aset hosting sendiri umumnya lebih cepat.

Ini juga menjadi pengalaman saya. Saya baru-baru ini membantu situs web game meningkatkan kinerjanya. Situs web menggunakan kerangka kerja CSS yang cukup besar dan memuat semua aset pihak ketiganya melalui CDN. Kami beralih ke self-hosting semua aset dan menghapus komponen yang tidak digunakan dari kerangka kerja.

Tidak ada pengoptimalan yang menghasilkan perubahan visual pada situs web, tetapi bersama-sama mereka meningkatkan skor Lighthouse dari 72 menjadi 98 dan mengurangi emisi karbon dari 0,26 gram per tampilan menjadi 0,15.

Kirim Hanya Apa yang Anda Butuhkan

Ini mengarah dengan baik ke subjek pengiriman hanya data yang benar-benar mereka butuhkan kepada pengguna. Saya telah mengerjakan (dan mengunjungi) banyak, banyak situs web yang didominasi oleh stok gambar orang-orang berjas yang tersenyum satu sama lain. Tampaknya ada mentalitas di antara organisasi tertentu bahwa apa yang mereka lakukan benar-benar membosankan dan menambahkan foto entah bagaimana akan meyakinkan masyarakat umum sebaliknya.

Saya bisa memahami pemikiran di balik ini karena ada banyak bagian tentang bagaimana jumlah waktu yang dihabiskan orang untuk membaca menurun. Teks, kami berulang kali diberitahu, akan ketinggalan zaman; semua orang tertarik sekarang adalah video dan pengalaman interaktif.

Dari sudut pandang itu, stok foto dapat dilihat sebagai alat yang berguna untuk menghidupkan halaman, tetapi studi pelacakan mata menunjukkan bahwa orang mengabaikan gambar yang tidak relevan. Saat orang tidak melihat gambar Anda, gambar tersebut mungkin juga merupakan ruang kosong. Dan ketika setiap byte membutuhkan biaya, berkontribusi pada perubahan iklim, dan memperlambat waktu pemuatan, akan lebih baik bagi semua orang jika memang demikian.

Sekali lagi, apa yang dapat dikatakan untuk gambar dapat dikatakan untuk semua hal lain yang bukan merupakan konten inti halaman. Jika sesuatu tidak berkontribusi pada pengalaman pengguna dengan cara yang berarti, itu seharusnya tidak ada. Saya tidak sejenak menganjurkan agar kita semua mulai menyajikan halaman tanpa gaya — beberapa orang, seperti mereka yang menderita disleksia, menemukan blok besar teks sulit dibaca, dan pengguna lain hampir pasti akan menganggap halaman seperti itu membosankan dan pergi ke tempat lain — tetapi kita harus melihat secara kritis setiap bagian dari situs web kita untuk mempertimbangkan apakah mereka mendapatkan penghasilan.

Aksesibilitas dan Lingkungan

Area lain di mana kinerja dan emisi bertemu adalah di bidang aksesibilitas. Ada kesalahpahaman umum bahwa membuat situs web dapat diakses melibatkan penambahan atribut aria dan JavaScript ke halaman, tetapi seringkali apa yang Anda tinggalkan lebih penting daripada apa yang Anda masukkan, membuat situs web yang dapat diakses relatif ringan dan berkinerja.

Menggunakan Elemen Standar

MDN Web Docs memiliki beberapa tutorial yang sangat bagus tentang aksesibilitas. Dalam “HTML: Basis yang Baik untuk Aksesibilitas”, mereka membahas bagaimana fondasi terbaik dari situs web yang dapat diakses terletak pada penggunaan elemen HTML yang benar untuk konten. Salah satu bagian artikel yang paling menarik adalah di mana mereka mencoba membuat ulang fungsionalitas elemen button menggunakan div dan JavaScript khusus.

Ini jelas merupakan contoh minimal, tetapi saya pikir akan menarik untuk membandingkan ukuran versi tombol ini dengan yang menggunakan elemen HTML standar. Contoh tombol palsu dalam kasus ini memiliki berat sekitar 1.403 byte yang tidak terkompresi, sedangkan button yang sebenarnya dengan lebih sedikit JavaScript dan tanpa gaya memiliki berat 746 byte. Tombol div juga secara semantik tidak berarti dan, oleh karena itu, jauh lebih sulit bagi orang-orang dengan pembaca layar untuk digunakan dan bot untuk diurai.

Bacaan yang disarankan : SVG yang Dapat Diakses: Pola Sempurna Untuk Pengguna Pembaca Layar

Ketika ditingkatkan, hal-hal semacam ini membuat perbedaan. Mengurai markup dan JavaScript minimal lebih mudah untuk browser, seperti juga lebih mudah bagi pengembang.

Pada skala yang lebih besar, saya baru-baru ini memfaktorkan ulang HTML situs web tempat saya bekerja — melakukan hal-hal seperti menghapus atribut judul yang berlebihan dan mengganti div s dengan lebih banyak persamaan semantik. Halaman asli memiliki struktur seperti berikut (konten dihapus karena privasi dan singkatnya):

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

Dengan konten lengkap, ini memiliki berat 34.168 byte.

Setelah refactoring, strukturnya seperti ini:

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

Beratnya 32.805 byte.

Perubahan saat ini sedang berlangsung, tetapi markup sudah jauh lebih mudah diakses menurut WebAIM, Lighthouse, dan pengujian manual. Ukuran file juga telah berkurang, dan, ketika rata-rata waktu dari lima profil di Chrome, waktu untuk mengurai HTML telah berkurang sekitar 2 milidetik.

Ini jelas merupakan perubahan kecil dan mungkin tidak akan membuat perbedaan persepsi bagi pengguna. Namun, senang mengetahui bahwa setiap byte merugikan pengguna dan lingkungan — membuat situs web dapat diakses juga dapat membuatnya sedikit lebih ringan.

Video

Versi HTML Project Gutenberg dari The Complete Works of William Shakespeare berukuran sekitar 7,4 MB tidak terkompresi. Menurut Otoritas Android dalam “Berapa Banyak Data yang Sebenarnya Digunakan YouTube?”, video YouTube 360p memiliki berat sekitar 5 hingga 7,5 MB per menit rekaman dan 1080p sekitar 50 hingga 68. Jadi, untuk jumlah bandwidth yang sama dengan semua drama Shakespeare , Anda hanya akan mendapatkan sekitar 7 detik video definisi tinggi. Video juga sangat intensif untuk dikodekan dan didekode, dan ini mungkin merupakan faktor utama yang memperkirakan emisi karbon Netflix setinggi 3,2 KG per jam.

Sebagian besar video mengandalkan komponen visual dan pendengaran untuk menyampaikan pesannya, dan ukuran file yang besar memerlukan tingkat konektivitas tertentu . Ini jelas membatasi siapa yang dapat mengambil manfaat dari konten tersebut. Membuat video dapat diakses adalah mungkin tetapi jauh dari sederhana, dan banyak situs web tidak mengganggu.

Jika video hanya pernah diperlakukan sebagai bentuk peningkatan progresif, ini mungkin tidak akan menjadi masalah, tetapi saya telah kehilangan hitungan berapa kali saya telah mencari sesuatu di web, dan satu-satunya cara untuk menemukan informasi yang saya diinginkan adalah dengan menonton video. Di YouTube, jumlah rata-rata pengguna bulanan tumbuh dari 20 juta pada 2006 menjadi 2 miliar pada 2020. Vimeo juga memiliki basis pengguna yang terus berkembang.

Terlepas dari banyaknya pengunjung ke situs web berbagi video, banyak situs web yang paling populer tampaknya tidak sepenuhnya mematuhi undang-undang aksesibilitas. Berbeda dengan ini, berbagai jenis teknologi bantu dirancang untuk membuat teks biasa dapat diakses oleh berbagai macam orang sebanyak mungkin. Teks juga mudah dikonversi dari satu format ke format lainnya, sehingga dapat digunakan dalam sejumlah konteks yang berbeda.

Seperti yang dapat kita lihat dari contoh Shakespeare, teks biasa juga sangat hemat ruang, dan memiliki jejak karbon yang jauh lebih rendah daripada bentuk informasi ramah manusia lainnya yang dikirimkan di web.

Video bisa menjadi hal yang hebat, dan banyak orang belajar paling baik dengan menonton proses dalam tindakan, tetapi juga membuat beberapa orang keluar dan memiliki biaya lingkungan. Untuk menjaga situs web kami seringan dan inklusif mungkin, kami harus memperlakukan teks sebagai bentuk komunikasi utama sedapat mungkin, dan menawarkan hal-hal seperti audio dan video sebagai tambahan.

Bacaan yang Disarankan : Mengoptimalkan Video Untuk Ukuran Dan Kualitas

Kesimpulannya

Mudah-mudahan, pandangan singkat tentang pengalaman saya dalam mencoba membuat situs web lebih baik untuk lingkungan telah memberi Anda beberapa ide untuk dicoba di situs web Anda sendiri. Ini bisa sangat mengecewakan untuk menjalankan halaman melalui Kalkulator Karbon Situs Web dan diberi tahu bahwa itu bisa mengeluarkan ratusan kilogram CO2 per tahun. Untungnya, ukuran web yang tipis dapat memperkuat perubahan positif maupun negatif, dan bahkan perbaikan kecil segera ditambahkan ke situs web dengan ribuan pengunjung seminggu.

Meskipun kami melihat hal-hal seperti situs web berusia 25 tahun meningkat 39 kali lipat setelah didesain ulang, kami juga melihat situs web dibuat untuk menggunakan data sesedikit mungkin, dan orang-orang pintar mencari cara untuk menghadirkan WordPress dalam 7 KB. Jadi, agar kami dapat mengurangi emisi karbon situs web kami, kami perlu membuatnya lebih cepat — dan itu menguntungkan semua orang .

Bacaan lebih lanjut

• Sampah di Seluruh Dunia, Gerry McGovern
• “Apakah WebP Benar-Benar Lebih Baik Dari JPEG?”, Johannes Siipola
• “Membuat Jamstack Lambat? Tantangan Diterima.”, Steve Keep, CSS-Tricks
• “Bisakah Internet Menjadi Hijau?”, Pertanyaan Iklim, BBC
• “Bisakah Pusat Data Anda Tidak Hanya Memberi Daya pada Situs Web Anda, Tetapi Juga Menumbuhkan Salad Anda?”, Tom Greenwood, Wholegrain Digital
• Aliansi Web yang Lebih Baik (proyek saya sendiri)
• Manifesto Web Berkelanjutan