We make Drupal sites fast the boring way: real caching, fewer database queries, and lighter pages. Measured against Core Web Vitals, not vibes.
Base scope of work — applies to all tiers. See the tier comparison below for hours and SLA specifics.
Core Web Vitals and server response times measured on the same pages before and after, so the improvement is a number, not a claim.
Redis or Memcache, Dynamic Page Cache and BigPipe set up correctly, with the settings committed to your codebase.
Responsive image styles, WebP, lazy loading, and aggregated CSS and JS.
The slow Views and entity queries we found, rewritten or cached, with notes on what we changed.
Transparent process — you always know what stage we're at and what comes next.
We measure the current state: Core Web Vitals, server response, and where the time goes.
Blackfire or Xdebug on the real pages to find the expensive queries and hooks.
Caching, assets, images, and the top query offenders, in cost order.
We remeasure the same pages, show the delta, and commit everything to your repo.
Pick the level that fits your size and required response time. You can switch tiers between months.
We profile the site with Blackfire, measure Core Web Vitals on real devices, and hand you a prioritized report: what is slow, why, and what it costs to fix. Useful on its own, and credited toward a sprint if you book one.
We implement the caching layer (Redis or Memcache, Dynamic Page Cache, BigPipe), fix CSS and JS aggregation, rebuild the image pipeline with WebP, and clear the top database query offenders. Before-and-after numbers included.
For sites that spike. Everything in the sprint plus Varnish or a CDN in front, cache-tag invalidation that actually works, and a load test so you know the ceiling before your traffic finds it.
Scope transparency — no surprises in the monthly report.
Access we require — passed via secure channel (1Password / Bitwarden).
It depends on how much low-hanging fruit is left. Sites with no object cache and unoptimized images often drop server response from over a second to under 200 ms cached. We measure your baseline first so the promise is specific to your site, not a generic percentage.
Usually not. Most gains come from caching, queries, and assets. If your host is genuinely the limit, we will say so rather than hide it behind more configuration.
Yes. We use core and contrib caching APIs and commit the config to your codebase, so a minor update will not undo the work. We avoid clever hacks that break on upgrade.
We can, but Drupal 7 is past end of life. If you are on 7, the better spend is often a migration to Drupal 10. We will tell you when optimization is throwing good money after bad.
That is the Scale hardening tier: Varnish or a CDN, working cache invalidation, and a load test so you know the ceiling before a campaign finds it.
Most “slow Drupal” sites are not slow because Drupal is slow. They are slow because the render cache is half-configured, the front page runs forty uncached Views queries, and someone is serving 4 MB hero images straight from the theme. We fix the boring things first, in a fixed scope, and we measure the result against Core Web Vitals rather than a feeling.
The order is always the same: measure, then cut the biggest cost. In practice that means turning on Dynamic Page Cache and BigPipe properly, moving cache storage to Redis or Memcache so it survives a busy day, aggregating and deferring CSS and JavaScript, and rebuilding the image pipeline with responsive image styles and WebP. Then we profile the real bottlenecks with Blackfire or Xdebug and fix the Views and entity queries that show up at the top.
A cached page should reply in under 200 ms at the server. Largest Contentful Paint should sit under 2.5 seconds on a mid-range phone, and the layout should stop jumping around. If your site sees real traffic spikes, we put Varnish or a CDN in front and load-test it before we call the job done.
We do not rewrite your theme for free, and we will not move your site to a new host without asking first. If the honest fix is better hosting rather than more caching, we will tell you that instead of selling you a sprint you do not need.
When slow search is the bottleneck, the fix often starts with the Search API module and a Solr backend.
30-day warranty. If a change we made regresses performance or breaks a page, we fix it without a new invoice.
