Barry Cheevers

At the time of writing, 71% of England by land area is in drought, with more than 27 million people subject to restrictions on their water use [1]. Against this backdrop, questions about environmental impact and resource consumption are particularly visible. While attention naturally focuses on industries with an obvious physical footprint, the infrastructure underpinning the web also consumes electricity, including infrastructure that exists solely to facilitate cybercrime

The Anti-Phishing Working Group (APWG) recorded 971,181 phishing attacks in the first quarter of 2026 alone, with APWG defining an “attack” as a unique reported phishing site rather than every individual URL pointing to it [2]. Other than the obvious benefit to potential victims, what is the environmental impact of detecting and taking down so many fraudulent websites, many of which are short-lived, repeatedly redeployed, and implemented with little incentive to minimise the resources they consume?

Phishing is usually discussed in terms of fraud losses, credential theft, and the downstream harm to victims and organisations. Its infrastructure is treated as transient and disposable, something that appears briefly and is then removed. As a result, the environmental impact of phishing is rarely considered at all, often dismissed implicitly on the assumption that individual pages are small and short-lived.

Viewed through the same lens used to reason about energy use across the wider web, phishing infrastructure looks different. Rather than asking for a precise carbon total, it is more useful to examine how phishing pages are deployed, accessed, and executed at scale, and whether those patterns introduce forms of inefficiency that are easy to miss when attention is focused only on individual attacks.

What generates carbon emissions on the web?

Loading a webpage nowadays is almost instantaneous, and we often don’t think about the amount of work, and therefore energy, required. Each load draws electricity across several layers:

• Data centres and servers running the site, or the backend services it depends on.
• Data transmission networks moving bytes through access networks, routers, switching, and long-haul links.
• Client devices doing work: rendering, executing scripts, decoding images, and retrying requests on poor connections.
• Infrastructure overhead: cooling, redundancy, and the operational inefficiencies of “always-on” capacity.

The exact split between these components varies by model and by context. What matters for our purposes is simpler: page views consume energy; energy has an emissions factor. At global scale, even the baseline electricity consumption of the web’s supporting infrastructure is non-trivial. The International Energy Agency (IEA) estimates that data centres consumed approximately 485 terawatt-hours (TWh) of electricity in 2025, following a 17% increase in electricity consumption that year [3]. The Sustainable Web Design Model, meanwhile, uses an estimate of 310 TWh of annual electricity consumption for data transmission networks, based on IEA data for 2022 [4].

Because measuring a “page view” end-to-end is difficult, sustainability practitioners commonly use models based on factors such as data transfer, electricity consumption and grid carbon intensity. The Sustainable Web Design Model, for example, estimates emissions across three parts of the system: data centres, data transmission networks, and user devices. It incorporates both operational emissions, generated through the use of this infrastructure, and embodied emissions associated with its manufacture. For website traffic, the model also distinguishes between new and returning visitors and accounts for data served from cache, providing a better approximation of how pages are actually loaded in practice [4].s are actually loaded in practice [3].

How does phishing infrastructure differ from legitimate websites?

When reasoning about phishing’s carbon footprint, it helps to focus on the concrete technical behaviours that map to actual energy use; for example, data transfer, computation, and repetitive deployment and retrieval. The following patterns in real-world phishing infrastructure align with inefficient, high-volume web activity. This activity provides the increased carbon footprint compared to standard web pages.

Ephemeral Hosting and Infrastructure Churn

Phishing kits and campaigns are designed for rapid setup and turnover rather than long-term operation. Attackers frequently deploy phishing pages on compromised legitimate websites or newly registered domains. A 2026 study of 15,126 newly registered phishing domains found that they had an average lifetime of just 8.6 days, illustrating how transient this infrastructure can be [5].

Phishing kits further enable this rapid deployment. Rather than requiring attackers to construct each phishing site from scratch, kits are distributed as ready-to-deploy phishing websites that allow campaigns using the same underlying techniques to be launched rapidly [6]. This pattern of repeated deployment means that work associated with copying files, establishing new domains or paths, configuring hosting, and serving newly deployed content is performed over and over again rather than being amortised over a long site lifetime.

The growing role of Phishing-as-a-Service (PhaaS) makes this particularly visible. Netcraft’s publicly available research shows that in June 2025, 13.5% of the phishing hostnames it detected were powered by one of the PhaaS platforms it was tracking [7]. This figure does not capture all kit-based phishing activity, but it illustrates the growing role of reusable, automation-friendly tooling in phishing operations.

