Copy of some Draft Web Development Guidelines

Third-party services should be assessed as first parties

Whether advertising, chatbots, maps, or other tooling; outsourcing your service to a third-party provider may be potentially useful in certain scenarios in reducing design or development time and redundancy (which can be a win for sustainability). Third-party services, however, come with issues, such as the lack of control over emissions, and they often can potentially suffer from latency and large file sizes which may not exist if you self-hosted or created the material.

Criteria: Assess third-parties

Machine-testable

Third-party services (including plugins, widgets, feeds, maps, carousels, etc) have been assessed as early in the ideation or creation process as possible and as few of them are used as possible to reduce the product or service's overall ecological impact, including Scope 3 emissions.

Resources

Criteria: Third-party implementation

Machine-testable

Third-party content (including plugins, widgets, feeds, maps, carousels, chat widgets, etc) that loads or requests resources or functionality from a location outside of the primary location, should be placed behind a click-to-load delay screen (using the "import on interaction" pattern), while alternatives are offered, for instance a link to a contact form as an alternative for a chat widget.

Resources

Criteria: Libraries and frameworks

Machine-testable

Large CSS libraries and JavaScript frameworks are only be used if a more performant alternative that achieves the same goal cannot be used instead.

Resources

Criteria: Self-hosting

Machine-testable

Self-hosted content has been prioritized over embedded content from third-party services.

Resources

Criteria: Avoiding dependency

Machine-testable

Your own clickable icons and widgets have been created, rather than relying on third-party services to host or allow embedding within your product or service.

Resources

Criteria: Third-party preferences

Machine-testable

Third-party products, services, libraries, and frameworks are often a source of sustainability issues that cannot be controlled or managed by the first-party provider of a service. While many do provide benefits to a website, the need to justify their inclusion must be made not only by those creating the product or service but also be able to be controlled by the consumer. As showcased with cookies, websites or applications can provide a similar mechanism of disabling or refusing non-first-party features (with explanations of their purpose) - unless such features can be proven as critical for functionality.

Resources

Impact: High, Effort: Medium

GRI Impact of Third-party services should be assessed as first parties
GRI Impact
materials High
energy High
water High
emissions High
Benefits of this guideline
  • Environment: Replacing heavy tooling and third-party services with lightweight tooling reduces visitor bandwidth usage considerably, despite having to learn a new way of doing things or reducing the visibility of such information. It can significantly reduce a page's (and data you have no control over) environmental impact, especially when it comes to Scope 3 emissions.
  • Privacy: Visitors not interested in embedded content may identify the lack of third-party tracking (such as embedded pixels and tags) as a privacy benefit, as there are fewer chances that visitor data is exploited.
  • Performance: Self-made widgets and controls work much faster than third-party content as you don't have to perform additional server requests, rendering requests, and such. You only include what features you require, and this reduces the overall size of the bandwidth usage (and emissions produced).

Example

Tags: