Well it depends, because maybe you're using Styled Components or some other library that ties you into the React/JSX ecosystem.
Or maybe your app passes a 'theme' through various contexts and you have to find the right theme and find the thing you need to tweak the background colour for, which might be in a CSS file pulled in through Webpack if you're lucky.
If you're not lucky, maybe there's some funky SASS/LESS setup where all of the colours are stored in variables describing their purpose, in one of a dozen specially categorised files for storing globals. Now there are six or seven values all with '#xxxxxx' as the colour value and you don't know which one it is, so then you're thinking, is this `lightBlue7` or `darkBlue-3` or `cyanish4`.
Or maybe a few event listeners pull down style information into the component state after first rendering with a bunch of placeholders, so now the component you're looking to change the background of is a function of the time spent on page.
Or, maybe you found some CSS and it was an easy change, but then the project is in Typescript and the CSS is actually derived at build-time from an enum containing all of the config, which is used to replace specially formed strings in the CSS while having sensible defaults in dev.
If you're cursed, the CSS isn't even in your frontend at all and a server-side rendering system is generating your styles from DB backed configurations, which are queried by a graphql layer in your frontend so users can customise their UI in their profile settings, so you have to write a database migration and run a full deployment to add the new colour and its customisation UI to the frontend.
I think if I was promoted to CEO, I would go full reactionary and demand that all front end javascript code must be vanilla and interact with the dom directly, and all styling contained in css
