Performance and security are usually managed by different people with different budgets, which obscures how often they produce the same answer. Both punish unnecessary third-party code. Both reward doing work on the server. Both improve when boundaries are explicit. Treating them as one project tends to produce better results than optimising either alone.
Every third-party script is both a performance and a security decision
A tag added for analytics or chat executes with full access to your page, including the forms on it. It also blocks rendering, adds connections, and its performance is outside your control. The question for each one is the same in both disciplines: what would we lose by removing it, and does that exceed what it costs us? The answer is frequently that it can go.
Do the work on the server
Rendering on the server and shipping less JavaScript improves load time on the devices most of your users actually have. It also shrinks the surface where client-side logic can be manipulated. Validation in particular belongs on the server — client-side checks are a usability feature, never a control, because anything enforced only in the browser can be bypassed by anyone who opens the network tab.
Set the headers
A content security policy, strict transport security, frame and content-type protections, and a sensible referrer policy are a short block of configuration that removes whole categories of attack. They take an afternoon, cost nothing at runtime, and are among the highest-value changes available on most sites.
Treat uploads as hostile
If users can upload files, validate the actual content rather than trusting the extension or declared type, cap the size at the boundary, store files outside the web root, and serve them from a separate origin with headers that force download rather than execution. Filenames should be generated rather than accepted.
Rate-limit anything that costs you something
Login, password reset, search, upload, and any endpoint that sends mail or calls a paid API. Without limits these become both an availability problem and a bill. With them, most automated abuse becomes uneconomic.
Measure on real conditions
Test on a mid-range phone over a constrained connection rather than on a developer laptop over office fibre. Most performance problems are invisible on the hardware they were built on, and most users are not on that hardware.
Make the boring things automatic
Dependency updates, certificate renewal, backup verification, and log retention all fail silently when they depend on someone remembering. Automate them, and alert on the failure of the automation rather than on the task itself.