The ecological impact of IT services is now known. By becoming aware of the environmental consequences of IT tools, digital ecology takes on its full meaning. When developing a website, an application, or any other IT service, we have seen that eco-design needs to be taken into account as early as possible in the project. Today, let’s talk about the best practices to follow to develop an ecological website.
Objective: reduce the resources used by the site
The goal is simple: you have to reduce energy consumption, thus reducing the number of devices and the cumulative power required to run the Web application. In other words :
- Reduce the number of requests,
- Reduce the volume of data exchanged,
- Limit processing, especially on the server-side.
Use a repository of good practices for digital ecology
Before getting to the heart of the matter, know that there is a repository of rules published by CNumR ( Collectif Conception Numérique Responsable ). Note that the rules below do not come from this repository but come from my design and development experience. I, therefore, invite you to complete them by purchasing Ecoconception web: the 115 best practices.
Use browser caches
The first step towards a less consuming site: use cache. Or rather caches! In 2014, I explained to you that there are many caching mechanisms to optimize your site’s performance. This point is crucial: a modern website weighs several MB or even ten MB for the most greedy. By using the caches available to us, we avoid the transfer of many files during navigation.
It would help if you played on the following cache levels:
- the browser cache consists of using the storage of files on the client’s web browser via the HTTP Cache-Control and Expires headers. It is managed by the browser itself and avoids the systematic loading of static resources: CSS, JS, images, etc.
- The browser storage of using space provided by the browser allows you to store data (or SessionStorage LocalStorage). For example, rather than loading drop-down list X times, load it once and store it on the client-side; you will avoid requests on the server.
Use application caches
In line with the previous good practice, it is imperative to set up caches on the server-side. Thus, many unnecessary processing operations are avoided: calls to the database, data calculations, generation of pages, management of referential data, etc.
It would help if you played on the following cache levels:
- the OPCode cache (OPcache) now embedded natively since PHP 5.5,
- the application caches of your architecture: database cache ( Mysql Query Cache, for example), application data caches ( APCu, Redis, Memcached, etc.).
Use server caches
Last level of cache: the storage of pages on the Web server-side. Modern servers allow static pages to be stored without calling on the backend, which generates the HTML page: Varnish, Nginx, Apache offer to cache static pages to avoid their systematic generation ( Apache mod_cache or Nginx proxy_cache ).
You can also use ESI (Edge Side Includes) or SSI (Server Side Includes) to cache chunks of pages while dynamic elements are loaded asynchronously. The most common example is a “shopping cart” component on an e-commerce website that is necessarily dynamic while the rest of the page is static (product page, category, etc.).
Limit the number of requests
The right request is the one that doesn’t go away. Caches help reduce them when browsing, but the initial loading of pages is no exception to this rule. Must, therefore :
- Concatenate and minify your assets (JS and CSS),
- Depending on the case, completely delete your JS and CSS files and directly include the JS and CSS code as an inline in the HTML code (with GZIP compression active),
- Use sprites for your icons. The best is to use icon fonts including only the icons used),
Enable GZIP compression
Another good practice to reduce the bandwidth required to load your site: enable GZIP compression on your Web server. In Apache, this is the mod_deflate module. Under Nginx, look at the side of the ngx_http_gzip module.
Resize and compress images
Images are very bandwidth-consuming resources. You may apply the techniques outlined above and end up with an initial HTML page at 20Kb; if you then load several mega images, your work will be useless. So be sure to:
- Resize your images according to the use made of them. 1600 × 900 images used as a 250 × 100 logo are unnecessary: resize the image correctly. Especially since we also reduce the browser’s processing, which will no longer have to force the resizing on display.
- Compress your images. On JPEG, you can easily go down to quality between 80 and 90% without a big loss. On PNG, be sure to use a lossless compression tool (TinyPNG, for example).
Load the images in lazy-loading
The lazy-loading images are a technique to load images only when you need it, i.e., you scrolled above your page. Thus, the images not displayed on your browser are not loaded at the initialization of the page, but only when they become visible (in fact, a little before).
This technique, which is easy to implement, is interesting on all access devices, but particularly on smartphones, for two reasons:
- the bandwidth in 3G or 4G is lower: your site will therefore load faster if the invisible images are not loaded,
- the surface of the site displayed is smaller on a smartphone (the viewport which designates the visible surface in your browser): so potentially you will have to load less image)
Use responsive images
The configuration of responsive images allows browsers to choose which images to load according to different criteria: screen size, pixel density (for HD or 4K screens, for example), the actual surface used by the image when it is displayed. This technique adjusts the loaded images, and therefore the amount of data transferred, as needed: you do not need an image of several MB on mobile, for example.
Avoid image sliders
We often tend to put an image slider at the start of the site to give a dynamic dimension. Ecologically speaking, this is a mistake (and ergonomically as well, by the way, as users rarely see images other than the first).
Delete videos
Exit the videos automatically played at the initialization of the page or the animated page backgrounds. Video streams represent almost 60% of global Internet traffic. Netflix alone is 15%… In many situations, videos have no interest other than seeing something moving on the screen. Delete them and, if they are really useful, turn off the autoplay.
Avoid full page reloads
Have you set up an automatic reload of your page every 60 seconds? On the one hand, it is unbearable for users … On the other hand, it is needlessly consuming resources. When necessary, favor AJAX requests that only load what is useful or WebSockets if you need real-time. On this last solution, I’m looking for information about resource consumption, contact me if you have any!
Be sober on scheduled tasks: AJAX, CRON …
Whether for AJAX requests or CRONs, there is no point in planning a data refresh every 10 seconds if the information only updates twice a day. Maybe 30 minutes is enough. All recurring scheduled tasks must be carefully dimensioned to avoid unnecessarily excessive consumption.
Avoid storing unnecessary data
Computer servers host an incalculable amount of unnecessary data (think of your mailbox). Databases: it’s the same. We generally collect much more data than necessary for the proper functioning of the application. Be reasoned about the data collected, particularly on the logs and application traces that are constantly growing. Not only will the planet thank you, but you will also take a step towards GDPR compliance (which involves justifying the use of users’ data).
Conclusion
You will have understood: the line of conduct to adopt when developing an eco-responsible website or application is to limit the transfer of resources between the client and the server.
Do you want to launch your online business presence? Are you looking for Web Development in Pakistan to upgrade your web design? Count on us to get competing Web Design and Development services.