WordPress, Magento, OpenCart, and Drupal speed work, scoped from real Lighthouse field data and slow-query logs. Not a 5-plugin checklist.
Most agencies sell speed optimization as the same five-plugin install regardless of CMS: cache plugin, lighter theme, Cloudflare, image lazyload, invoice. That gets a one-week pop in Lighthouse score and the same TTFB six months later. The hard wins live below the cache layer.
Bloated plugins firing autoload on every request. MySQL queries written against a 200-row catalog that now has 40,000 rows. Themes loading 18 webfonts when two would do. Background HTTP calls in admin pages slowing every editor action. None of that gets fixed by a plugin.
We start every engagement with three measurements: a Lighthouse field-data report from the last 28 days, a query log captured over a representative production day, and a render trace on a real device over 4G. The fix list comes from those three artifacts. Cache layers and CDNs go on at the end, after the underlying app is fast, not before to mask the fact that it isn't.
WordPress sites usually fail on plugin sprawl. 32 active plugins, six firing autoload options, two doing background HTTP calls on every admin load. The fastest unlock is a plugin audit, then deferred JS, then object caching with Redis. Hosting moves the floor: Kinsta or WP Engine over a $5/month shared plan changes TTFB from 1.4 s to 180 ms.
Magento 2 fails on database. Un-indexed queries, EAV joins, full-page-cache misses on logged-in users. We run bin/magento indexer:status, profile the slowest 50 queries, rebuild what is missing. Varnish in front of FPC, WebP for product images, ElasticSearch for catalog search.
OpenCart sites are almost always template-bound. Nested foreach loops in tpl files, $modify->image() called inside loops, no opcache. The fix is a front-end strip and a rebuild around server-side caching.
Drupal performance is mostly cache-tag hygiene and Views query rewrites. BigPipe and Lazy Builders cover the rest. Most production Drupal sites we audit are leaving 60% of cache hits on the floor because tags invalidate too aggressively.
Two to four weeks for a single site, including the audit week. Bigger Magento and Drupal projects can run six to eight if the database needs work. We send a fix-list with effort estimates after the first week so you can scope what we ship.
No, and you should be skeptical of agencies that do. PageSpeed Insights varies between runs by 5-15 points on the same URL. We commit to Core Web Vitals targets instead: LCP under 2.5 s, INP under 200 ms, CLS under 0.1, measured on real-device field data over 28 days.
Optimization keeps your codebase, theme, and plugins in place and removes what is slow. A rebuild starts from scratch with a new theme or new plugins. We recommend optimization first when 70% of the slowdown is fixable with cache tuning and plugin removal. We recommend a rebuild when the theme or core architecture is the problem.
We test on a staging clone first. Every plugin removal goes through a smoke test of the public site and the admin flows your team uses. Anything we are unsure about, we keep and just disable autoload, which fixes the speed cost without removing the function.
Yes, when it is part of the speed plan. For WordPress we move to Kinsta, WP Engine, or Pantheon depending on the budget and team. For Magento we move to a managed VPS with Varnish and Redis pre-configured. Migration is a separate scope of two to seven days on top of the optimization engagement.
Lighthouse field data from CrUX, a synthetic test from WebPageTest on a baseline device, and a server-side TTFB log captured from your monitoring stack. We report before-and-after numbers in a one-page summary at the end. If the numbers do not move, we keep working under the same fee.
30 minutes with a senior engineer. No salespeople. We respond within one business day with a brief outline.
Send a project brief →