From an energy perspective, every deployment involves some combination of data transfer, storage and compute, from transferring the kit contents to a host to serving the resulting page. The energy cost of any individual setup is small, but repeated infrastructure churn causes the same types of work to be performed across large numbers of short-lived deployments.

Automation-First Deployment

Modern phishing kits increasingly prioritise automation, making it easier to replicate phishing pages at scale. Netcraft’s analysis of the Darcula Phishing-as-a-Service platform shows how this automation is now embedded directly into attacker tooling. The darcula-suite allows users, including those with little or no web development experience, to generate customised phishing pages by automatically cloning legitimate websites, downloading their assets, and allowing credential-harvesting forms to be inserted into the resulting copy [8]. Netcraft found that the toolkit uses Headless Chrome and browser automation to clone legitimate websites, substantially reducing the technical work required to create a convincing phishing page [8].

Recent updates have further accelerated this process through the integration of generative AI. In April 2025, Netcraft observed that darcula-suite had added AI functionality capable of assisting users with customising phishing pages, generating forms, and translating content into different languages. Netcraft reported that this allowed less technically capable users to create customised phishing kits in minutes [9].

From an energy perspective, this automation increases total resource consumption not because any single deployment is costly, but because it makes repeated deployment easy and scalable. Each automated build involves retrieving and copying assets, instantiating a new page, and subsequently serving that content, incurring network transfer and server-side compute costs each time. As these processes are repeated across large numbers of campaigns and short-lived sites, automation multiplies the amount of similar work performed across the ecosystem, work that would otherwise be amortised or avoided in more stable, long-lived infrastructure.

Disposable Design and Lack of Optimisation

Phishing kits are assembled to mimic genuine sites quickly, not necessarily to execute as leanly as possible. In practice, this often means packaging reusable HTML, CSS, scripts and images so attackers can deploy convincing pages without building them from scratch. A recent analysis of 1,300 phishing kits found substantial code reuse, with many of the major components required to keep phishing pages functional being very similar or even identical across different kits [11].

Unlike carefully engineered production sites, phishing pages can therefore introduce several forms of unnecessary or repetitive work:

• They can transfer more data than is necessary.
  Automated phishing tools can copy far more than the minimum content required to present a credential-harvesting form. Netcraft’s analysis of darcula-suite, for example, found that an attacker can provide the URL of a legitimate website and have the tool automatically visit it and download all of its assets before rendering an editable clone [9]. Images, style sheets, scripts and other resources are therefore replicated as part of the phishing page even though the attacker’s underlying objective may require little more than a convincing interface and a form for capturing information.Every additional asset has to be stored and, when requested by a visitor, transferred across the network. As discussed earlier, data transfer is one of the principal inputs used by the Sustainable Web Design Model when estimating the emissions associated with a webpage [4].
• They can execute more code than is required simply to collect credentials.
  Phishing pages increasingly contain functionality beyond the basic imitation of a legitimate website. Large-scale analysis of more than 434,000 phishing pages identified JavaScript used for browser fingerprinting, client-side IP checking, bot detection, obfuscation and dynamic script execution, alongside the functionality required for the phishing page itself [6].This code exists for a reason, usually improving mimicry or helping the page evade detection, but from an energy perspective it still represents additional work. Scripts must be transferred, parsed and executed by the victim’s device, while some techniques also generate additional network requests or server-side processing.
• They can undermine the benefits of caching across deployments.
  In principle, caching reduces repeated downloads when the same assets remain available at stable URLs. The Sustainable Web Design Model explicitly accounts for this: data loaded from a returning visitor’s cache does not need to be transferred again through the network or recomputed by the data centre [4].Some phishing infrastructure works against these conditions. Group-IB’s analysis of more than 6,000 phishing kits found that 22% of the kits it detected in 2022 used dynamic directories. In these cases, phishing operators created random website folders that were accessible through personalised phishing URLs, primarily as a technique for evading detection and blacklisting [10].Changing the path under which copied assets are served can also reduce opportunities for browsers and intermediary caches to reuse resources previously retrieved from another URL. This does not mean that phishing pages cannot benefit from caching at all, but frequent changes to domains, directories and URLs can make repeated requests behave more like first-time loads.

A simplified example of the dynamic-directory behaviour is shown below:

