For the most part, when things (CSS, images, plugins) aren’t being used, they’re not computing or using resources. How you use them, or how they’re designed, is what makes the difference.
CSS
Fifty CSS snippets that each efficiently do an inexpensive thing thing might be completely unnoticeable.
One CSS snippet that inefficiently does an expensive thing could hang the app.
A hypothetical example is a snippet that recolors your folders as you drag a file. Redrawing your file explorer for every few pixels you drag is expensive and could freeze Obsidian.
Images
Having a lot of images in your vault, of itself, might have little effect except when indexing and searching
What you do with the images, however, could cause delays from minor to major.
Example: Opening a note that simply links to lots of images probably won’t cause issues. Opening the local graph on that note could be sluggish. Turning all of those links into embeds could make scrolling choppy and slow.
With a lot of images, search will be slower at returning results and at making suggestions in various file suggesters.
There’s a file limit (I don’t recall the number, but it’s high) above which fuzzy search disengages, leaving only literal search.
Plugins
See “CSS”. Fifty plugins that, etc.
It depends on what the plugin does.
A plugin that, say, runs a bunch of stuff at startup will slow your start-up time (example: MakeMD). A plugin that loads very little then sits idly until you call on it might have effectively no impact until you put it into action (example: Local Backup).
Another example where how you use it makes a difference: Dataview. Using it to search for well-defined info in a small subset of files can be snappy. But using it to search the entire vault and do manipulations on a large amount of info can hang Obsidian.
