Bagaimana Meningkatkan Kinerja Situs Web Dapat Membantu Menyelamatkan Bumi

Anda mungkin tidak sering memikirkannya, tetapi Internet menggunakan listrik dalam jumlah yang sangat besar. Listrik ini perlu diproduksi di suatu tempat. Di sebagian besar negara, ini berarti pembakaran bahan bakar fosil. Ini, pada gilirannya, berarti bahwa jejak karbon Internet telah berkembang ke titik di mana ia mungkin telah melampaui perjalanan udara global, dan ini menjadikan Internet sebagai mesin berbahan bakar batu bara terbesar di Bumi.

Laporan Kesehatan Internet Mozilla 2018 menyatakan bahwa — terutama ketika Internet berkembang ke wilayah baru — “keberlanjutan harus menjadi prioritas yang lebih besar.” Tetapi sebagaimana adanya, situs web tumbuh semakin gemuk, yang berarti bahwa permintaan energi Internet terus tumbuh secara eksponensial.

Sementara itu, dampak perubahan iklim semakin parah dan semakin banyak dari tahun ke tahun. Sebagian besar ilmuwan iklim mengaitkan meningkatnya keganasan dan frekuensi peristiwa cuaca ekstrem di seluruh dunia dengan perubahan iklim, yang sebagian besar mereka kaitkan dengan aktivitas manusia. Sementara beberapa orang mempertanyakan sains, bahkan perusahaan minyak terbesar di dunia sekarang menerimanya, dan mengakui bahwa model bisnis mereka perlu diubah.

Setiap negara di Bumi (kecuali AS), telah menandatangani Perjanjian Iklim Paris. Meskipun AS secara kontroversial menarik diri, banyak individu, kota, negara bagian, dan perusahaan paling berpengaruh di Amerika — yang mewakili lebih dari separuh populasi dan ekonomi AS — telah mempertahankan komitmen mereka terhadap perjanjian melalui inisiatif America's Pledge.

Sebagai pengembang web, dapat dimengerti untuk merasa bahwa ini bukan masalah yang kami pengaruhi, tetapi ini tidak benar. Banyak upaya sedang dilakukan untuk memperbaiki situasi di web. Green Web Foundation memelihara database host web yang terus berkembang yang sepenuhnya didukung oleh energi terbarukan atau setidaknya berkomitmen untuk menjadi netral karbon. Pada tahun 2013, A List Apart menerbitkan Desain Web Berkelanjutan oleh James Christie. Selama tiga tahun terakhir, konferensi SustainableUX telah melihat para ahli dalam keberlanjutan web berbagi pengetahuan mereka di berbagai disiplin ilmu berbasis web.

Sejak 2009, Greenpeace telah menekan perusahaan Internet besar untuk membersihkan campuran energi mereka melalui kampanye Clicking Clean. Sebagian sebagai hasil dari kampanye ini, Google mengumumkan tahun lalu bahwa untuk pertama kalinya telah membeli energi terbarukan yang cukup untuk menyamai 100% konsumsi globalnya untuk operasi.

Jadi, selain menyalakan server dengan energi terbarukan, apa lagi yang bisa dilakukan pengembang web tentang perubahan iklim?

“Anda Tidak Dapat Mengelola Apa yang Tidak Dapat Anda Ukur”

Mungkin kemenangan terbesar dalam hal membuat situs web lebih berkelanjutan adalah bahwa kinerja, pengalaman pengguna, dan keberlanjutan semuanya terjalin dengan rapi. Metrik utama untuk mengukur keberlanjutan produk digital adalah penggunaan energinya. Ini termasuk pekerjaan yang dilakukan oleh server, klien dan jaringan komunikasi perantara yang mengirimkan data di antara keduanya.

Dengan mengingat hal itu, mungkin hal pertama yang perlu dipertimbangkan adalah bagaimana kita mengukur penggunaan energi situs web kita? Ini sebenarnya adalah usaha yang lebih sulit daripada yang Anda bayangkan, dan sulit untuk mendapatkan data yang tepat di sini. Namun, ada beberapa fallback bagus yang dapat kita gunakan yang menunjukkan penggunaan energi. Ini termasuk transfer data (yaitu berapa banyak data yang harus diunduh browser untuk menampilkan situs web Anda) dan penggunaan sumber daya dari perangkat keras yang melayani dan menerima situs web. Metrik yang jelas di sini adalah penggunaan CPU, tetapi penggunaan memori dan bentuk penyimpanan data lainnya juga berperan.

