Tóm tắt nhanh: Thật không may, các trang web không thân thiện với môi trường như chúng ta mong muốn. Trong bài viết này, Berwyn Powell chia sẻ kinh nghiệm của mình trong việc cố gắng làm cho các trang web thân thiện hơn với môi trường. Hy vọng rằng điều này sẽ mang lại cho bạn một vài ý tưởng để thử áp dụng cho chính trang web của mình. Sẽ khá nản lòng khi bạn đưa một trang web vào công cụ Website Carbon Calculator và nhận được thông báo rằng nó có thể thải ra hàng trăm ki-lô-gam CO₂ mỗi năm. May mắn thay, quy mô khổng lồ của mạng lưới web có thể khuếch đại những thay đổi tích cực cũng như tiêu cực. Ngay cả những cải thiện nhỏ cũng sẽ nhanh chóng tích lũy trên các trang web có hàng nghìn lượt truy cập mỗi tuần.
Giống như nhiều nhà phát triển khác, những báo cáo trong vài năm gần đây về nhu cầu năng lượng khổng lồ của web đã thúc đẩy tôi xem xét lại các trang web của mình và tìm cách giảm thiểu tác động của chúng. Bài viết này sẽ đề cập đến một số trải nghiệm của tôi trong quá trình thực hiện việc đó, cũng như những suy nghĩ hiện tại của tôi về việc tối ưu hóa trang web nhằm giảm lượng khí thải carbon, cùng với một số ví dụ thực tiễn về những điều bạn có thể làm để cải thiện chính các trang của mình.
Nhưng trước tiên, một lời thú nhận: Khi tôi lần đầu tiên nghe về tác động môi trường của các trang web, tôi đã không thực sự tin điều đó. Rốt cuộc thì, kỹ thuật số vốn được cho là tốt hơn cho hành tinh này, phải không?
Tôi đã tham gia vào nhiều nhóm xanh và môi trường trong nhiều thập kỷ. Trong suốt khoảng thời gian đó, tôi không hề nhớ có ai từng thảo luận một cách rõ ràng về những tác động môi trường tiềm ẩn của web. Trọng tâm lúc nào cũng là giảm tiêu thụ và từ bỏ việc đốt nhiên liệu hóa thạch. Thời điểm duy nhất Internet được nhắc đến là khi nó được coi như một công cụ để giao tiếp với nhau mà không cần chặt thêm cây, hoặc để làm việc mà không cần phải đi lại hằng ngày.
Vì vậy, khi mọi người lần đầu tiên bắt đầu nói về việc Internet có lượng khí thải carbon tương đương với ngành hàng không, tôi đã hơi hoài nghi.
Khí thải carbon
Thật khó để hình dung ra mạng lưới phần cứng khổng lồ cho phép bạn gửi một yêu cầu đến máy chủ để lấy một trang web rồi nhận lại phản hồi. Hầu hết chúng ta không sống trong các trung tâm dữ liệu, và những sợi cáp truyền tín hiệu từ máy tính này sang máy tính khác thường được chôn sâu dưới chân chúng ta. Khi bạn không thể nhìn thấy quá trình đó diễn ra, tất cả có thể mang lại cảm giác như một phép màu — và điều này càng trở nên khó hiểu hơn khi một số công ty cứ khăng khăng thêm những từ như “đám mây” và “không máy chủ” vào tên sản phẩm của họ.
Vì điều này, trong một thời gian dài, quan điểm của tôi về Internet có phần mơ hồ, như một ảo ảnh. Tuy nhiên, khi tôi bắt đầu viết bài viết này, tôi đã thực hiện một thí nghiệm suy nghĩ nhỏ: Có bao nhiêu thiết bị phần cứng mà một tín hiệu phải đi qua từ chiếc máy tính tôi đang sử dụng để có thể truyền tải ra ngoài ngôi nhà?
Câu trả lời thật sự gây bất ngờ: để một tín hiệu thoát ra khỏi ngôi nhà, nó phải đi qua 3 dây cáp mạng (Cat cables), một bộ chuyển mạch (switch), 2 bộ chuyển đổi qua đường điện (powerline adapters), một bộ định tuyến và modem, một dây RJ11, cùng với nhiều mét dây điện. Điều này cho thấy rằng đằng sau một hành động tưởng chừng đơn giản trên Internet lại là cả một hệ thống phần cứng phức tạp, tiêu tốn năng lượng và để lại dấu chân carbon nhất định. “Ảo ảnh” về một không gian mạng vô hình, nhẹ nhàng với môi trường, thực ra đang dần hiện ra rõ ràng hơn như một hạ tầng vật chất khổng lồ, gắn liền với những vấn đề môi trường và công nghệ mà chúng ta cần quan tâm.
Tất nhiên, web (và mở rộng ra là các trang web mà chúng ta tạo ra) đều có dấu chân carbon. Tất cả các máy chủ, bộ định tuyến, bộ chuyển mạch, modem, bộ lặp tín hiệu, tủ viễn thông, bộ chuyển đổi quang – điện và các trạm truyền tín hiệu vệ tinh của Internet đều phải được sản xuất từ kim loại khai thác từ lòng đất và nhựa được tinh chế từ dầu thô. Sau đó, để cung cấp dữ liệu cho ước tính khoảng 20 tỷ thiết bị kết nối trên toàn cầu, chúng cần tiêu thụ điện năng – quá trình sản xuất điện này cũng phát thải carbon (ngay cả điện tái tạo cũng không hoàn toàn trung tính carbon, mặc dù chắc chắn tốt hơn rất nhiều so với nhiên liệu hóa thạch).
Việc đo lường chính xác lượng khí thải đó gần như là không thể — bởi mỗi thiết bị đều khác nhau và nguồn năng lượng cung cấp cho chúng cũng có thể thay đổi theo từng thời điểm trong ngày. Tuy nhiên, chúng ta có thể hình dung một cách tương đối thông qua các số liệu điển hình về mức tiêu thụ điện năng, số lượng người dùng, v.v. Một công cụ sử dụng dữ liệu này để ước tính lượng khí thải carbon của một trang web là Website Carbon Calculator. Theo công cụ này, một trang trung bình được kiểm tra “tạo ra 1,76 gam CO₂ cho mỗi lượt xem trang”.
Nếu bạn đã quen với việc nghĩ rằng công việc mình làm về cơ bản là vô hại đối với môi trường, thì nhận thức này có thể khiến bạn khá nản lòng. Tin tốt là, với vai trò là những nhà phát triển, chúng ta hoàn toàn có thể làm được rất nhiều điều để cải thiện tình hình này.
Tài liệu khuyến nghị: Làm thế nào việc cải thiện hiệu suất website có thể giúp cứu lấy hành tinh.
Hiệu suất và khí thải carbon
Nếu chúng ta nhớ rằng việc truy cập các trang web tiêu thụ điện năng và quá trình sản xuất điện năng thải ra carbon, thì có thể thấy rằng lượng khí thải của một trang web phụ thuộc rất nhiều vào khối lượng công việc mà cả máy chủ và máy khách phải xử lý để hiển thị trang đó. Bên cạnh đó, dung lượng dữ liệu cần thiết cho trang, cũng như mức độ phức tạp của lộ trình mà dữ liệu phải di chuyển, sẽ quyết định đến lượng carbon được phát thải bởi chính mạng lưới truyền tải.
Ví dụ, việc tải xuống và hiển thị example.com có khả năng tiêu thụ ít điện năng hơn nhiều so với trang chủ của Apple, và đồng thời cũng nhanh hơn. Thực chất, điều chúng ta đang nói ở đây là: lượng khí thải cao và tốc độ tải trang chậm chỉ là hai biểu hiện của cùng một nguyên nhân gốc rễ.
Tất nhiên, bàn luận về mối quan hệ này trên lý thuyết là một chuyện, nhưng có được dữ liệu thực tế để chứng minh thì sẽ thuyết phục hơn nhiều. Để làm điều đó, tôi đã quyết định tiến hành một nghiên cứu nhỏ. Tôi viết một chương trình giao diện dòng lệnh đơn giản để lấy danh sách 500 trang web phổ biến nhất trên Internet (theo MOZ), rồi kiểm tra trang chủ của chúng bằng cả Google’s PageSpeed Insights và Website Carbon Calculator.
Một số lượt kiểm tra đã bị quá thời gian (thường là do trang được kiểm tra mất quá lâu để tải), nhưng tổng cộng tôi đã thu thập được kết quả của hơn 400 trang vào ngày 14 tháng 7 năm 2021. Bạn có thể tải về bản tóm tắt kết quả để tự xem xét, nhưng để có cái nhìn trực quan hơn, tôi đã biểu diễn chúng trong biểu đồ dưới đây:
Như bạn có thể thấy, mặc dù sự khác biệt giữa từng trang web là rất lớn, nhưng có một xu hướng rõ rệt: các trang tải nhanh hơn thường có lượng khí thải thấp hơn. Lượng khí thải trung bình của những trang web có điểm PageSpeed là 100 vào khoảng 1 gam carbon, trong khi đó con số này tăng lên gần 6 gam đối với những trang web có điểm số bằng 0. Tôi cảm thấy hơi yên tâm khi nhận thấy rằng, mặc dù vẫn có nhiều trang có tốc độ rất chậm và mức phát thải cao, nhưng phần lớn kết quả lại tập trung ở góc dưới bên phải của biểu đồ.
Hành động
Khi đã hiểu rằng phần lớn lượng khí thải của một trang web bắt nguồn từ hiệu suất kém, chúng ta có thể bắt đầu thực hiện các bước để giảm thiểu chúng. Nhiều yếu tố góp phần tạo ra khí thải của một trang web nằm ngoài tầm kiểm soát của chúng ta với tư cách là nhà phát triển. Chẳng hạn, chúng ta không thể lựa chọn thiết bị mà người dùng sử dụng để truy cập trang web, cũng như không thể quyết định cơ sở hạ tầng mạng mà các yêu cầu của họ đi qua. Tuy nhiên, chúng ta hoàn toàn có thể thực hiện các biện pháp để cải thiện hiệu suất trang web của mình.
Tối ưu hóa hiệu suất là một chủ đề rộng, và có lẽ nhiều bạn đọc bài viết này còn có nhiều kinh nghiệm hơn tôi. Dù vậy, tôi muốn đề cập ngắn gọn đến một vài điểm mà gần đây tôi quan sát được trong quá trình tối ưu tốc độ tải và lượng khí thải carbon của nhiều trang web.
Việc render trên thiết bị di động chậm hơn rất nhiều
Gần đây, tôi đã thiết kế lại blog cá nhân của mình để giúp nó thân thiện hơn với người dùng. Một trong những sở thích của tôi là nhiếp ảnh, và trước đây trang web có sử dụng một hình ảnh tiêu đề (header) toàn màn hình.
Mặc dù thiết kế này thể hiện khá tốt các bức ảnh của tôi, nhưng việc cuộn qua nó lại vô cùng bất tiện, đặc biệt là khi di chuyển giữa các trang bài viết trên blog. Tuy vậy, tôi cũng không muốn mất đi cảm giác có một bức ảnh ở phần tiêu đề, và cuối cùng tôi đã chọn cách sử dụng ảnh đó làm nền cho tiêu đề trang.
Phần tiêu đề toàn màn hình trước đây đã sử dụng srcset để tải nhanh nhất có thể, nhưng hình ảnh vẫn rất lớn trên các màn hình có độ phân giải cao, và thời gian Longest Contentful Paint (LCP) trên thiết kế cũ khi truy cập bằng di động gần 3 giây. Một lợi thế lớn của thiết kế mới là cho phép tôi thu nhỏ hình ảnh đáng kể, từ đó giảm thời gian LCP xuống còn khoảng 1,5 giây.
Trên máy tính xách tay và máy tính để bàn, người dùng hầu như không nhận thấy sự khác biệt, bởi cả hai phiên bản đều tải trong chưa đến một giây. Tuy nhiên, trên các thiết bị di động kém mạnh mẽ hơn, sự khác biệt này là rất rõ rệt. Vậy tác động của thay đổi này đối với lượng khí thải carbon là gì? 0,31 gam cho mỗi lượt xem trước đó, giảm còn 0,05 gam sau đó. Việc giải mã và render hình ảnh là một quá trình tiêu tốn rất nhiều tài nguyên, và mức tiêu thụ này tăng theo cấp số nhân khi kích thước hình ảnh lớn hơn.
Kích thước hình ảnh không phải là yếu tố duy nhất ảnh hưởng đến thời gian giải mã; định dạng cũng đóng vai trò quan trọng. Công cụ Lighthouse của Google thường khuyến nghị sử dụng các định dạng hình ảnh thế hệ mới để giảm lượng dữ liệu cần tải xuống, nhưng các định dạng mới này thường chậm hơn trong quá trình giải mã, đặc biệt là trên thiết bị di động. Việc truyền ít dữ liệu hơn qua mạng chắc chắn tốt hơn cho môi trường, nhưng việc tiêu tốn nhiều năng lượng hơn để giải mã có thể làm mất đi lợi ích đó. Giống như hầu hết các vấn đề khác, việc kiểm thử thực tế là “key” trong trường hợp này.
Từ những thử nghiệm của riêng tôi khi cố gắng thêm hỗ trợ mã hóa AVIF cho trình tạo trang tĩnh Zola, tôi nhận thấy rằng AVIF — vốn hứa hẹn mang lại kích thước tệp nhỏ hơn nhiều so với JPG ở cùng mức chất lượng — lại mất thời gian mã hóa lâu hơn gấp nhiều lần. Điều này trùng khớp với quan sát của bunny.net, rằng WebP có thể vượt trội hơn AVIF tới 100 lần. Trong quá trình này, máy chủ phải tiêu thụ điện năng, và tôi tự hỏi liệu đối với các trang web có lượng truy cập thấp, việc chuyển sang định dạng mới này có thực sự làm tăng lượng khí thải và giảm hiệu suất hay không.
Tất nhiên, hình ảnh không phải là thành phần duy nhất của các trang web hiện đại cần nhiều thời gian xử lý. Các tệp JavaScript nhỏ, tùy thuộc vào những gì chúng thực hiện, cũng có thể mất nhiều thời gian để chạy và gặp phải những rủi ro tiềm ẩn tương tự như hình ảnh.
Tài liệu khuyến nghị: The Humble img Element And Core Web Vitals.
Các chuyến đi vòng tích tụ dần
Một yếu tố khác có thể gây ảnh hưởng đáng kể đến hiệu suất và lượng khí thải là nguồn dữ liệu của bạn đến từ đâu. Từ lâu, quan điểm phổ biến cho rằng việc cung cấp tài nguyên như framework thông qua mạng phân phối nội dung (CDN) sẽ cải thiện hiệu suất, bởi lấy dữ liệu từ các nút cục bộ thường nhanh hơn so với từ một máy chủ trung tâm. Ví dụ, jQuery có thể được tải từ CDN, và những người duy trì nó cho rằng điều này giúp tăng tốc độ, nhưng thử nghiệm thực tế của Harry Roberts đã chỉ ra rằng tự lưu trữ (self-hosting) tài nguyên thường nhanh hơn.
Đây cũng chính là trải nghiệm của tôi. Gần đây, tôi đã hỗ trợ một trang web trò chơi cải thiện hiệu suất. Trang web này sử dụng một framework CSS khá lớn và tải tất cả tài nguyên bên thứ ba thông qua CDN. Chúng tôi đã chuyển sang tự lưu trữ toàn bộ tài nguyên và loại bỏ các thành phần không sử dụng trong framework.
Những tối ưu hóa này không làm thay đổi bất kỳ yếu tố trực quan nào trên trang web, nhưng kết quả là điểm Lighthouse đã tăng từ 72 lên 98, đồng thời lượng khí thải carbon giảm từ 0,26 gam mỗi lượt xem xuống còn 0,15 gam.
Chỉ gửi những gì bạn cần
Điều này dẫn dắt người dùng đến chủ đề chỉ gửi cho họ những dữ liệu họ thực sự cần. Tôi đã làm việc (và truy cập) rất nhiều trang web tràn ngập hình ảnh stock về những người mặc vest đang mỉm cười với nhau. Dường như một số tổ chức có tâm lý cho rằng những gì họ làm thực sự nhàm chán và việc thêm ảnh bằng cách nào đó sẽ thuyết phục được công chúng.
Tôi có thể hiểu được phần nào suy nghĩ đằng sau điều này, bởi vì có rất nhiều bài viết về việc thời gian mọi người dành cho việc đọc đang giảm dần . Văn bản, như chúng ta vẫn thường được nghe, đang dần lỗi thời ; tất cả những gì mọi người quan tâm bây giờ là video và trải nghiệm tương tác.
Từ góc độ đó, ảnh stock có thể được xem là một công cụ hữu ích để làm sống động các trang web, nhưng các nghiên cứu theo dõi chuyển động mắt cho thấy mọi người thường bỏ qua những hình ảnh không liên quan . Khi mọi người không nhìn vào ảnh của bạn, chúng chẳng khác nào một khoảng trống. Và khi mỗi byte đều tốn tiền, góp phần gây biến đổi khí hậu và làm chậm tốc độ tải, thì sẽ tốt hơn cho tất cả mọi người nếu chúng thực sự liên quan.
Một lần nữa, những gì có thể nói về hình ảnh cũng có thể nói về mọi thứ khác không phải là nội dung cốt lõi của trang. Nếu có thứ gì đó không đóng góp ý nghĩa cho trải nghiệm của người dùng, thì nó không nên xuất hiện. Tôi không hề ủng hộ việc tất cả chúng ta bắt đầu cung cấp các trang không có định dạng — một số người, chẳng hạn như những người mắc chứng khó đọc, thấy những khối văn bản lớn khó đọc, và những người dùng khác gần như chắc chắn sẽ thấy những trang như vậy nhàm chán và sẽ tìm nơi khác — nhưng chúng ta nên xem xét kỹ lưỡng mọi phần trên trang web của mình để xem liệu chúng có xứng đáng với giá trị của chúng hay không.
Khả năng tiếp cận và môi trường
Một lĩnh vực khác mà hiệu suất và lượng khí thải hội tụ là khả năng truy cập. Có một quan niệm sai lầm phổ biến rằng việc tạo khả năng truy cập cho trang web bao gồm việc thêm ariacác thuộc tính và JavaScript vào trang, nhưng thường thì những gì bạn bỏ qua lại quan trọng hơn những gì bạn đưa vào, giúp trang web dễ truy cập trở nên tương đối nhẹ và hiệu suất cao.
Sử dụng các phần tử chuẩn
MDN Web Docs có một số hướng dẫn rất hay về khả năng truy cập. Trong bài viết ” HTML: Một Nền Tảng Tốt Cho Khả Năng Truy Cập “, họ trình bày cách nền tảng tốt nhất của một trang web dễ tiếp cận nằm ở việc sử dụng đúng các thành phần HTML cho nội dung. Một trong những phần thú vị nhất của bài viết là phần họ cố gắng tái tạo chức năng của một button thành phần bằng cách sử dụng div JavaScript tùy chỉnh.
Đây rõ ràng là một ví dụ tối thiểu, nhưng tôi nghĩ sẽ rất thú vị nếu so sánh kích thước của phiên bản nút này với phiên bản sử dụng các phần tử HTML chuẩn. Ví dụ về nút giả trong trường hợp này nặng khoảng 1.403 byte chưa nén, trong khi nút thật button với ít JavaScript hơn và không có kiểu dáng nào nặng 746 byte. div Nút này cũng sẽ vô nghĩa về mặt ngữ nghĩa, do đó, người dùng trình đọc màn hình và bot khó sử dụng hơn nhiều, cũng như khó phân tích cú pháp.
Đọc thêm : SVG có thể truy cập: Các mẫu hoàn hảo dành cho người dùng trình đọc màn hình
Khi được mở rộng, những điều này tạo nên sự khác biệt. Việc phân tích cú pháp mã đánh dấu tối thiểu và JavaScript dễ dàng hơn cho trình duyệt, cũng như cho các nhà phát triển.
Trên quy mô lớn hơn, gần đây tôi đang tái cấu trúc mã HTML của một trang web mà tôi đang làm việc — thực hiện những việc như loại bỏ các thuộc tính tiêu đề thừa và thay thế div“s” bằng các từ ngữ tương đương ngữ nghĩa hơn. Trang gốc có cấu trúc như sau (nội dung đã được xóa để đảm bảo tính riêng tư và ngắn gọn):
<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>
Với nội dung đầy đủ, nó nặng 34.168 byte.
Sau khi tái cấu trúc, cấu trúc giống như sau:
<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>
Nó nặng 32.805 byte.
Những thay đổi hiện đang được tiến hành, nhưng theo WebAIM, Lighthouse và thử nghiệm thủ công, mã đánh dấu đã dễ truy cập hơn nhiều. Kích thước tệp cũng đã giảm, và khi tính trung bình thời gian từ năm cấu hình trong Chrome, thời gian phân tích cú pháp HTML đã giảm khoảng 2 mili giây.
Đây rõ ràng là những thay đổi nhỏ và có lẽ sẽ không tạo ra bất kỳ sự khác biệt nào về mặt nhận thức đối với người dùng. Tuy nhiên, thật tốt khi biết rằng mỗi byte đều gây tổn hại cho người dùng và môi trường — việc làm cho trang web dễ truy cập cũng có thể giúp trang web nhẹ hơn một chút.
Video
Phiên bản HTML của The Complete Works of William Shakespeare trên Project Gutenberg có dung lượng khoảng 7,4 MB khi chưa nén. Theo Android Authority trong bài viết ” YouTube thực sự sử dụng bao nhiêu dữ liệu? “, một video YouTube 360p nặng khoảng 5 đến 7,5 MB cho mỗi phút quay và video 1080p nặng khoảng 50 đến 68 MB. Vì vậy, với cùng dung lượng băng thông như tất cả các vở kịch của Shakespeare, bạn sẽ chỉ có khoảng 7 giây video độ nét cao. Video cũng rất tốn kém để mã hóa và giải mã, và đây có lẽ là một yếu tố chính góp phần vào ước tính lượng khí thải carbon của Netflix lên tới 3,2 KG mỗi giờ.
Hầu hết video đều dựa vào cả yếu tố hình ảnh và âm thanh để truyền tải thông điệp, và kích thước tệp lớn đòi hỏi một mức độ kết nối nhất định . Điều này rõ ràng đặt ra những hạn chế đối với những người có thể hưởng lợi từ nội dung đó. Việc làm cho video dễ tiếp cận là điều có thể, nhưng không hề đơn giản, và nhiều trang web thậm chí còn không quan tâm đến điều đó.
Nếu video chỉ được coi là một hình thức nâng cao dần dần, thì có lẽ điều này sẽ không thành vấn đề, nhưng tôi đã không còn nhớ nổi bao nhiêu lần mình phải tìm kiếm thứ gì đó trên web, và cách duy nhất để tìm được thông tin tôi muốn là xem video. Trên YouTube, số lượng người dùng trung bình hàng tháng đã tăng từ 20 triệu vào năm 2006 lên 2 tỷ vào năm 2020. Vimeo cũng có lượng người dùng không ngừng tăng lên .
Mặc dù có lượng truy cập khổng lồ vào các trang web chia sẻ video, nhiều trang web phổ biến nhất dường như không tuân thủ đầy đủ luật về khả năng truy cập . Ngược lại, nhiều loại công nghệ hỗ trợ được thiết kế để giúp văn bản thuần túy dễ tiếp cận với càng nhiều người càng tốt. Văn bản cũng dễ dàng chuyển đổi từ định dạng này sang định dạng khác, vì vậy nó có thể được sử dụng trong nhiều bối cảnh khác nhau.
Như chúng ta có thể thấy từ ví dụ về Shakespeare, văn bản thuần túy cũng cực kỳ tiết kiệm không gian và có lượng khí thải carbon thấp hơn nhiều so với bất kỳ hình thức thông tin thân thiện với con người nào khác được truyền trên web.
Video có thể rất tuyệt vời, và nhiều người học hiệu quả nhất khi xem một quy trình thực tế, nhưng nó cũng bỏ sót một số người và gây ra những tổn hại về môi trường. Để giữ cho trang web của chúng ta gọn nhẹ và bao quát nhất có thể, chúng ta nên coi văn bản là hình thức giao tiếp chính bất cứ khi nào có thể, và cung cấp thêm các nội dung như âm thanh và video.
Đọc đề xuất :
Tối ưu hóa kích thước và chất lượng video
Kết luận
Hy vọng rằng, bài viết ngắn gọn này về kinh nghiệm của tôi trong việc nỗ lực cải thiện môi trường cho website đã cung cấp cho bạn một vài ý tưởng để áp dụng trên website của mình. Việc chạy một trang web qua Công cụ tính toán lượng khí thải carbon của website và nhận được thông báo rằng nó có thể thải ra hàng trăm kg CO2 mỗi năm có thể khá nản lòng. May mắn thay, quy mô khổng lồ của web có thể khuếch đại cả những thay đổi tích cực lẫn tiêu cực, và ngay cả những cải tiến nhỏ cũng sẽ sớm được tích lũy trên các website có hàng nghìn lượt truy cập mỗi tuần.
Mặc dù chúng ta đang chứng kiến những thứ như một trang web 25 năm tuổi tăng gấp 39 lần về kích thước sau khi được thiết kế lại, chúng ta cũng thấy các trang web được thiết kế để sử dụng ít dữ liệu nhất có thể , và những người thông minh đang tìm cách cung cấp WordPress với dung lượng 7 KB . Vì vậy, để giảm lượng khí thải carbon từ các trang web của mình, chúng ta cần phải làm cho chúng nhanh hơn — và điều đó mang lại lợi ích cho tất cả mọi người .
Tài nguyên khác
- Chất thải toàn cầu , Gerry McGovern
- “ WebP có thực sự tốt hơn JPEG không? ”, Johannes Siipola
- “ Làm Jamstack chậm lại? Chấp nhận thử thách. ”, Steve Keep, CSS-Tricks
- “ Internet có bao giờ có thể xanh được không? ”, Câu hỏi về khí hậu, BBC
- “ Trung tâm dữ liệu của bạn không chỉ cung cấp năng lượng cho trang web mà còn có thể trồng rau xà lách của bạn? ”, Tom Greenwood, Wholegrain Digital
- Liên minh Web Tốt hơn (dự án của riêng tôi)
- Tuyên ngôn Web bền vững
Đọc thêm
- Tại sao việc tối ưu hóa điểm Lighthouse không đủ để có một trang web nhanh
- Thành công trong việc mở rộng quy mô: Những hiểu biết sâu sắc và bài học thực tế
- Cách chúng tôi tối ưu hóa hiệu suất để phục vụ đối tượng toàn cầu
- Phát triển web đang trở nên quá phức tạp và có thể là lỗi của chúng ta
Tác giả: Berwyn Powell. Bài viết được dịch từ: Giảm phát thải Carbon trên Web.
