Exercise 3: The Two Real Costs of Installing 40 "Just in Case" Plugins — Possible Solution ==================================================================== COST 1: PERFORMANCE ------------------------------ Per this chapter's own warn-box, "every active plugin adds real PHP code that runs on every relevant page load." Forty active plugins mean forty pieces of code potentially executing on every single page request, regardless of whether most of them are actually being used meaningfully by visitors. This is directly tied by this chapter to Performance & Core Web Vitals's own material - each additional plugin adds real processing time and resource use, with a genuine, measurable effect on how quickly pages actually load. COST 2: SECURITY ------------------------------ Per this chapter, "every plugin is also additional code that could contain a vulnerability." Forty plugins mean forty separate codebases, each maintained (or not) by a different developer, each representing its own independent chance of containing a security flaw. This chapter ties this directly to OWASP Top 10's own Vulnerable & Outdated Components category - an unmaintained or vulnerable plugin among those forty is exactly the kind of risk that category describes, and having forty plugins installed means forty separate opportunities for exactly that risk to exist somewhere in the mix. WHY "JUST IN CASE" MAKES BOTH COSTS WORSE FOR NO BENEFIT ------------------------------ Plugins installed "just in case they're useful someday" but not actually being used still incur both costs in full - the performance cost of their code running (or at minimum being loaded) and the security cost of their code existing and potentially going unmaintained - while providing none of the actual functional benefit a genuinely needed plugin would justify. The costs are real and ongoing; the benefit, for an unused "just in case" plugin, never materializes. WHY THIS CHAPTER'S OWN CONCLUSION FOLLOWS ------------------------------ Per this chapter, "fewer, well-vetted plugins consistently beats many loosely-chosen ones." Given that both costs scale with plugin count regardless of actual use, and neither cost is offset unless a plugin is genuinely needed and used, minimizing the plugin count to only what's actually necessary is the position this chapter's own reasoning directly supports. WHY THIS WORKS AS AN ANSWER ------------------------------ It identifies both costs precisely as this chapter names them (performance and security), explains why "just in case" plugins incur both costs while providing no offsetting benefit, and connects that reasoning directly to this chapter's own stated conclusion rather than asserting it independently.