Transfer data adalah salah satu hal yang dapat kita ukur dengan cukup mudah. Semua browser utama menyediakan alat pengembang yang memungkinkan kami mengukur aktivitas jaringan. Pada tangkapan layar di bawah ini, misalnya, kita dapat melihat bahwa memuat situs web Majalah Smashing untuk pertama kalinya hanya memerlukan transfer data di bawah satu megabita. Alat pengembang Firefox sebenarnya memberi kami dua angka: yang pertama adalah ukuran file yang tidak terkompresi yang telah ditransfer, dan yang terakhir adalah ukuran terkompresi.

Alat yang paling umum untuk mengompresi aset saat melintasi jaringan adalah gzip, jadi perbedaan antara kedua angka tersebut biasanya merupakan hasil kerja gzip. Angka terakhir ini menunjukkan berapa banyak data yang benar-benar telah dikirim dan yang harus diperhatikan.

Catatan : Ada banyak alat lain yang memberi kami metrik untuk transfer data termasuk WebPagetest yang sangat dihormati.

Untuk mengukur penggunaan CPU, Chrome memberi kami Pengelola Tugas granular yang menunjukkan jejak memori, penggunaan CPU, dan aktivitas jaringan dari masing-masing tab. Untuk yang lebih berani/teknis, perintah top (tabel proses) menyediakan metrik serupa di sebagian besar sistem operasi mirip Unix seperti macOS dan Ubuntu. Secara umum, kami juga dapat menjalankan perintah teratas di server mana pun yang memiliki akses shell.

Untungnya, ada upaya seperti WebsiteCarbon dan Ecograder yang berusaha menerjemahkan metrik ini menjadi angka CO2 tertentu (dalam kasus WebsiteCarbon) atau skor (dalam kasus Ecograder).

Desain Web Berkelanjutan

Sekarang kita tahu bagaimana mengukur dampak dari situs kita, saatnya untuk memikirkan bagaimana kita dapat mengoptimalkan berbagai hal untuk membuatnya lebih berkelanjutan, lebih berkinerja, dan secara umum pengalaman yang lebih baik untuk digunakan.

Ada beberapa karya yang sudah ada yang dapat kami gunakan untuk membantu kami di sini. Pada tahun 2016, O'Reilly menerbitkan "Merancang Untuk Keberlanjutan" oleh Tim Frick. Dalam buku ini, Tim membawa kita pada tur tentang mengapa dan bagaimana desain berkelanjutan. Tetapi kita juga dapat memanfaatkan banyak ide, pembicaraan konferensi, dan artikel yang ada — meskipun tidak memiliki fokus eksplisit pada keberlanjutan — memiliki tumpang tindih yang besar dengan filosofi desain web yang berkelanjutan. Contoh yang sangat bagus di sini adalah proyek sampingan Brad Frost, "Death To Bullshit", artikel dan pembicaraan Heydon Pickering tentang menulis kode yang lebih sedikit, dan posting blog Adam Silver, "Merancang Untuk Performa Aktual."

Jika kita sedang mendesain ulang situs web secara lengkap, atau memulai yang baru dari awal, kita bisa mulai dengan beberapa pertanyaan tingkat tinggi di sini. Misalnya, apa yang sebenarnya pantas atau perlu ada di beranda? Dan lebih khusus lagi, nilai apa yang dibawa oleh setiap elemen di beranda? Seperti yang dikatakan Heydon Pickering:

“Fitur situs web yang paling berkinerja, dapat diakses, dan mudah dipelihara adalah yang tidak Anda buat sejak awal.”

