Plugins are how WordPress does almost everything beyond publishing text, and they are also the most common way a site becomes slow, broken or compromised. Both facts follow from the same design: a plugin runs with full access to your site, your database and your files. Installing one is a decision about trust, not just about features.
This covers installing plugins the three ways it can be done, and then the part that matters more, how to choose one, how to spot the one that is hurting the site, and how to remove it properly.
Installing from the plugin directory
In the dashboard, open Plugins then Add New and search. Click Install Now, then Activate. Plugins here are hosted on wordpress.org, which means they are freely licensed and have passed a basic review: not that they are well written or currently maintained.
Before clicking install, read four things on the plugin page. When it was last updated: anything untouched for more than a year is a risk, because a plugin that is not maintained will not be patched when a vulnerability is found. Its compatibility with your WordPress version. The active install count, where a larger number means problems get found by someone other than you. And the support forum, where unanswered threads tell you more than the star rating does.
Installing a plugin you have as a file
Commercial plugins are usually delivered as a ZIP file. Open Plugins then Add New, choose Upload Plugin, select the file and install it.
Upload only ZIPs from the developer you bought from. "Nulled" copies of commercial plugins (paid plugins redistributed for free) very frequently contain injected code, and the injection is the entire reason the copy exists. A compromise arriving this way is invited in with full privileges, and no security plugin will stop it.
Installing over SFTP
If the dashboard is unreachable, or the upload limit is smaller than the plugin, extract the plugin folder into wp-content/plugins using File Manager or an SFTP client. It appears in the plugin list on the next page load, ready to activate.
Keep the folder structure intact: the plugin's own folder goes directly inside plugins, not wrapped in another folder created by the extraction.
Updating plugins
Turn on automatic updates for plugins. Outdated plugins are the leading cause of compromised WordPress sites, and the gap between a vulnerability becoming public and being exploited at scale is often measured in hours. Enabling automatic updates deals with the settings.
The exception is a site where a broken page costs money directly. A store mid-season, a booking system. There, test updates on a staging copy first. That is a real trade-off, not an excuse to leave updates off; a site running six-month-old plugins is in far more danger than one that occasionally needs a layout fixed.
Finding the plugin that is slowing the site
Plugin count is a poor measure. Thirty plugins that do nothing on the front end cost less than one that runs a database query on every page load.
Install a query monitoring plugin, load a slow page as an administrator, and read which plugin accounts for the most query time and PHP time. Related-post widgets, sliders, visitor counters and "recent activity" panels dominate this list far more often than people expect, because they recompute on every request instead of caching the answer.
Then deactivate one plugin at a time and re-measure. Deactivating five at once tells you something improved, not what. Optimizing WordPress performance puts this in the context of the other three things that make WordPress slow.
Finding the plugin that broke the site
If the site broke right after activating something, deactivate that plugin. If you cannot reach the dashboard, rename the plugin's folder inside wp-content/plugins over SFTP: adding -off to the end is enough. WordPress cannot find it, treats it as deactivated, and the site returns.
If you do not know which one, rename the whole plugins folder to plugins-off. Everything deactivates at once and you can log in. Rename it back, then activate plugins one at a time until the fault reappears.
Conflicts between two plugins that are each fine alone are common, and they produce the confusing case where the last plugin you activated is not really the culprit.
Deleting plugins properly
Deactivate, then Delete. Deactivating alone leaves the code on disk, and some vulnerabilities are reachable in files that are present but not active. If you are not using it, delete it.
Deleting through the dashboard removes the files. It usually does not remove the plugin's database tables or its stored options, because WordPress cannot know whether you intend to reinstall. Over years this accumulates, which is part of why old sites carry bloated option tables. Some plugins offer a "remove all data on uninstall" setting: turn it on before deleting if you are certain you are done with it.
How many plugins is too many
There is no number. The useful questions are whether each plugin is maintained, whether it does work on every page load, and whether you would notice if it stopped working.
That last one is the most revealing. A plugin nobody would notice missing is pure risk with no return. It still needs patching, still loads, and still has full access to your site. Those are the ones to remove first.
When something breaks after an install, the search does not have to be one plugin at a time. There is more on a much faster approach in How to Find Which Plugin Is Causing a Problem.