Most WordPress sites we are asked to look at are not broken. They are slow, a little neglected, and one unpatched plugin away from a bad week. The owner usually says the same thing: "It worked fine when we launched." That is true, and it is the problem. A WordPress site is not a finished object. It is a small system with moving parts, and the parts age at different speeds.
This is the checklist we run on a client WordPress site before we propose any rebuild. In most cases the fixes are small, and a rebuild is not needed.
Start by measuring, not guessing
Before touching anything we record three things on the live site: how long the home page and two or three key pages take to become usable on a mid-range Android phone over a normal mobile connection, how long the server takes to answer the first request, and how many plugins are active.
The last number is more useful than it sounds. A site with 40 active plugins has 40 places for code to be slow and 40 places for a security hole to appear. We do not have a magic limit, but when a client cannot tell us what half of them do, that is where we begin.
Write the numbers down. Without a before value, nobody can say later whether the work helped.
Performance: the usual causes, in the order we check them
1. Hosting and PHP version. If the site is on a cheap shared plan running an old PHP version, no amount of tuning will fix it. Moving to a supported PHP version and a host with a proper object cache often gives the largest improvement for the least work. We test the upgrade on a staging copy first, because old themes and plugins sometimes break on a newer PHP.
2. Page caching. Public pages should not be rebuilt by PHP and the database for every visitor. A page cache, either from the host or a well-configured plugin, turns most requests into static files. The things to be careful about are logged-in users, carts and checkout pages, and forms. Those must stay uncached or be handled deliberately.
3. Images. This is the most common reason a page feels heavy. Editors upload a 4 MB photo from a phone and the theme shows it at 400 pixels wide. We check that WordPress is generating properly sized versions, that the theme asks for the right size, that modern formats are served where the host supports them, and that images below the fold load lazily. Fixing this on a typical business site often cuts the page weight by more than half.
4. Plugins that do too much. Page builders, slider plugins and "all in one" packs often load their CSS and JavaScript on every page, even where nothing uses them. We either remove them, replace them with a small piece of theme code, or limit where their assets load. Sometimes the honest answer is that the site is built on a page builder in a way that cannot be made fast, and then we say so and discuss a lighter theme.
5. The database. Old revisions, expired transients and leftover options from deleted plugins pile up. On a site that has run for years, one autoloaded option table can quietly add a noticeable delay to every request. Cleaning it is routine, and we always take a backup first.
Security: boring work that prevents most incidents
In our experience, most compromised WordPress sites were not targeted cleverly. They were running something outdated that was known to be vulnerable, or someone reused a weak admin password.
What we put in place:
- Updates on a schedule. Core, plugins and themes are updated on a staging copy, checked, then applied to the live site. Security fixes are applied faster than feature updates. A site with no one responsible for this will fall behind.
- Fewer plugins, from known authors. Every abandoned plugin is a liability. If a plugin has not been updated for a long time and a better maintained alternative exists, we move off it.
- Admin accounts under control. Named accounts, not a shared "admin" login. Two-factor authentication for anyone who can publish or install. Former staff and agencies removed.
- Backups we have actually restored. A backup that has never been restored is a hope. We keep copies off the server and test a restore on staging at least once.
- Login and file protection. Rate limiting on the login page, file editing in the dashboard switched off, and correct file permissions on the server.
- Monitoring. An uptime check and an alert if core files change unexpectedly. We want to hear about a problem before the client's customers do.
None of this is exotic. The value is in doing it consistently and writing down who owns it.
When we recommend more than a tune-up
Sometimes the checklist shows a deeper issue. The theme is a heavily modified third-party one that nobody can update safely. The site depends on a plugin whose author has disappeared. The content model is forced into posts and pages when the business really needs structured data, such as properties, courses or products with filters.
In those cases we talk about options: a clean custom theme on the same content, a move of the heavy parts to a Laravel application behind the WordPress front end, or a headless setup. We covered when that last option is worth it in a separate post. We do not start there. Rebuilding is more expensive than fixing, and a client should only pay for it when the checklist says it is needed.
What a client can expect from us
For a typical business site, a performance and security review is a short engagement. You receive the before and after numbers, a list of what we changed, a list of what we recommend but did not change and why, and a simple maintenance plan with clear ownership. If the site is on a host we do not control, we tell you what to ask them for.
If you have a WordPress site that has grown slow or that nobody has looked after, send us the address and a short note about what it needs to do for your business. We will tell you honestly whether a few days of cleanup is enough or whether it is time to think bigger.
You can reach us through the contact page on this site. We are based in Lalitpur and work with clients locally and abroad.