Saya bekerja di tim VIP WordPress.com, jadi dalam nada ini, saya memutuskan untuk menantang diri saya sendiri dengan menyusun tema WordPress minimalis untuk melihat seberapa jauh saya dapat mengambil teknik desain web yang berkelanjutan. Hasilnya adalah sebuah tema bernama Susty, dan itu dapat dilihat dalam aksi di situs web terlampir yang saya kumpulkan: sustywp.com. Dalam contoh khusus itu, situs web dikirimkan hanya dalam transfer data lebih dari 6KB, yang terasa bagus mengingat situs web rata-rata sekitar 1,5MB.

Jadi, apa yang saya lakukan? Nah, saya akan memberitahu Anda.

Kurangi Permintaan Jaringan

Seperti yang telah saya uraikan di atas, permintaan jaringan adalah sesuatu yang dapat kita ukur dengan mudah, sehingga permintaan tersebut menjadi titik awal yang baik. Dalam menyatukan Susty, saya perhatikan ada sejumlah permintaan HTTP yang terjadi yang tampaknya tidak perlu. Misalnya, WordPress menggabungkan beberapa CSS dan JavaScript yang mendeteksi penggunaan emoji dan memastikan emoji tidak muncul sebagai karakter ilegal. Tidak ada yang salah dengan ini, tetapi jika Anda tidak berencana untuk menggunakan emoji, atau Anda senang dan yakin bahwa berbagai default sistem akan membantu Anda, Anda dapat mencegahnya memuat.

Ini menunjukkan penghematan yang relatif sedikit, tetapi dengan menetapkan filosofi memangkas kode dan permintaan yang tidak diinginkan dari halaman kami, kami dapat membuat peningkatan kinerja yang jauh lebih signifikan. Sebagai contoh:

• Apakah kita memuat seluruh jQuery untuk beberapa operasi DOM dasar?
  Bisakah kita mencapai tujuan yang sama dengan JavaScript murni? Anda dapat membaca tentang penghapusan kode mati lebih lanjut (alias gemetar pohon) di posting ini untuk Google oleh Jeremy Wagner.
• Apakah kita memiliki korsel gambar?
  Apakah kita benar-benar membutuhkan semua gambar itu? Apakah mereka secara signifikan meningkatkan pengalaman pengguna? Atau bisakah kita menguranginya menjadi hanya satu, citra yang kuat? Atau bahkan secara acak menampilkan salah satu pilihan gambar, untuk memberikan kesan dinamis kepada pengguna yang kembali? Omong-omong, penelitian yang telah dilakukan di sini menunjukkan bahwa sebagian besar pengguna tidak menyukai atau terlibat dengan carousel.
• Jika kami menggunakan banyak gambar, apakah kami mendapat manfaat dari menyediakan gambar kami menggunakan format WebP untuk browser yang mendukungnya?
  Untuk waktu yang lama, dukungan WebP sangat terbatas. Tetapi dengan Firefox yang akan mulai mendukungnya di versi 65 (dijatuhkan pada Januari 2019), hanya masalah waktu sebelum orang-orang yang tersesat seperti Safari mengejar ketinggalan.
• Apakah kami memuat ratusan kilobyte font web?
  Apakah kami menggunakan semua font web yang kami muat? Apakah kita bahkan membutuhkan font web? Sebagian besar perangkat saat ini memiliki tumpukan font yang setengah layak, bisakah kita menentukan daftar font yang ingin kita lihat disusun berdasarkan preferensi? Jika kita harus menggunakan font web, kita harus memastikan font kita berkinerja sebaik mungkin.
• Apakah kami menyematkan video YouTube?
  Video YouTube yang disematkan biasanya menambahkan sekitar satu megabita transfer data bahkan sebelum ada orang yang berinteraksi dengannya. Jika hanya sebagian kecil dari pengguna kami yang benar-benar akan duduk dan menonton video yang disematkan di situs web kami, bisakah kami menautkannya saja?

Cermati Semuanya

Dalam nada ini, kami juga dapat menginterogasi setiap aspek halaman kami. Apa yang benar- benar layak untuk berada di sana? Apakah sidebar kami menambahkan nilai nyata, atau kami hanya menempatkan satu di sana karena konvensi menentukan bahwa situs web memiliki sidebars? Jadi, kami telah menambahkan satu dan mengisinya dengan omong kosong.

