3EI Moved Off WordPress — 42% Lower Cost, 75% Faster, Zero Malware
3EI Investigations International Solutions has been licensed since 1996 and runs investigative, forensic, protective, and training operations across three continents. Their clients range from individuals and law firms to celebrities and Fortune 1000 companies. Discretion is the product.
Which made the state of their WordPress site a real problem, not a cosmetic one.
The malware cycle
The site was compromised repeatedly. Not dramatically — the ordinary WordPress pattern: an outdated plugin, injected scripts, a cleanup, a few quiet weeks, then the same thing again. Each round meant a restore, a scan, a round of password rotations, and a stretch where nobody could be certain what a visitor was actually being served.
For a security firm, a site quietly serving injected code to prospective clients is not an IT annoyance. It is a credibility problem in the one area where you cannot afford one.
Why it kept happening
The vulnerability was structural rather than any single mistake. A WordPress install is a live PHP application with a database, a plugin tree, and a public admin login. Every plugin is code you did not write, running with real privileges, updated on someone else’s schedule. The attack surface is large by design, and it grows every time you add a feature.
You can harden it. Plenty of people do. But you are managing risk continuously rather than removing it.
What we built instead
We redesigned the site and rebuilt it as a statically served front end on SBC Cloud, with dynamic pieces handled by managed services rather than a monolithic application. There is no PHP process to exploit, no plugin tree to keep patched, no public admin login to brute force, and no database sitting behind the front page.
- Content served from the edge rather than generated per request
- No runtime plugin surface — the largest single source of WordPress compromise simply is not present
- Managed TLS and automatic network-level DDoS protection at the platform layer
- Immutable deploys — rolling back is redeploying a known-good build, not restoring a database
Cost and performance
The security case alone justified the move. The economics made it straightforward.
Monthly infrastructure cost fell by roughly 42%. The old stack was paying for managed WordPress hosting, a security plugin subscription, a backup service, and a CDN add-on — four line items doing what the platform now does as standard.
The performance side is independently measured rather than asserted. GTmetrix tested the live site on 24 August 2026 from Seattle, and the full report is linked at the end of this article.
Grade A, 93% performance, 87% structure. Largest Contentful Paint at 595ms against a 1.2s threshold, Cumulative Layout Shift at 0.04 against 0.1, fully loaded in 1.2s with a 113ms time to first byte and a 29ms server response. For a site carrying nearly five megabytes of video on the homepage, that is a good result.
What the report also says
Two things are worth reporting honestly, because anyone can open the same link and find them.
Total Blocking Time is 155ms, against a 150ms threshold — GTmetrix marks it “OK, but consider improvement” rather than good. The cause is identifiable: roughly 683ms of JavaScript execution, most of it in a single main.js. Speed Index is 1.8s against a recommended 1.3s, and total page weight is 6.02MB, of which 4.82MB is video. The report flags that payload as its highest-impact issue.
None of that is hidden by the grade, and none of it is finished work. Next passes are deferring offscreen images, serving the remaining JPEGs in next-gen formats, and setting explicit dimensions on the logo to remove the last of the layout shift. A site is a thing you keep tuning, not a thing you launch.
Page load time improved by about 75%. That is not a tuning result; it is what happens when a page stops being assembled by PHP and a database on every request and starts being served as a finished document from the edge. The site also carries video on the homepage, which is exactly the kind of payload that punishes a slow origin.
Faster, cheaper, and safer usually involves a trade. Here they were the same decision — because the thing generating the cost was also the thing generating the risk.
What 3EI actually notices
Not the architecture. The site loads immediately on a phone in the field, the contact form arrives, and nobody has been asked to approve an emergency cleanup in six months. The operational overhead that used to sit quietly on their team is gone.
Where this argument stops
It is worth being precise about what the security claim covers, because it does not extend to everything we build. A static site has a very small attack surface because there is genuinely nothing there — no CMS login, no PHP process, no database. Requests for /wp-admin, /wp-login.php, /xmlrpc.php or /wp-config.php do not get blocked so much as they find nothing to reach.
The moment a project adds serverless functions, a database, payments, authentication, or object storage, you have an application backend again — and with it the normal obligations: secrets management, API authorization, input validation, database permissions, rate limiting, webhook verification. That work does not disappear because the front end is static. We treat those as two different classes of engagement, and we would rather say so than let one claim do work it cannot support.
Is this right for every site?
No, and it is worth being clear about that. If a site depends on a large plugin ecosystem, a store with complex inventory logic, or non-technical editors publishing many times a day through a familiar interface, WordPress may still be the right answer and the correct move is to harden it properly.
The calculus changes when the plugin dependency is thin, the content changes at a manageable pace, and the cost of a compromise is high. That describes a lot of professional services firms — and it described 3EI precisely.
If you are running a WordPress site you no longer trust, the analysis is worth doing before the next cleanup rather than after it.