I started thinking more seriously about the environmental side of websites through performance work.
Most website performance conversations begin in a fairly predictable place. A page is taking too long to load, images are heavier than they should be, JavaScript has grown over time or the site feels slower on a phone than it does on a desktop machine. At first, those conversations usually sound like UX (user experience) conversations, because slow websites frustrate people and make simple tasks feel harder than they need to be.
The more websites I built and maintained, the more I started thinking about the energy cost behind those decisions. A large image sent to a mobile device does not just affect a Lighthouse score. The device has to download it, decode it, render it and keep enough of the page active for the visitor to use it. One wasteful decision does not sound particularly serious on its own, however the same decision repeated across thousands of visits, over months and years, starts to feel much harder to ignore.
I don’t think most websites are built wastefully because developers don’t care. More often, the waste appears slowly. A script gets added for one feature, a background video gets added during a redesign, a tracking tool gets added because somebody wants more reporting, then a year later the site is heavier than anyone remembers it being. Nobody sat down and decided to make the website inefficient. It happened one small decision at a time.
That is usually how I think about lower-energy website development. It is not about turning every website into a plain HTML document with no character. It is about asking whether each part of the page is doing enough useful work to justify the cost of loading it, running it and maintaining it.
Browsers Help, But They Shouldn’t Have To Do Everything
Modern browsers already do a lot of work to reduce unnecessary energy use. They can slow down background tabs, manage rendering more intelligently and avoid spending effort on parts of a page the visitor cannot currently see. That work is useful, but I don’t think it should become an excuse for careless development. If a website constantly asks the browser to run timers, animate hidden elements or fetch information nobody is looking at, the browser is left cleaning up decisions that could have been avoided earlier.
That is where the development decisions matter. Responsive images, lighter scripts, sensible CSS and fewer unnecessary background tasks all reduce the amount of work a device has to do. I have become more careful with things like will-change, because it can be useful when applied deliberately, but it can also encourage the browser to prepare for changes that may not actually matter. Small technical decisions like that are easy to overlook because they rarely feel dramatic during development.
The way I tend to look at it now is fairly simple. If an element is not visible, it probably should not be working hard. If a section of the page is not being used, it probably should not be asking for data. If an animation is decorative, it should not keep running forever. Those are not complicated ideas, but they do change how a site feels over time, especially on battery-powered devices.
A visitor might not describe the difference in technical terms. They may not know that a script is polling too often or that an animation is keeping the GPU busy. They will notice that the page feels heavy, the phone gets warm or the battery drops faster than expected. That experience matters as much as the visual design.
Timers And Background Work
One of the first places I look is JavaScript running in the background.
It is surprisingly easy for a website to end up with several setInterval or setTimeout functions doing small jobs independently. One script checks for updates, another rotates content, another watches for interface changes and another keeps a component refreshed. Each one might look harmless in isolation, but together they can keep the browser doing regular work long after the visitor has stopped interacting with the page.
I prefer to question whether that work needs to happen on a fixed schedule at all. Sometimes the better answer is to run the task when something actually changes, or when the visitor performs an action. If regular checks are genuinely needed, I would rather coordinate them through a single process than have several unrelated timers scattered through the codebase. That makes the behaviour easier to understand and usually reduces needless CPU activity.
This is one of those areas where the environmental argument and the maintenance argument point in the same direction. Fewer background tasks means less work for the device, but it also means fewer things for a developer to trace later. If a page starts behaving strangely six months after launch, a handful of predictable background processes is much easier to reason about than a collection of timers added at different stages of the project.
The important part is not removing every timer from a website. Some are useful. The important part is knowing why they exist, how often they run and whether the visitor benefits from that work happening repeatedly.
Animations That Only Work When They Need To
Animations can improve a website when they help the visitor understand what is happening. A menu opening, a panel expanding or a piece of feedback after an action can make an interface feel more understandable. The problem starts when animations run continuously for no practical reason. Animated GIFs, looping background effects and permanent loading-style movement can keep a device working even when the visitor is not getting anything useful in return.
I have become much more careful about when animations start. If something only appears halfway down the page, it does not need to animate while the visitor is still at the top. IntersectionObserver is useful here because it allows animations or effects to begin when an element actually enters the viewport. That means the browser is not spending effort on visual behaviour the visitor cannot see.
I also prefer CSS transitions and CSS animations where they make sense, rather than controlling every movement through JavaScript. Browsers are generally better at managing declarative animations, especially when tabs move into the background or the device needs to save power. That does not mean JavaScript animation is wrong, but it should have a reason beyond habit.
There is also a UX side to this. Constant movement can become tiring, particularly when someone is trying to read or complete a task. Respecting reduced-motion preferences, avoiding unnecessary loops and keeping animation purposeful all help the experience feel calmer. The same decisions also reduce wasted processing, which is why this part of web development sits across both usability and energy use.
Network Requests And Polling
Network activity is another area where waste can hide.
A website that repeatedly asks the server for new information every few seconds might seem responsive during testing, but that pattern can become expensive over time. The browser has to wake up, make the request, wait for the response and decide what to do next. If the answer is usually “nothing has changed”, then most of that work was unnecessary.
I usually start by asking how fresh the information really needs to be. Some features need live updates. Many do not. A dashboard used actively during the day may need to update more often than a small content block on a marketing page. A notification system might justify a persistent connection, while a simple status message may only need to refresh when the visitor interacts with the page.
Where live behaviour is genuinely needed, WebSockets or Server-Sent Events can sometimes make more sense than constant polling. In other cases, a longer interval or an update triggered by user action is enough. The point is to make the website ask for information when there is a good reason, rather than because a timer was easy to add during development.
This also affects hosting and server load. Every unnecessary request has to be handled somewhere. Reducing network chatter makes the visitor’s device do less work, but it also reduces the amount of pointless traffic the server has to deal with. On a small site that might feel minor, but on a busy site those repeated requests can become part of the site’s normal operating cost.
Images, Videos And The Cost Of Visual Decisions
Images are usually one of the easiest places to make a website lighter.
I have seen plenty of sites where large images were uploaded because they looked good on a designer’s screen, then squeezed into much smaller spaces on the actual page. The browser still has to download the larger file, even if the visitor only sees it at a fraction of the size. That is wasteful from a performance point of view, but it is also wasteful from an energy point of view because the device is doing unnecessary work before the visitor has even started using the page properly.
I tend to think about media in terms of its actual use on the page. If an image is displayed in a small card, it should not be served as a huge file. If a mobile layout uses a different crop, the device should not be forced to download an image intended for a large desktop screen. Compression, correct dimensions and modern image formats are not glamorous parts of web development, but they make a real difference to the day-to-day behaviour of a site.
Video needs even more care. A well-used video can explain something quickly, show a product properly or help someone make a decision. A background video that autoplays because the page felt empty during design is harder to justify. Video files are heavy, and if they load automatically they consume bandwidth and power before the visitor has chosen to watch anything.
My preference is to make video intentional. Let the visitor decide to play it, avoid loading more than is needed and don’t use moving media as decoration unless it genuinely improves the page. That approach is better for performance, better for accessibility and usually better for the person trying to get information from the site.
Hosting And Measuring The Site
The code is only part of the picture.
At some point, the website has to be hosted somewhere, and the electricity used to serve those pages matters. I don’t think hosting choice should be treated as an afterthought, especially for websites with consistent traffic. A provider using renewable energy or making serious efforts to reduce the impact of its infrastructure can make the same website less wasteful over time.
I also think measurement helps, even when the measurement is imperfect. Tools like Website Carbon can give a useful estimate of how heavy a site is and how that might translate into emissions. I would not treat any single score as the full truth, because websites vary by page, traffic source, device and hosting setup. I do think tools like that are useful because they make the issue visible.
That visibility changes the development conversation. Instead of saying a page “feels heavy”, you can start looking at the specific reasons. Large assets, excessive scripts, repeated requests and unnecessary third-party tools become easier to question when there is some kind of measurement attached to them. The score is not the goal, but it can point you towards decisions worth reviewing.
This is also where long-term maintenance matters. A site might launch in a good state and still become heavier over the next year. New scripts get added, old sections are hidden rather than removed and media libraries fill up with files that are no longer used. Regular reviews stop that drift from becoming normal.
Choosing Tools With Some Restraint
I have nothing against modern JavaScript tools or front-end libraries. They are useful when the project needs them. The problem is when the size and behaviour of the tooling is out of proportion with the actual website being built. A small content-led website should not need the same amount of client-side JavaScript as a complex web application.
This is something I try to think about early in a project. What does the website actually need to do in the browser? Which parts need to be interactive? Which parts could be rendered simply and cached properly? Those questions affect performance, but they also affect how much processing happens on the visitor’s device every time the site loads.
Third-party scripts deserve the same attention. Analytics, chat widgets, tracking pixels and embedded tools can all be useful, but each one adds another request, another script and another possible source of slow behaviour. The cost is rarely obvious when the script is added. It becomes obvious later when the page is harder to debug, slower to load and heavier than the original build suggested.
I prefer to treat every dependency as something that needs to earn its place. If it helps the business or the visitor enough to justify the cost, fine. If nobody can explain why it is still there, it probably needs removing.
Sustainable UX Is Mostly About Reducing Waste
Sustainable UX sounds like it should be a separate discipline, but a lot of it comes back to basic product thinking.
If someone can find what they need quickly, they spend less time moving through unnecessary pages. If the navigation is clear, they do not need to reload several sections of the site before reaching the right information. If the content answers the question properly, they are less likely to bounce between pages trying to piece the answer together.
That might sound like a small thing, but website behaviour repeats. A confusing structure does not waste effort once. It wastes effort every time someone uses it. Over weeks and months, poor navigation creates more page views than necessary, more searches than necessary and more frustration than necessary.
Good SEO can help here too, although I think about it less as traffic generation and more as route planning. If someone searches for a specific answer, the best outcome is that they land on the page that answers it. Sending them through a generic landing page, then making them hunt for the useful content, creates more work for the visitor and more work for the website.
That is why I see UX and lower-energy design as closely connected. A clear website usually wastes less of the visitor’s time, and a website that wastes less time often wastes fewer resources.
Cleaning Up After The Website Has Been Live
Websites rarely stay clean by accident.
A site might launch with tidy templates, carefully compressed assets and a sensible set of scripts. A few months later, a campaign gets added. Then a landing page is built quickly. Then an old feature is replaced but the original code is left behind because removing it feels risky. Over time the website carries decisions that are no longer visible to the people using it.
I think this is where maintenance becomes part of sustainability. Removing unused CSS, deleting old scripts, clearing redundant media and reviewing third-party tools all help keep the website lighter. That work is not as exciting as launching a new feature, but it often makes the site better for everyone using it.
It also makes future development easier. A cleaner codebase is easier to change, easier to reason about and less likely to surprise you when something breaks. From a business perspective, that matters because every future update depends on the condition of what already exists.
The environmental benefit sits alongside that. Less unused code means fewer bytes transferred, less parsing, less processing and less pointless work repeated across every visit. It is practical maintenance with a wider benefit.
What I Take From This
I don’t think environmentally conscious web development needs to be dramatic.
Most of the useful decisions are fairly ordinary. Serve the right image size. Avoid scripts that run without a reason. Don’t load video before someone asks for it. Keep the codebase clean. Choose hosting with some thought. Question third-party tools before adding them, and question them again later when nobody remembers why they were added.
The important part is treating those decisions as part of normal website development rather than a separate ethical exercise added at the end. A lighter website is usually faster, easier to maintain and better for visitors on slower connections or battery-powered devices. It also asks less from the infrastructure behind it.
That is the part I keep coming back to. A website does not need to be stripped of personality to waste less energy. It just needs decisions that are easier to justify when you look at them closely. If a feature improves the experience, supports the business and makes sense technically, it probably has a place. If it exists because nobody questioned it, that is usually where the waste begins.
Leave a Reply