Dengan Susty, saya telah bereksperimen dengan pendekatan yang agak tidak lazim untuk menurunkan navigasi ke halamannya sendiri. Ini memungkinkan saya untuk memiliki halaman yang dipreteli menjadi hal-hal yang benar-benar penting, dengan konten tambahan hanya dimuat atas permintaan eksplisit pengguna. Susty sangat ringan dan cepat sehingga saya menyadari melalui beberapa penelitian pengguna (alias mitra saya) bahwa pemuatan menu tidak benar-benar terasa seperti halaman baru, jadi saya memutuskan untuk membuatnya terlihat seperti overlay, dengan tanda silang ke abaikan yang sebenarnya hanya membawa Anda kembali ke halaman sebelumnya.

Selain membantu saya membuat halaman yang ringan dan menyenangkan, navigasi yang diturunkan juga menghilangkan kebutuhan akan kode sembunyikan/ungkap yang mewah untuk menampilkannya. Pada titik ini, saya ingin menjelaskan bahwa Susty adalah contoh dari mengambil teknik desain web berkelanjutan secara ekstrem (saya tidak menyarankan itu adalah pola dasar dari situs web yang bagus).

Tulis CSS Seperti Nenekmu

Ketika berbicara tentang peningkatan kinerja yang serius, kita harus ingat bahwa secara harfiah setiap karakter kode penting. Setiap karakter mewakili satu byte, dan bahkan setelah dikompresi oleh gzip, karakter tersebut masih bertambah berat. CSS adalah domain tempat kita sering melihat banyak bloat. Untungnya, ada semakin banyak alat yang semakin kompleks yang dapat membantu Anda menyingkirkan CSS yang tidak digunakan. Posting fantastis oleh Sarah Dayan ini menguraikan bagaimana dia mengurangi bundel CSS-nya dari 259KB menjadi 9KB!

Jika kita memulai dari awal, mungkin kita harus berpikir lebih dalam tentang bagaimana kita menulis CSS sejak awal. Heydon Pickering menulis posting yang sangat bagus tentang bagaimana kita dapat menulis CSS dengan cara yang sesuai dengan kekuatan bagaimana sintaks dirancang, dan bagaimana ini dapat membantu pengembang mencegah pengulangan. Heydon juga menunjukkan berapa banyak pemborosan yang terjadi dengan penggunaan div dan kelas yang berlebihan — baik dalam HTML maupun CSS.

Apa yang Anda Analisis?

Tampaknya telah menjadi lebih-atau-kurang di mana-mana di web bagi semua orang untuk menganalisis apa yang dilakukan pengunjung situs web mereka melalui alat seperti Google Analytics, KISSmetrics, Piwik, dll. Meskipun saya tidak ragu bahwa ada kasus penggunaan yang sah, apakah kita benar-benar perlu analitik di setiap situs web? Saya, misalnya, biasanya menambahkan Google Analytics ke setiap situs yang saya kelola sebagai hal yang biasa. Tetapi baru-baru ini saya sadar bahwa untuk sebagian besar situs web yang dipermasalahkan, ini adalah upaya yang hampir tidak ada gunanya: "Oh, enam orang datang ke pos ini melalui Facebook hari ini." Siapa peduli?

Kecuali Anda benar-benar membutuhkannya, dan Anda akan menganalisis dan bertindak berdasarkan data, buang saja analitik dan temukan cara yang lebih baik untuk menghabiskan waktu Anda daripada melongo melihat banyaknya orang yang mengunjungi situs web X hari ini.

Selain menambah bobot halaman Anda, penggunaan sesuatu seperti Google Analytics menimbulkan pertanyaan etis seputar data yang Anda kumpulkan atas nama pengguna Anda atas nama Google, yaitu ada alasan Google memberi Anda Analytics secara gratis.

Jangan Lupakan Dasar-dasarnya

Ada begitu banyak informasi di sekitar hari-hari ini tentang hal-hal berikut, tetapi kita tidak boleh berpuas diri dan melupakannya. Di samping semua hal di atas, kita harus selalu mengecilkan HTML, CSS, dan JavaScript, dan menggabungkannya jika perlu. Kita juga harus mengompres semua gambar untuk memastikan ukurannya sekecil mungkin, menggunakan format yang tepat dalam pengaturan yang tepat, dan menggunakan rendering progresif.

