In the last post I discussed ideas for defining a “embodied energy” for a web page. Similar to physical products produced by Industrial Design and Interior Design/Architecture, a web page or site required a specific amount of energy and resources for its creation. This embodied energy constitutes the overall “carbon footprint” of a web page (if carbon-based fuel is used to provide the energy), and is a result of decisions in design, programming, hours spent creating the design, workstation power, and company/team organization.
In this section I will look at energy of use. For a web page, this is the energy need to:
- Maintain page code and media on a server, day to day
- Page request from an end-user
- Assemble a page from databases, included files, and media files
- Download a page and its assets
- Render the page on the client’s computer
- Static use of the web page
- Interactivity with the web page during its use
Let’s look at each section in turn:
Maintenance on a server – This is the energy and resources used when a page is not being assembled or downloaded. For rapid response, the server must remain on, even if there is no access to the site. For shared servers and clouds this is the chunk of the overall hardware, with the associated electricity needed to keep it active, allocated to a particular site.
Possible components of maintenance:
- Hard drive and system board power, divided by the slice being used by the filesystem to store the files.
- Power being used by non-web resources, like databases or media streaming servers that help assemble the page while they are “idling”, and not assembling a page for download.
Page request – This is the energy needed to send a page request from the client computer to the server. It consists of energy needed to form and push the request out of the client computer, and the energy needed to hop the request over to the server. While the Internet tends to blind us to geographic distance, energy use by a request from a distant client should be greater than one that is local.
Page assembly – This could be very intensive. If server-side programming like PHP, Java, ASP.NET is used to construct a web page with database help, there may be multiple processes or servers that have to be “fired up”. What’s needed is a way to calculate the burst of power needed to grab data and media, and shove them out onto the network.
Page download – This is the amount of energy needed to run the routers, repeaters, transponders, etc., that constitute the network. Since the Internet runs as a ‘dumb’ network, we may have a variable number of “hops” through these devices (as well as store-and-forward servers for email) that have to be figured out. Geographic location of the servers will be important, though the Internet is generally seen as removing physical location as a consideration in hosting.
This can also feed onto the real “green-ness” of a web hosting service. Many hosting companies listing themselves as “green” are located near renewable energy sources. But the geographic location of these sources may reduce the efficiency of transmission, if the average page has to go through lots of hops to get to its typical destination.
Page Rendering – This component of the overall energy of use consists of cpu work done on the client side to render the page, and any subsequent energy needed to display the rendered page.
Static use – For many pages, the user’s primary interaction will be to simply read the page and go on. The energy used at this point is the energy needed to maintain the page onscreen.
In the next section I’ll consider the end-life of a web page – when it is deleted, or, more commonly, upgraded or changed so it is a new page.