template = phishing_page_files
new_path = create_random_directory()
copy(template, new_path)
redirect_visitor(new_path)

Figure 1. Simplified pseudocode illustrating dynamic-directory creation and replication of phishing page assets.

The example is deliberately simplified, but illustrates the underlying behaviour documented in phishing kits: a new directory is generated, an existing set of page files is placed beneath it, and the visitor is sent to the newly created path. Group-IB observed dynamic-directory techniques being used specifically to make phishing content harder for automated systems to discover and blacklist [10].

From an energy-model perspective, more data transferred and more computation performed per request both contribute to energy consumption. Inefficient payloads, additional client-side code and repeated retrieval of resources therefore have the potential to raise the per-visit energy use of phishing infrastructure relative to a more carefully optimised implementation [4]. The difference for any individual page load may be extremely small, but, as with the wider argument of this article, its significance comes from repetition at scale.

Repeated Retrieval Work, Including Non-Victim Traffic

Phishing pages aren’t only loaded by intended victims. They also attract automated scans and web crawlers. Defenders use automated systems to discover, retrieve and analyse suspicious URLs, and those systems can interact with a phishing page in much the same way as an ordinary browser.

Cloudflare, for example, describes an automated phishing-detection pipeline in which each submitted URL is first processed by its URL Scanner. The scanner retrieves the page and records its rendered HTML, network requests and other site attributes before the resulting resources are passed to further classifiers and threat-intelligence systems [12]. In other words, investigating a suspicious page can itself involve loading the page and retrieving the resources it references.

This type of automated web retrieval takes place at significant scale across the security ecosystem. In 2026, urlscan.io introduced bulk data dumps partly because customers consuming its scan data had previously needed to make hundreds of thousands of individual Result API requests per day. A urlscan.io scan browses to a submitted URL like a regular user, recording the resources requested, contacted domains and IP addresses, DOM content and other activity generated during the page load [13].

Though this automated defensive traffic doesn’t “benefit” attackers, it nonetheless consumes compute and network resources each time a page is retrieved and analysed. The same phishing page may also be encountered independently by multiple security vendors, crawlers, researchers and other automated systems. From an energy-accounting perspective, the purpose of a request does not change the underlying work involved: data still has to be transferred, servers still have to respond, and scanning systems may render and process the resulting content [4].

Some phishing infrastructure also introduces repeated background requests that are unrelated to direct user interaction. Microsoft documented a particularly clear example in an AI-enabled device-code phishing campaign in April 2026. After directing the victim towards Microsoft’s legitimate device-login page, JavaScript running on the phishing page entered a polling state and contacted the attacker-controlled /state endpoint every three to five seconds to determine whether the victim had completed authentication [14].

Each poll generated another request to attacker-controlled infrastructure even while the authentication state remained unchanged. Once authentication succeeded, a subsequent poll detected the change and allowed the attack to continue [14]. While the energy cost of any one of these requests is extremely small, designs built around repeated polling create additional network and compute work for as long as the interaction remains active.

As with the other sources of inefficiency discussed here, the significance comes from repetition: individual requests are negligible, but automated scanning, repeated retrieval and background communication multiply the number of interactions associated with phishing infrastructure.

Obfuscation and Evasion Techniques

Many modern phishing kits incorporate obfuscation and evasion features to Many modern phishing kits incorporate obfuscation and evasion features to make detection and analysis more difficult. Netcraft’s investigation into the Lighthouse and Lucid Phishing-as-a-Service campaigns, which identified more than 17,500 phishing domains associated with the two platforms, documented both heavily obfuscated HTML and anti-monitoring logic designed to conceal phishing content from automated scanners and researchers [7].

Lucid phishing pages, for example, were observed checking several conditions before displaying their phishing content. These included requiring a specific URL path, access from a particular proxy country, and a mobile User-Agent. When those conditions were not met, visitors were instead shown a generic fake retail website. Netcraft also attributed a Lighthouse campaign making use of heavy HTML obfuscation, alongside similar anti-monitoring content [7].

Obfuscation can add further layers of processing to what would otherwise be relatively simple page logic. Encoded or compressed content may need to be decoded, decompressed or otherwise transformed at runtime before the underlying code can execute. A simplified example is shown below:

payload = retrieve_encoded_content()
payload = decode(payload)
payload = decompress(payload)
payload = transform(payload)
execute(payload)

Figure 2. Simplified pseudocode illustrating multi-layer runtime decoding used to conceal underlying functionality.