Kinerja Sisi Server

Sejauh ini, fokus kami hampir seluruhnya pada front-end, tetapi banyak dari hal ini menjadi tidak relevan jika kami juga tidak mengoptimalkan hal-hal di sisi server. Saya telah menyebutkannya beberapa kali, tetapi kita harus benar-benar mengaktifkan kompresi gzip setiap saat.

Kami harus membuat penyajian situs web kami semudah mungkin untuk server kami. Saya sebagian besar menggunakan Nginx, dan saya sangat menyukai cache FastCGI dan merasa sangat efisien. Jika Anda memiliki akses shell ke server Anda sendiri, berikut adalah posting yang menjelaskan cara mengkonfigurasinya. Ada lebih sedikit opsi teknis jika Anda tidak memiliki (atau tidak menginginkan) sebanyak mungkin kendali atas server Anda. Favorit tertentu di ruang WordPress adalah WP Super Cache.

Kita harus menggunakan HTTP2 melalui HTTPS. Menggunakan HTTPS membuka dunia teknologi web baru seperti pekerja layanan yang memungkinkan kita memperlakukan jaringan itu sendiri sebagai sesuatu yang bagus untuk dimiliki. Jika Anda ingin mempelajari lebih lanjut tentang ini, saya sangat merekomendasikan buku baru Jeremy Keith, “Going Offline.”

Catatan : Anda juga mungkin ingin menyelidiki Modul PageSpeed ​​Google, yang tersedia untuk Apache dan Nginx.

Terakhir, dampak terbesar yang dapat kami peroleh di sini adalah menghosting situs web kami di pusat data yang didukung oleh energi terbarukan. Di Inggris, saya sangat merekomendasikan Krystal dan Kualo dalam hal perusahaan tempat saya menghosting situs saya secara langsung. (Untuk direktori lengkap host web hijau, lihat The Green Web Foundation.)

Kesimpulannya

Saya harap saya telah meyakinkan Anda bahwa ada baiknya melakukan upaya untuk membuat situs web kami lebih berkelanjutan. Apalagi dalam prosesnya kami juga membuat website kami:

• Lebih berprestasi,
• Lebih ramah pengguna,
• Lebih mudah diakses,
• Lebih ramah server,
• Lebih baik dioptimalkan untuk mesin pencari.

Tanggapan yang dimiliki beberapa orang terhadap gagasan desain web yang berkelanjutan — yang bukannya tidak masuk akal — adalah bahwa hal itu tampaknya merupakan konsesi yang sangat kecil terhadap penyebab lingkungan. Tentu saja, seberapa besar pengaruh yang Anda dapat bergantung pada seberapa sibuk situs web yang Anda kerjakan. Namun selain membantu web menjadi sedikit lebih ramah lingkungan, desain web berkelanjutan pada dasarnya adalah praktik terbaik desain web.

Ada baiknya juga memikirkan untuk mengimbangi emisi karbon yang tidak dapat Anda hindari. Pengimbangan karbon terkadang dicemooh, dan dengan tujuan yang baik. Masalah utama dengan offset adalah bahwa biasanya jangka waktu dimana karbon akan diimbangi cukup panjang. Misalnya, dengan penanaman pohon, angka yang diberikan untuk jumlah penyerapan karbon biasanya didasarkan pada periode 100 tahun. Jadi, dalam hal pengurangan emisi karbon sekarang, itu bukan solusi. Tapi itu lebih baik daripada tidak sama sekali.

Moto myclimate adalah melakukan yang terbaik, dan mengimbangi sisanya. Saya telah menulis posting blog tentang menggulirkan skema offset karbon Anda sendiri. Saya juga sangat merekomendasikan inisiatif 1% Untuk Planet. Terakhir, jika Anda adalah pemilik bisnis dan ingin bergabung dengan aliansi perusahaan yang ingin melihat keadilan sosial, lingkungan, dan ekonomi yang lebih baik, lihat skema Perusahaan B Bersertifikat.