Recommendations for Actions

Support Caching on the Server Side

The caching capabilities of HTTP are designed to reduce the amount of HTTP requests and transferred data volume significantly. Content that is dynamically generated by scripts or programs on the server side is usually not treated to be cacheable and therefore not tagged with caching metadata by default.
However, there may be cases where dynamic content changes less frequently than once for each request. Therefore caching it may be possible without the risk of presenting obsolete data to visitors. In our opinion the following tasks are important:

• retrieving presented content dynamically out of content repositories
• presenting dynamically generated charts as images

Concerning the first point, well-engineered content management systems may be configured to use some kind of caching strategy and to support Expires and Last-Modified headers. Hence, we focus on websites or web applications that are not run via a Content Management System (CMS), but are implemented directly in scripts and programs. For instance, assuming a web based application that collects power meter readings of a family home, calculates its power consumption daily and presents it in charts on a website, the Last-Modified date can be set to the date and time where the last meter reading has been inserted into the database.
We recommend that web developers implement support for Expires and Last-Modified headers in their web programs and scripts whenever possible, to decrease the transferred data volume and thus power consumption. The following example code shows how this may be realized in principle, with the PHP scripting language. A more sophisticated example is given by Nottingham (2009).

Configure HTTPs Caching Support

Since the configuration of the user’s web browser cannot be affected by web designers or administrators, they have to focus on the server-side configuration aspects of caching. Where approx. 80% of the web users have their browsers configured for caching, however 20% always have an empty cache (Theurer 2007). The inclusion of caching metadata by the web server will significantly decrease the amount of HTTP requests and HTTP responses. Caching in HTTP/1.1 is designed to reduce

• the need to send requests to servers ("expiration" mechanism) and
• the need to send full responses back to the clients ("validation" mechanism).

The validation mechanism does not reduce the amount of HTTP-requests but it reduces the payload of the HTTP responses that are sent back to the client and thus addresses network bandwidth reduction (Fielding et al. 1999, p. 74).

In order to facilitate the expiration mechanism of HTTP servers, administrators can specify an Expires or Cache-Control header in their response. The Expires header as described with HTTP/1.0 (Berners- Lee 1996, p. 41) defines the absolute date after which the response is expected to be stale. One minor problem with the Expires header is that it uses explicit date and time strings and thus requires server and client clocks to be synchronized (Crocker 1982, p. 26; Souders 2007, p. 22). Beginning with HTTP/1.1 that limitation has been overcome with the Cache- Control header. It uses the max-age directive to define the seconds, which the requested resource may remain in the cache. To stay compatible with older HTTP clients that do not support the HTTP/1.1 protocol, one can define the Expires header alongside with the Cache-Control header. In that case the Cache-Control header overrides the Expires header.

The validation mechanism is utilized by HTTP clients that have a resource entry in their cache that has already expired. In that case the client may send a conditional HTTP request to the server. This conditional HTTP request looks exactly like a normal HTTP request but in addition it carries a so called "validator" that may be used by the server to decide whether the resource requested by the client is still up to date or needs to be refreshed. In case that it needs a refresh the new data is sent to the client, otherwise the server responds with the HTTP status code "304 Not modified". There are two validators that may be used: Last-Modified dates or Entity Tag cache validators. In case of the Last-Modified date a cache entry is considered to be valid if the requested resource has not been modified since the given Last- Modified date. An Entity Tag is a unique identifier for a specific version (entity) of a resource (Fielding et al. 1999, p. 85). The calculation of the Entity Tags depends on the implementation of the web server. The HTTP/1.1 specification states that servers should send both, Entity Tag and Last-Modified values in their responses. HTTP/1.1 clients are forced by the specification to use Entity Tags in cache-conditional requests if provided by the server. In addition clients should also apply a Last-Modified date if one was set (Fielding et al. 1999, p. 86).

In order to reduce the total amount of HTTP requests or HTTP payload sizes we suggest configuring the client cache support properly. This means:

1. setting far future expiration dates and cachecontrol headers for resources that infrequently change
2. setting Last-Modified headers and Entity Tags for all resources that do not need recalculation on subsequent requests (mainly static content)

A simple example configuration fragment for the popular Apache web server may look like this:

Configure the Web Browser

The former sections focused on the web designers’ and administrators’ options to reduce network traffic and thus power consumption. As was mentioned, administrators have no possibility to influence the browser configuration directly, like e.g. forcing the browser to cache delivered content according to the corresponding HTTP response header fields. Web users can also contribute a large part to the reduction of network traffic and power consumption by configuring the caching capabilities of their web browsers in a way that far future expiry dates can take effect, or by installing web browsers that are fully compatible with GZIP based HTTP compression. Furthermore, there is a lot of advertisement on web pages today that causes additional, but avoidable network traffic.

Thus, we recommend that one should

• configure large caches in Web browsers
• not clear caches during browser shutdown
• use browsers supporting GZIP compression
• use advertisement blockers to block advertisement images and Flash

Visualize Green Power Status of a Website

In order to assess whether a website is hosted with renewable energies, tools like the "Power Indicator" (Naumann 2008b) can help users by visualizing the "green power state" of a website.

Apply "Green IT" on the Client Side

Of course, users of a website also have the possibility to obtain renewable energies within their companies or households. It is also recommended to utilize the available energy management options of client computers.

References

• Naumann, S., Gresk, S. & Schäfer, K., 2008b. How Green is the Web? Visualizing the Power Quality of Websites. In: Möller, A., Page, B. & Schreiber, M. eds., 2008. EnviroInfo 2008. Environmental Informatics and Industrial Ecology, 22nd International Conference on Environmental Informatics. Aachen: Shaker Verlag, pp. 62-65.

Acknowledgements

This text has been published by INSTICC Press:

• Dick, Markus; Naumann, Stefan; Held, Alexandra: Green Web Engineering. A Set of Principles to Support the Development and Operation of "Green" Websites and their Utilization during a Website’s Life Cycle. Filipe, Joaquim; Cordeiro, José (eds.): WEBIST 2010 : Proceedings of the 6th International Conference on Web Information Systems and Technologies, April 7 - 10, 2010, Valencia, Spain, Volume 1. Setúbal: INSTICC Press, 2010, pp. 48 - 55.