A fictional small publisher has accumulated plugins through several redesigns. Some support forms and redirects, others were used for a single campaign, and several have unclear names. The publisher wants a lighter, safer site but cannot afford to lose enquiries or old links. The exercise is a dependency audit, not a claim that a particular plugin count is universally safe.
Record purpose before counting
The number of installed plugins tells little about what they do. A small extension can perform a critical function, while one large suite may include features the site never uses. Identify the business purpose of each item and the person who can explain it. Include inactive extensions because they still occupy space and can confuse future maintenance.
Put it into practice
Create an inventory with purpose, owner, active state, and installed version.
Evidence to keep: A plugin list that connects technical names to actual website functions.
Stop and investigate if: An extension is marked unnecessary solely because its name is unfamiliar.
Keep the initial observation separate from the proposed solution. Write down what was known before making the change, which part of the exercise is hypothetical, and which information must come from the real website owner. This prevents an attractive explanation from becoming an unsupported claim. Ask a second reader to identify the decision being made and the condition that would change it.
Look for hidden dependencies
A form, booking feature, page template, or custom block may rely on an extension without making that dependence obvious. Inspect representative pages and relevant settings. Some plugins create data or database tables that remain after deactivation; others may remove information during uninstall. Read the publisher’s instructions before assuming the two actions are equivalent.
Put it into practice
Map each plugin to pages, integrations, scheduled jobs, and stored data.
Evidence to keep: A dependency note identifying what could stop working if the plugin is disabled.
Stop and investigate if: A plugin is uninstalled before the team understands its data behaviour.
Use a comparison that another authorised person could repeat. Keep the relevant conditions stable, record the version or document reviewed, and change only what the question requires. If a comparison cannot isolate the cause, describe it as an observation rather than a proof. The useful record explains what was checked, what remained outside the test, and what should be investigated next.
Check maintenance evidence
Review the legitimate publisher, update route, support information, and compatibility notes. A recent date alone is not a complete quality assessment, and an old date does not explain every risk. Consider whether the extension still has an accountable maintainer and whether the team can obtain updates through a trusted channel. Record uncertainty instead of inventing a reassuring conclusion.
Put it into practice
Review official maintenance information and document unanswered questions.
Evidence to keep: A source link and review date for each important extension.
Stop and investigate if: The installed package has an unclear origin or no reliable update route.
Make the verification artefact small enough to review carefully. A short note, a safe test submission, or a documented configuration comparison can be more useful than a large unexplained report. Keep private information out of public examples. When the evidence is incomplete, state the gap beside the decision instead of allowing a confident summary to conceal the unresolved part of the work.
Identify overlapping responsibilities
Two extensions may both manage caching, optimisation, redirects, or security settings. Overlap can create confusion even if neither product is inherently poor. Choose the component that owns each responsibility and document exceptions. Do not enable every performance switch at once. A clear configuration is easier to test and explain than several tools competing over the same output.
Put it into practice
Assign one primary owner to each shared technical responsibility.
Evidence to keep: A responsibility map for caching, forms, redirects, and other overlapping features.
Stop and investigate if: Two tools repeatedly rewrite the same page or configuration without coordination.
Before accepting this step, consider the ordinary failure path as well as the successful one. Identify who notices a problem, what the visitor sees, and how the team returns to a known state. A process that works only when every assumption is correct remains fragile. The recovery action should be understandable to someone who did not design the original change.
Measure an actual effect
A plugin should not be blamed for a performance problem merely because it exists. Compare the relevant page or task with one optional component changed at a time in staging. Record cache state, device, and feature loss. A faster result is not an improvement if the comparison removed the function that visitors were trying to use.
Put it into practice
Run a controlled comparison for one suspected performance contribution.
Evidence to keep: A before-and-after record describing conditions and preserved functionality.
Stop and investigate if: Several plugins change at once and the team cannot attribute the result.
Check the result in the context where it will actually be used. An isolated editor view, a demonstration account, or an unusually fast device may hide a difficulty that matters in normal operation. Record any conditions that differ from the intended audience. This does not require pretending to test every possible situation; it requires a clear account of the situations that were and were not examined.
Deactivate with a recovery route
Choose a low-risk candidate, save a restore point, and disable it in staging. Follow the dependency checklist and inspect less prominent pages as well as the homepage. Keep a note of settings that would be needed if the extension is re-enabled. Deactivation is a testable change; permanent data removal deserves a separate deliberate decision.
Put it into practice
Disable one candidate in staging and run its documented acceptance checks.
Evidence to keep: A change log with the rollback steps and the outcome of each dependent task.
Stop and investigate if: A required function fails and nobody knows how to restore the previous setup.
Give the decision an owner and a review trigger. The person approving a change should know what evidence supports it and what would justify reopening it. Keep the handover practical: describe the action, the expected observation, and the limit of the conclusion. If responsibility is shared, explain where the next step goes rather than leaving it somewhere between several people.
Archive the decision, not the clutter
After a successful removal, keep a concise record of why the extension was removed and what replaced its responsibility. Do not retain unnecessary downloadable packages inside a public directory. Preserve documentation and backups in an appropriate private location. A future maintainer needs the reasoning, not a pile of unexplained old ZIP files.
Put it into practice
Complete the removal record and verify that public pages still behave correctly.
Evidence to keep: A decision note with the replacement arrangement and review date.
Stop and investigate if: The same unused extension is repeatedly reinstalled because its history is unknown.
Avoid turning a useful local finding into a universal rule. A result can depend on content, configuration, staffing, timing, or the audience’s needs. Note those dependencies in the review. A good recommendation remains conditional where the evidence is conditional, and it distinguishes a sensible next experiment from a result that has already been established by a controlled observation.
Set rules for future additions
A short intake process prevents another accumulation. Ask what problem the new plugin solves, why existing features do not solve it, who will maintain it, and how it will be tested. Review renewals and abandoned trials periodically. The goal is a purposeful toolset that the team understands, not an arbitrary competition to achieve the smallest count.
Put it into practice
Require a purpose, owner, and test plan before adding another extension.
Evidence to keep: An extension intake checklist linked to the maintenance inventory.
Stop and investigate if: A temporary experiment becomes a permanent dependency without review.
Finish this check with a record another maintainer can understand later. Include the reason for the decision and any unfinished action, not just a mark saying complete. Revisit the check when its assumptions change. Keeping that link between a decision and its evidence makes future updates easier and prevents an old instruction from surviving after the situation it described has disappeared.
Worked example: a fictional scenario with concrete decisions
Begin with a fictional list containing a form extension, redirect manager, image optimiser, campaign popup, custom block library, backup tool, and several items with unclear purposes. The team does not select a deletion target by sorting the list alphabetically or by file size. It asks who requested each item and which visitor task relies on it. The popup appears to belong to an old campaign, while the redirect manager supports links that still circulate in earlier newsletters.
The first candidate is the campaign popup because its owner confirms that the campaign ended and no replacement offer uses it. Before deactivation, the maintainer saves the relevant settings and checks whether the extension also manages an embedded signup form. That hidden dependency would change the decision. If the signup belongs to another component, the popup can be tested independently. The audit has already provided useful information by separating an obsolete promotional feature from an active contact route.
In staging, disable the popup and inspect a normal article, the homepage, and the newsletter route. Use a logged-out browser state so administrator behaviour does not hide the feature. Record what changed and what remained. If the form stops appearing, pause and investigate rather than continuing through a predetermined removal list. The ability to reverse a small controlled change is what makes this exercise practical for a team that cannot afford an unexplained interruption.
The redirect manager remains because several old public links still need it. The team records the relevant mappings and considers whether a different maintained arrangement could own them later. This is a separate migration task with its own tests. Removing the extension merely to reduce the plugin count would create broken journeys without demonstrating an equivalent replacement. A purposeful dependency can be preferable to a lower count achieved by abandoning a responsibility the website still has.
The resulting inventory identifies a purpose and owner for each remaining extension, plus a short list of uncertainties requiring follow-up. The removed campaign tool has a decision record explaining why it was retired. Future requests for new plugins must name a problem, a maintainer, and an acceptance test. This fictional exercise demonstrates a process; it does not provide a security rating for any named extension or a measured speed improvement. Those conclusions require evidence from the real configuration under review.
