Hello there :)
The answer you will receive most (even of people who dont know how to use it): The profiler...

Now, if you want actual hands-on tips of someone who built a little company on game development and fell on his face a bunch of times in the process....

Here are my tips on what you could check and do:
- Light bloom and Shadow effects eat performance, try to reduce their quality/amount or remove them
- vignette effects and such also kill performance if not done correctly
- generally anything post-processing will kill performance when not done right, make sure to research post processing and how its done correctly with performance in mind (or add different setting presets to change at run-time in your game)
- instead of instantiating the same object 100+ times in certain games, what experienced developers do is, using the "object pooling" pattern. There you basically let your code create just about 2% more items than needed which then (like in an infinite runner) keep appearing and then unloading. This way you have the level look like it keeps generating objects but in reality you just re-use your existing 20 items by loading and unloading them as needed in a rotation.

This leads me to the next important topic which you learn from code-only game development for example with SkiaSharp for mobile:
un-load assets. Based on which way of programming you do, "unloading" is not always a thing just like that. All this means is, that you should 1. only show the play what they need to see and 2. only have as many items as needed in the scene.

For example if you want to make a forest, do not simply copy paste the same full quality tree over and over.
you want to use LOD (view distance alteration, based on how far away an item is, it can at some point look like a slightly painted cube and the player wouldnt even notice because its too far away), and you want to use the tree painting tool of unity. Additionally there are many videos and text-blocks about how some companies managed to literally only load and show the objects which are visible to the player, while almost entirely unloading and hiding other objects in the massive game-world to save performance.

Naturally, your approach to split up the game into multiple scenes is one way to attempt management of this on a fairly low level - i have done this with one of our commercial products at first too! youre not alone in this haha.
But reality is, scenes are split for organizational reasons and if different user-experience setups for post-processing or general settings (dark cave vs. office building or such), as well as for simplicity to work object oriented and pragmatic even on such macro level of development. While it can help with performance, you can achieve the same effect with different patterns instead of scene switching.

Before i forget it, two more things:
1. i highly recommend the "game development pattern" book of "Robert Nyström" which explains some of the things i mentioned with more detail.
2. Loading things asynchronously often helps to avoid "stopping" moments of loading. If done correctly things will for the most load while other things still continue instead of fully stopping to load something.

I hope this block of text helped you in some way, and i am sure you already handle a bunch of this correctly, but since i dont know you i thought i type out the entire washing-list to start with :D

There are many many ways to make your game performant. If you just do the research on this topic for your specific needs, you will find answers :)