DW/double checking SWD calculations

[drydenwilliams]

Why/How have the calculations for SWD changed?

I've added this PR in to highlight and ask questions on why the SWD calculations have changed from v0.8.0 to v0.9.0? To understand why, and do get these calculations double-checked by other people.

With these updates, it takes CO2 grams per visit from 0.2 to 0.57 which is quite a jump.

Some more info about the changes can be seen here: https://github.com/thegreenwebfoundation/co2.js/issues/76#issuecomment-1106232937

[mrchrisadams]

Hi Dryden, can you please take a look at #87 ?

I've made a few small changes to the test, and it looks like the v9 calc does return 0.2 there, and the v8 return the 0.57 figure.

https://github.com/thegreenwebfoundation/co2.js/pull/87

[mrchrisadams]

Hi Dryden,

Thanks for making the test above - it was helpful when I was looking at this last night.

I didn't want to change this PR, so I've created #87 which should show some more of my working, but this raises a good point.

Do we not have the constants the wrong way around anyway?

Here's the formula from the SWD webpage

E = [Data Transfer per Visit (new visitors) in GB x 0.81 kWh/GB x 0.75] + [Data Transfer per Visit (returning visitors) in GB x 0.81 kWh/GB x 0.25 x 0.02]

So E in this case, is our first load which we expect to be big, then then subsequent loads which we expect to be smaller.

I know it's silly to assume a webpage is 1gb in size, but it does make these calculations easier to follow here.

// our first visit 
[Data Transfer per Visit (new visitors) in GB x 0.81 kWh/GB x 0.75]

To make this concrete, 1 * 0.81 * 0.75 is 0.6075.

We know this should be a larger number than the subsequent visits, where more of the assets are assumed to be loaded from the cache. And if we look we see the smaller number

// subsequent visits
[Data Transfer per Visit (returning visitors) in GB x 0.81 kWh/GB x 0.25 x 0.02]

Again making this concrete, 1 * 0.81 * 0.25 * 0.02 gives us a much smaller number number of 0.00405

Lets look at the v8 version, which is very closely copied from website carbon 2.0 code:

energyPerVisitV8(bytes) {
    const transferedBytesToGb = bytes / fileSize.GIGABYTE;

    return (
      transferedBytesToGb * KWH_PER_GB * RETURNING_VISITOR_PERCENTAGE +
      transferedBytesToGb *
        KWH_PER_GB *
        FIRST_TIME_VIEWING_PERCENTAGE *
        PERCENTAGE_OF_DATA_LOADED_ON_SUBSEQUENT_LOAD
    );
  }

Here, the website carbon code has RETURNING_VISITOR_PERCENTAGE as 0.75 and FIRST_TIME_VIEWING_PERCENTAGE as 0.25, which is the other way around from the SWD page itself.

website carbon code and CO2 js:
FIRST_TIME_VIEWING_PERCENTAGE = 0.25
RETURNING_VISITOR_PERCENTAGE = 0.75

SWD webpage
FIRST_TIME_VIEWING_PERCENTAGE = 0.75
RETURNING_VISITOR_PERCENTAGE = 0.25

If we break the return value into two parts, we have the top part, which should represent the first load.

transferedBytesToGb * KWH_PER_GB * RETURNING_VISITOR_PERCENTAGE

And then the second part, which should represent the second load:

Followed by the second part which represents the subsequent load which should be smaller.

transferedBytesToGb * KWH_PER_GB * FIRST_TIME_VIEWING_PERCENTAGE * PERCENTAGE_OF_DATA_LOADED_ON_SUBSEQUENT_LOAD

The extra functions in the SWD module are there because not every consumer of CO2 makes these caching assumptions (sitespeed doesn't for example), and we've previously discussed the option of overriding these numbers, where we have better data, just like how we've discussed the option of supporting other carbon intensity numbers if they are available.

I found them useful for debugging these caching assumptions today, and I've adjusted the energyPerVisitByComponent accordingly to make it clearer what values are being returned.

[mrchrisadams]

OK, I now think that 0.57 ought to be the correct value for the website. I've outlined in #87 why, and updated any failing tests accordingly.

[drydenwilliams]

Wooohoooo good spot! Well done @mrchrisadams

[drydenwilliams]

Mystery solved, closing this issue.