Adding a no-backend option for checking a site

[mrchrisadams]

Hi folks, I'm creating this issue as a result of some discussion in PR 487 on the Wagtail bakery Demo repo.

Here's the key quote:

Qn1. Is there a way to manually trigger a run for a given project to see how it's working, outside of pushing new code to a branch?

I'm thinking of something along the lines of the use case in the original README for @thibaudcolas 's fork - where he demonstrated how to run a specific scenario on their remote dedicated testing hardware. A bit like this:

greenframe analyze http://localhost:8000/ homepage-landing.js

The idea here is that spinning up a full docker container, with browser and puppeteer is more than many teams are able to take on, but also getting the directly measured energy figures from a browser itself is a useful thing, that many existing tools don't offer.

The only example I DO know that supports exposing CPU usage figures is Sitespeed.io (see this issue for more), and that works by using Firefox's own profiler's own per-process figures, rather than inspecting the whole machine from the outside. When I spoke to the Firefox folks, I think that because it uses a per-process focussed approach that lists only processes the browser "owns", it was harder to see when work was offloaded to a GPU, like for video and so on.

However, please don't take that at face value though - I'm not sure if that is correct.

Anyway, something a bit like this would be really helpful and I think lower the barrier to starting with GMT:

gmt one-off focussed-usage-scenario.yml green-coding-puppeteer-container https://path-to-website-to-check

Where:

• gmt is probably some nice binary CLI alias to sending a modified HTTP request to the GMT server API, requesting a one-off run
• one-off is a one-off test subcommand (inspired by the current GMT API)
• • focussed-usage-scenario.yml might be a usage scanario as already defined in GMT,
• green-coding-puppeteer-container is a predefined label for docker container. As far as I can tell, these docker container labels that would always be present even if you are reusing a docker compose file anyway in a usage_scenario.yml. To make things specific, the wagtail PR linked above has the docker container containing the browser as green-coding-puppeteer-container
• https://path-to-website-to-check is the domain to check. I think puppeteer and playright assume a single domain by default - hence making the domain explicit.

[ArneTR]

Hmm, now reading this I am not exactly sure anymore if I understood you correct initially:

• Are you proposing a more easy CLI based interface to submit jobs to the cluster? If so somehow the command must provide all the infos that must be typed in on https://metrics.green-coding.io/request.html
• Or are you suggesting a CLI command that is specifically targeted at looking at websites. Using the GMT measurement infrastructure to spin up a browser, visit a page, log all energy data while doing so?

[mrchrisadams]

Hi @arne

It might help to look at the workshop I delivered at Djangocon 2024 when showing folks how to use some of these tools:

Here's the link to the deck (it's quite long - see slides 46 - 60 for a little more context). https://docs.google.com/presentation/d/1mn1Qsr_vZ0lkFvIDZu5aEOginHFCpr4V/edit#slide=id.p1

That workshop introduces people to using some tools to look at a website, and use the information recorded to draw some conclusions about the carbon footprint of usage, starting with tooling like WebPageTest, then introducing people to GMT as a way to look at the full stack, instead of only relying on data transfer:

If it helps, I used this diagram below to explain how people with existing django apps can implement some of this, but as the diagram suggests, there are really two separate things people need to get meaningful numbers for web apps:

1. an easily reproducible set of server-side components, that are somewhat representative of a live site prepopulated with data (the stuff on the left)
2. some knowledge of how to drive a browser with code for repeatable steps, and some understanding of the usage_scenario.yml file format

I'm suggesting something on the right hand side - so that people can start using GMT to try running measurement runs in a setup that doesn't just rely on data transfer as the proxy, but still provides a degree of reproducibility.

I'm hoping the repo linked below gives some extra context at what I'm after, but I'll also be in Berlin next week. I'm happy to chat over lunch 👍

https://github.com/mrchrisadams/gmt-check-a-website