WordPress performance and PHP upgrade
A home-improvement contractor was stuck on an unsupported PHP version because their custom theme was too old to move. We upgraded the stack, proved nothing visible changed, then went after the speed problems that were costing them in search.
The site ran on WP Engine, which was ready to move to a current PHP version. The business was not. Its custom Genesis child theme dated from 2019 and the owners were unsure it would survive the jump, so the whole site was pinned to PHP 7.4: no longer supported, increasingly incompatible with plugin updates, and a growing security exposure.
The brief was clear about one thing. They liked their site and did not want it to look or behave any differently afterwards.
We started on a fresh staging copy and recorded a full baseline of how every page type looked and behaved before touching anything. That baseline is what made the rest of the job verifiable.
Then we compared the rendered page code across nine different page types, before and after. It came out identical, byte for byte, on all nine. Site search returned the same results for the same queries. That is the difference between telling a client nothing changed and showing them.
Found along the way: two files in the site root printed the server's configuration, file paths and software versions to anyone who knew the address. Not an emergency, but they made the site easier to attack and had no reason to exist. We removed them and flagged an old database backup sitting in the same place.
With the upgrade done, the client asked us to sort out their pile of optimisation plugins and make the CDN pull its weight. The real problems were not where anyone was looking.
Pages jumped around while loading, and that layout shift was the one metric Google was failing the site on. The cause was two fonts arriving late and shifting the menu, which pushed everything below it down the page. Fixing it took layout shift from failing to effectively zero on desktop and mobile, and the same fix made mobile pages noticeably faster.
The site was paying for WP Rocket, but its optimisation service was being turned away by a firewall rule every time it tried to read a page. So instead of one optimised stylesheet, every page loaded 24 separate style files before anything could appear. Once the rule was corrected, WP Rocket did its job: one optimised block, and pages started showing far sooner.
We removed five plugins. One had switched off the browser's built-in image lazy loading and put nothing in its place. Another threw an error on every page load for a shopping cart the site did not have. We also cleared 143 leftover database records from plugins uninstalled years earlier and removed two stylesheets loading sitewide for features nobody used. Every form on the site was tested after each change.
"He helped update an old custom Genesis Child Theme to the latest version and ensure compatibility with PHP 8.4. Along the way, he discovered several other problems that he fixed at no cost. He exceeded my expectations in every way."
Don K., the client, review via Codeable
An Elementor review that was expected to cover about 25 pages turned out to need just four, because the rest only carried leftover markers. And around 30 posts had embedded videos that no longer played, because the service hosting them had shut down. Neither was in the brief. Both were handed to the client as a clear list so their team could act on them.
Client name and site withheld at our discretion. Figures are taken from the project record. The two client reviews quoted on this site are public on Nirmal's Codeable profile.
A plugin? A SaaS MVP? A WooCommerce system? An AI-powered feature? Tell us your idea. We'll help you figure out the way to build it.
No hard selling. No confusing technical talk. Just honest guidance from a senior development team.
Tell us what you need. A developer, not a salesperson, replies within one business day with questions or a fixed price.
