Talked through this with Mo

• We'll create a new static file with a style block that adds the new rule (Making sure any relative URLs for stylesheets and scripts have been updated)
• We'll upload it to https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/89fa9bbdf4ed2998c48a16c6e3fe69ecf0dbe11a/docroot/wikipedia.org/speed-tests folder
• We'll deploy it in a deployment window.
• We'll run a synthetic test on the production version of the static URL e.g. https://en.wikipedia.org/speed-tests/index.html

I have added

[style*="background"] {
	color: @color-inverted;
}

Locally there is no performance impact, even with 6x throttling, and seems that is also supported by https://github.com/amcss/am-benchmarks and https://stackoverflow.com/questions/22284219/css-performance-between-class-and-attribute-selectors outcomes, Should we proceed with a synthetic speed test?

Change 1006872 had a related patch set uploaded (by Mabualruz; author: Mabualruz):

[mediawiki/skins/MinervaNeue@master] [POC] Attribute selector contrast issue fix

https://gerrit.wikimedia.org/r/1006872

Change 1007352 had a related patch set uploaded (by Mabualruz; author: Mabualruz):

[operations/mediawiki-config@master] Performance Impact Assessment for Night Mode Style Correction

https://gerrit.wikimedia.org/r/1007352

We discussed in SHDT:
@Mabualruz to:

• link out to results of local testing
• Jon to review https://gerrit.wikimedia.org/r/1007352 and Mo to get it deployed.

The local results:

Once the patch has a +1 it needs to be scheduled on the next deploy window. I suggest 1 more local result attached from a different machine and check on the online speed test files on sign-off I will move this to review

Looking closely I think we should be using an article where the selector would apply to lots of elements. I have suggested using the URL https://en.m.wikipedia.org/wiki/2023_Formula_One_World_Championship?minervanightmode=1 for the tests.

https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20240229T2100 scheduled for late window deployment

Change 1007352 merged by jenkins-bot:

[operations/mediawiki-config@master] Performance Impact Assessment for Night Mode Style Correction

https://gerrit.wikimedia.org/r/1007352

Mentioned in SAL (#wikimedia-operations) [2024-02-29T21:04:07Z] <jdrewniak@deploy2002> Started scap: Backport for [[gerrit:1007352|Performance Impact Assessment for Night Mode Style Correction (T358240)]]

Mentioned in SAL (#wikimedia-operations) [2024-02-29T21:05:37Z] <jdrewniak@deploy2002> mabualruz and jdrewniak: Backport for [[gerrit:1007352|Performance Impact Assessment for Night Mode Style Correction (T358240)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-02-29T21:13:36Z] <jdrewniak@deploy2002> Finished scap: Backport for [[gerrit:1007352|Performance Impact Assessment for Night Mode Style Correction (T358240)]] (duration: 09m 28s)

Seems Live examples with performance insights also have no performance difference between:

• https://en.wikipedia.org/speed-tests/2023_Formula_One_World_Championship.mobile.nightmode.enwiki.1709132740/before/index.html
• https://en.wikipedia.org/speed-tests/2023_Formula_One_World_Championship.mobile.nightmode.enwiki.1709132740/after-add-css-style-attribute-selector/index.html

@Mabualruz could you please also do a brief write up (with screenshots) describing what you see here and why we can be confident that this is not a performance issue. I don't think it's sufficient to just add two JSONs to this task and expect people to download them and review them and determine that themselves.

Live Night Mode With Selector:

Live Night Mode No Selector:

Short Answer

Upon reviewing the performance data collected from both scenarios—with and without the night mode style selector—we observed that the scenario with the selector had fewer total events (49,826 events) compared to the scenario without the selector (51,906 events). However, the total duration of events was slightly longer with the selector (7,798.584 ms) compared to without (6,993.239 ms). This suggests that while the implementation of the night mode style correction slightly increases the processing time, it also reduces the total number of events that need to be processed. This efficiency in reducing event counts may offset the marginal increase in processing duration, leading to our conclusion that the performance impact is minimal and within acceptable parameters for user experience. We remain open to further discussion and analysis to ensure a comprehensive understanding of these findings.

Data analysis

The data from both files (liveNightModeWithSelector.json.gz and liveNightModeNoSelector.json.gz) is structured into two main keys: traceEvents and metadata. This structure suggests that the files contain performance tracing information and associated metadata.

Examine both files:

1. Metadata Comparison: Quick review of the metadata to understand the context of each test scenario.
2. Trace Events Analysis: Analyse the traceEvents for both scenarios to identify any significant differences in performance metrics, such as execution times, resource loading, or any other indicators of performance impact.

The metadata comparison between the two files reveals that both tests were conducted under similar conditions, focusing on the page load use case. Here are some key observations:

• Source: Both sets of data were collected using DevTools, ensuring consistency in the data collection method.
• Track Configuration: The configuration for tracked events, such as LayoutShiftTrack, NetworkTrack, and RendererTrack, was the same across both tests. This indicates that the comparison will be fair and focused on the same performance aspects.
• Use Case: The use case for both tests was "Page load," which is crucial for understanding the impact of the night mode style correction during initial page loading.
• Network and CPU Throttling: Both tests were conducted without network throttling and with the same level of CPU throttling (6). This ensures that any observed performance differences are not influenced by external throttling factors.

Given the consistency in testing conditions, any differences in the traceEvents data will provide a clear insight into the performance impact of implementing the night mode style correction. Let's now analyse the traceEvents data to identify any performance differences. ​​

The analysis of the traceEvents data from both test scenarios reveals the following:

• Total Events:
  • With Selector: 49,826 events
  • No Selector: 51,906 events
• Total Duration (in milliseconds):
  • With Selector: 7,798.584 ms
  • No Selector: 6,993.239 ms

This data indicates that the scenario with the selector had fewer total events compared to the scenario without the selector. However, the total duration for processing these events was longer in the scenario with the selector. This could suggest that while there are fewer events to process when the selector is used, the complexity or nature of these events could result in a slightly longer processing time.