This type of layered execution is useful to attackers because the underlying functionality is not immediately visible to static inspection. Research analysing more than 2,000 phishing kits has identified obfuscation alongside evasion functions specifically intended to complicate static analysis, reverse engineering and automated detection [15].

From an energy perspective, obfuscation can introduce additional overhead in two ways. First, some obfuscation techniques increase the size of the code that must be transferred. Second, runtime decoding, decompression, control-flow transformations and similar techniques can require additional processing before or during execution. Experimental research into source-code obfuscation has measured runtime overhead, memory overhead and increases in file size across different obfuscation techniques and tools [16].

The amount of additional energy involved in any individual phishing-page load is likely to be extremely small, and obfuscation should not be treated as a dominant source of emissions. However, where an obfuscated page transfers additional data or performs additional computation, that work contributes to the overall energy required to deliver and execute the page. Repeated across large numbers of phishing deployments and interactions, it represents another source of otherwise unnecessary computation within the phishing ecosystem.

Beyond the Phishing Page: Delivery at Scale

The phishing page itself is only one part of the system. Large-scale phishing campaigns also rely on high-volume message delivery via email, SMS, and other channels, many of which never result in a victim interaction. To give a sense of the scale involved, Microsoft Threat Intelligence detected approximately 8.3 billion email-based phishing threats in the first quarter of 2026 alone, with monthly volumes ranging from 2.9 billion in January to 2.6 billion in March [17]. Telephone-based phishing is also continuing to grow: APWG reported that vishing and SMS-based phishing increased by 15% between Q4 2025 and Q1 2026 [2].

Even when phishing messages are successfully blocked or ignored, infrastructure has already performed work to transmit and process them. Modern email-security systems may subject messages to several forms of automated analysis before they reach a recipient. Cloudflare Email Security, for example, describes inspecting email protocols including SMTP, IMAP and POP3 and applying techniques including machine-learning models, real-time lexical analysis, OCR and sandbox execution when analysing suspicious messages and attachments [18].

Links and other content contained within phishing messages may also trigger further analysis by defensive systems, adding additional requests and processing beyond the original message delivery. As discussed earlier, this activity ultimately relies on data centres, networks and user or security devices, all of which consume electricity [4].

As with phishing pages themselves, the energy cost of processing any individual malicious message is extremely small. The significance comes from volume. When phishing campaigns operate at the scale of billions of detected messages, considerable amounts of network and computational work are being performed to transmit, inspect and ultimately discard traffic that exists solely to facilitate fraud

Illustrative calculation

Precise carbon accounting for phishing is not currently possible, but it is possible to illustrate the scale using transparent assumptions and published estimates of the carbon intensity of internet data transfer. Academic literature analysing the environmental impact of internet use estimates that global internet use has a carbon footprint ranging from 28 to 63 g CO₂-equivalent per gigabyte (GB) of data transferred, depending on network efficiency, electricity generation and the boundaries of the model [19].

For illustrative purposes, we use the midpoint of this range, approximately 45 g CO₂e per GB, as a literature-based estimate of emissions associated with data transfer.

A simple scaling formula is therefore:

Total CO₂e (grams) ≈ N × V × W × (45 / 1000)

Where:

N = number of phishing instances, or comparable units of activity,
V = average number of full page loads per instance, including victims, scanners and researchers,
W = megabytes (MB) transferred per page load,
and 45 / 1000 converts grams of CO₂e per GB into grams per MB.

The Anti-Phishing Working Group (APWG) recorded approximately 3.8 million phishing attacks during 2025 [20]. APWG defines an “attack” as a unique reported phishing site rather than every individual URL leading to the same destination, making this a useful public proxy for the number of phishing instances active during the year.

For this illustrative calculation, we therefore use the following parameters:

N = 3,800,000 phishing sites, based on APWG’s reported attacks during 2025 [20].

V = 100 full page loads per site, representing a mixture of potential victims, security scanners, researchers and other automated retrieval. This is an illustrative assumption rather than an observed global average.

W = 1 MB per load, representing a relatively lightweight complete page load including HTML and associated assets. For context, the median mobile home page measured by HTTP Archive in 2025 was approximately 2.36 MB [21].

Using these values:

3,800,000 × 100 × 1 × (45 / 1000) ≈ 17.1 tonnes CO₂e

