Sustainable Web at maneko

Six ideas.

1. 01

   Build only what needs to exist.

   What we choose not to build is a design decision too.

   Every feature, integration, page, animation and dependency comes with a cost.

   That cost is not only development time. It can also mean more code, more maintenance, more data transfer, more computation and more complexity.

   So we try not to begin by asking "what else can we add?". We begin with a different question.

   Does this need to exist?

   In practice

   • We evaluate features against real user and business needs.
   • We try to reduce unnecessary pages and repeated content.
   • We see technology as a tool rather than the objective.
   • When a simpler solution is enough, we question additional technical complexity.
   • The fact that something can be built is not enough reason to build it.

   Build less. Build better.

2. 02

   Every byte should earn its place.

   Everything we ask someone to download should have a reason to be there.

   High-resolution imagery, custom type, video and motion are powerful design tools. We are not interested in removing them simply to make a number smaller.

   But sending people significantly more data than the experience requires is not good design either.

   The goal is not to remove visual quality. It is to deliver it with less unnecessary weight.

   In practice

   • We prepare images for the sizes in which they will actually be displayed.
   • We consider modern and efficient media formats where appropriate.
   • We aim to serve appropriate image variants across different screens.
   • We defer media that is not needed for the initial experience.
   • We question unnecessarily large image and video assets.
   • We optimise SVGs and other static resources.
   • We try not to send font weights and character sets that the experience does not use.

   We can protect the identity of the work, without making it heavier than it needs to be.

3. 03

   Your device shouldn't work harder than it has to.

   Data transfer is only part of the story.

   The code we send to a browser also needs to be processed by someone's device.

   That is why we look beyond file size and consider how much work an experience asks a device to perform.

   In practice

   • We try to reduce unnecessary JavaScript.
   • We remove unused code and dependencies.
   • When native web technologies can solve a problem well, we question additional libraries.
   • We evaluate intensive motion and interactions for performance as well as appearance.
   • We defer non-critical work where appropriate.
   • We choose rendering and application architectures based on the needs of the project rather than habit.

   An interface can be ambitious. The user's device should not have to pay an unnecessary price for it.

4. 04

   Every third party has to justify its seat at the table.

   Every external service added to a site brings new weight with it.

   • Analytics
   • Chat tools
   • Video embeds
   • Maps
   • Marketing pixels
   • Social feeds
   • Experimentation platforms

   Every third-party service added to a website can introduce more requests, more code, more data transfer and sometimes new questions about privacy.

   That is why we prefer to add third parties because they are needed, not because they are expected.

   In practice

   • We want to know why every third-party service exists.
   • We remove services that are no longer being used.
   • We consider lighter alternatives.
   • We try to avoid loading unnecessary third-party resources immediately.
   • Where appropriate, services can wait for user interaction or consent.
   • We consider the value of an integration alongside its performance, privacy and maintenance cost.

   Convenience isn't free.

5. 05

   Host with intention.

   Even a well-optimised website has to run somewhere.

   We do not treat infrastructure as an entirely invisible technical detail.

   When hosting decisions are within our control, energy sourcing, infrastructure efficiency, resource allocation and the transparency of the provider can become part of the decision.

   In practice

   • We try to avoid unnecessary over-provisioning.
   • We design caching and distribution strategies around actual project needs.
   • We question unnecessary storage and excessive logging.
   • When infrastructure is our decision, we examine the evidence behind environmental claims made by providers.
   • Where appropriate, we prefer independently verifiable lower-impact hosting options.

   Infrastructure is not under maneko's control on every project. When it is not, we want to say so clearly.

   We only claim what we can verify.

6. 06

   Measure, don't guess.

   The easiest way to say something is "more sustainable" is to say it without measuring it.

   We prefer the opposite.

   We do not believe there is one perfect measurement for the environmental impact of a digital product. Nor can its entire impact be reduced to a single number.

   But measuring useful indicators is a better starting point than measuring nothing at all.

   Where possible, we establish technical baselines and follow how they change.

   We look at things like

   Transferred Data

   The amount of data actually transferred to the user.

   Page Weight

   The resources required to deliver an experience.

   Network Requests

   How many separate network requests a page requires.

   JavaScript

   How much JavaScript is transferred and executed.

   Images & Media

   The weight of visual and media resources.

   Core Web Vitals

   Performance indicators that help us understand real user experience.

   Third-party impact

   The additional cost introduced by external services.

   Hosting status

   Whether environmental claims associated with the infrastructure can be independently verified.

   Estimated CO₂e

   An estimate generated from transferred data and the calculation model being used.

   The word in that last one matters:

   estimated.

   This is not a reading taken from an electricity meter. It is the output of a model.

The Maneko Sustainable Web Standard

Product & Scope

Reducing features and complexity that do not serve a meaningful need.

Images & Media

Delivering media with appropriate sizes, formats and loading strategies.

Typography

Protecting visual identity without carrying unnecessary font weight.

Front-end

Managing code, dependencies and computational cost.

Third Parties

Evaluating external services against both their value and their cost.

Network & Caching

Reducing repeated transfers and unnecessary network activity.

User Preferences

Respecting preferences such as reduced motion where appropriate.

Accessibility

Helping digital experiences work for more people.

Hosting & Infrastructure

Making more considered infrastructure choices when those choices are ours to make.

Performance & Carbon

Measuring performance budgets and estimated environmental indicators.

Evidence & Reporting

Supporting what we say with evidence wherever possible.

Carbon numbers need context.

Model

Which estimation model was used?

Version

Which version of that model?

Date

When was the measurement taken?

Scenario

Was it a first visit, repeat visit or another defined scenario?

Data transferred

How much data was the calculation based on?

Hosting status

Could the hosting claim be verified?

So instead of simply writing:

Changelog

1. v1.0
   • Sustainable Web at maneko established.
   • Core measurement areas, technical standard categories and the evidence policy defined.
2. v1.1
   • First baseline measurement for maneko.studio completed and published.
   • Measurement methodology and the context for the carbon estimate added to the page.
   • The measurement is now repeatable; the figures come from a single measurement record.
3. Next
   • Reduce the weight of the home page video: the heaviest single item the measurement found.
   • Set performance budgets for different project classes.
   • Develop the Sustainability Report format for client projects.
   • Collect real-user field data for Core Web Vitals.