To put 17.1 tonnes of CO₂e into more familiar terms, Ofgem’s current Typical Domestic Consumption Value for electricity is 2,500 kWh per year for a medium-consumption UK household [22]. Applying the UK Government’s 2026 electricity conversion factor of 0.13096 kg CO₂e per kWh gives approximately 327 kg CO₂e per household per year [23].

The illustrative phishing scenario above is therefore equivalent to the emissions associated with the annual electricity consumption of approximately 52 typical UK households.

This comparison simply provides a more familiar scale for understanding what 17.1 tonnes of CO₂e represents. The calculation captures only emissions associated with data transfer and excludes backend processing, client-side computation, repeated deployment, multi-page phishing flows, obfuscation and evasion logic, automated security analysis, and the infrastructure used to distribute phishing through email, SMS and other channels. Even using a relatively lightweight 1 MB page and an illustrative 100 loads per phishing site, activity at the scale reported by APWG is sufficient for network-related emissions alone to accumulate into tonnes of CO₂e, with heavier pages or greater numbers of victim and automated retrievals increasing the total proportionally.

So, can phishing really have a meaningful carbon footprint?

Yes, although not because any individual phishing page consumes a significant amount of energy. The impact comes from scale: millions of short-lived sites being deployed, loaded by victims, repeatedly retrieved by security systems, and supported by infrastructure that performs work solely because the phishing campaign exists. Our illustrative calculation puts data-transfer emissions alone at 17.1 tonnes of CO₂e, comparable to the annual electricity emissions of around 52 typical UK households [20], [22], [23], before accounting for backend processing, client-side computation, repeated deployment, email and SMS delivery, or the other sources of activity discussed throughout this article. Phishing therefore represents a form of digital waste in which electricity, bandwidth and computation are consumed to facilitate fraud, while legitimate organisations expend further resources detecting and removing it.

That matters as the amount of electricity consumed by digital infrastructure continues to grow. The IEA expects global data-centre electricity consumption to almost double from 485 TWh in 2025 to around 950 TWh by 2030 [3]. At the same time, 71% of England by land area is currently in drought [1], making questions around resource use particularly visible. Phishing is clearly not a significant cause of either problem, but it illustrates a wider point: as demand for digital infrastructure grows, efficiency should not only mean doing useful work with fewer resources, but also eliminating unnecessary work altogether. Faster phishing detection and takedown primarily protects victims, but every campaign removed also stops a stream of otherwise pointless computation and network traffic. That environmental benefit may be small, but it is one more reason to disrupt cybercrime as quickly as possible.

References

[1] Environment Agency, “Dry weather and drought in England: 7 to 13 August 2026,” GOV.UK, Aug. 14, 2026. [Online]. Available: https://www.gov.uk/government/publications/dry-weather-and-drought-in-england-2026-summary-reports/dry-weather-and-drought-in-england-7-to-13-august-2026. [Accessed: Aug. 16, 2026].

[2] Anti-Phishing Working Group, “Phishing Activity Trends Report, 1st Quarter 2026,” May 2026. [Online]. Available: https://docs.apwg.org/reports/apwg_trends_report_q1_2026.pdf. [Accessed: Aug. 16, 2026].

[3] International Energy Agency, Key Questions on Energy and AI, Paris, France: IEA, 2026. [Online]. Available: https://www.iea.org/reports/key-questions-on-energy-and-ai. [Accessed: Aug. 16, 2026].

[4] Sustainable Web Design, “Estimating Digital Emissions,” Sustainable Web Design. [Online]. Available: https://sustainablewebdesign.org/estimating-digital-emissions/. [Accessed: Aug. 16, 2026].

[5] S. Agarwal and M. Vasek, “Examining newly registered phishing domains at scale,” Journal of Cybersecurity, vol. 12, no. 1, Art. no. tyag020, Jul. 2026, doi: 10.1093/cybsec/tyag020.

[6] A. Nahapetyan, K. Khare, K. Schwarz, B. Reaves, and A. Kapravelos, “Characterizing Phishing Pages by JavaScript Capabilities,” arXiv preprint arXiv:2509.13186, rev. Jul. 2026. [Online]. Available: https://arxiv.org/abs/2509.13186. [Accessed: Aug. 16, 2026].

[7] H. Everett, “Inside the Lighthouse and Lucid PhaaS Campaigns Targeting 316 Global Brands,” Netcraft, Sep. 17, 2025. [Online]. Available: https://www.netcraft.com/blog/inside-the-lighthouse-and-lucid-phaas-campaigns-targeting-316-global-brands. [Accessed: Aug. 16, 2026].

[8] H. Everett, “darcula-suite 3.0 enables DIY phishing of any brand,” Netcraft, Feb. 20, 2025. [Online]. Available: https://www.netcraft.com/blog/darcula-v3-phishing-kits-targeting-any-brand. [Accessed: Aug. 16, 2026].

[9] H. Everett, “AI-enabled darcula-suite makes phishing kits more accessible, easier to deploy,” Netcraft, Apr. 24, 2025. [Online]. Available: https://www.netcraft.com/blog/ai-enabled-darcula-suite-makes-phishing-kits-more-accessible-easier-to-deploy. [Accessed: Aug. 16, 2026].

[10] Group-IB, “The use of phishing kits surges by 25% in 2022 as they become more evasive and advanced,” May 25, 2023. [Online]. Available: https://www.group-ib.com/media-center/press-releases/phishing-kits-2022/. [Accessed: Aug. 16, 2026].

[11] B. Ousat, M. A. Tofighi, E. Schafir, and A. Kharraz, “An Analysis of Architectural and Operational Dynamics of Phishkits in the Wild,” arXiv preprint arXiv:2608.07451, Aug. 2026. doi: 10.48550/arXiv.2608.07451.

[12] Cloudflare, “How Cloudflare is using automation to tackle phishing head on,” Cloudflare Blog, Mar. 17, 2025. [Online]. Available: https://blog.cloudflare.com/how-cloudflare-is-using-automation-to-tackle-phishing/. [Accessed: Aug. 16, 2026].

[13] urlscan.io, “Introducing Data Dumps: Bulk Download of urlscan Scan Data,” urlscan.io Blog, Mar. 12, 2026. [Online]. Available: https://urlscan.io/blog/2026/03/12/datadump/. [Accessed: Aug. 16, 2026].

[14] Microsoft Threat Intelligence, “Inside an AI-enabled device code phishing campaign,” Microsoft Security Blog, Apr. 6, 2026. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/. [Accessed: Aug. 16, 2026].

[15] A. Venturi, M. Colajanni, M. Ramilli, and G. V. Santangelo, “Classification of Web Phishing Kits for Early Detection by Platform Providers,” Computers & Security, 2023. [Online]. Available: https://arxiv.org/abs/2210.08273. [Accessed: Aug. 16, 2026].

[16] H. Jin, J. Lee, S. Yang, K. Kim, and D. H. Lee, “A Framework to Quantify the Quality of Source Code Obfuscation,” Applied Sciences, vol. 14, no. 12, Art. no. 5056, Jun. 2024, doi: 10.3390/app14125056.

[17] Microsoft Threat Intelligence, “Email threat landscape: Q1 2026 trends and insights,” Microsoft Security Blog, Apr. 30, 2026. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2026/04/30/email-threat-landscape-q1-2026-trends-and-insights/. [Accessed: Aug. 16, 2026].

[18] Cloudflare, “How Email Security detects phish,” Cloudflare One Documentation, Apr. 17, 2026. [Online]. Available: https://developers.cloudflare.com/cloudflare-one/email-security/reference/how-es-detects-phish/. [Accessed: Aug. 16, 2026].

[20] Anti-Phishing Working Group, “Phishing Activity Trends Report, 4th Quarter 2025,” Feb. 2026. [Online]. Available: https://docs.apwg.org/reports/apwg_trends_report_q4_2025.pdf. [Accessed: Aug. 16, 2026].

[21] HTTP Archive, “Page Weight,” The 2025 Web Almanac, 2026. [Online]. Available: https://almanac.httparchive.org/en/2025/page-weight. [Accessed: Aug. 16, 2026].

[22] Office of Gas and Electricity Markets, “Summary of changes to the energy price cap: 1 July to 30 September 2026,” May 27, 2026. [Online]. Available: https://www.ofgem.gov.uk/sites/default/files/2026-06/Summary-of-changes-to-energy-price-cap-1-July-to-30-September-2026.pdf. [Accessed: Aug. 16, 2026].

[23] Department for Energy Security and Net Zero, “Greenhouse gas reporting: conversion factors 2026,” Jun. 11, 2026. [Online]. Available: https://www.gov.uk/government/publications/greenhouse-gas-reporting-conversion-factors-2026. [Accessed: Aug. 16, 2026].