Start with the business and technical reality
Performance problems are often cumulative. A page can be slowed by a heavy frontend, inefficient database queries, cache misses, third-party calls and under-tuned infrastructure at the same time. Increasing server size may hide the symptom temporarily without changing the underlying behaviour.
We begin with evidence: request timing, application profiling, database activity, cache behaviour, search latency, queue health, browser metrics and traffic patterns. For Magento, this can also include indexing, Redis, OpenSearch, full-page cache, cron and extension behaviour.
The most useful optimisation programme prioritises improvements by customer impact, operational risk and engineering effort rather than chasing every metric equally.
When clients bring us in
- Pages are slow despite apparently sufficient server resources
- Core Web Vitals fluctuate between lab and real-user data
- Peak traffic causes errors or high response times
- Magento admin, indexing or cron is becoming slow
- Database or search load grows faster than traffic
- A CDN or cache layer is producing unexpected misses
What good delivery should leave behind
A successful engagement should improve more than the immediate feature or incident. It should make the system easier to understand, safer to change and more visible to the people responsible for operating it.
- Clear technical ownership and responsibilities
- Maintainable code and configuration
- Visible failures rather than silent data loss
- Controlled release and recovery paths
- Documentation for future developers and operators
- A sensible next-step roadmap rather than permanent firefighting
Technical depth across the parts that matter
The exact scope depends on the existing environment and commercial priorities. We focus on the areas that materially affect reliability, maintainability and delivery rather than adding process for its own sake.
Frontend
Reduce blocking resources, JavaScript cost, image weight, layout instability and inefficient rendering.
Application
Profile slow code paths, external calls, extension behaviour and repeated computation.
Database
Identify expensive queries, locking, indexes, connection pressure and data growth issues.
Caching
Assess page cache, Redis, CDN behaviour, invalidation and cache-key design.
Search & queues
Review OpenSearch/search latency, indexing, cron, consumers and background backlogs.
Infrastructure
Match PHP, web server, database and system resources to actual workload and failure patterns.
Common failure patterns that create unnecessary cost
Many technical problems are recurring patterns rather than isolated defects. Identifying them early helps avoid repeatedly paying to treat the visible symptom.
- Optimising only Lighthouse while backend response remains slow
- Caching configured but frequently invalidated
- Third-party API calls placed directly in customer requests
- Database tables growing without retention strategy
- Background jobs competing with storefront traffic
- Scaling vertically instead of removing repeated expensive work
A controlled route from uncertainty to production
We prefer visible, reviewable delivery. The exact sequence changes with the project, but the principle is to reduce uncertainty early and keep each production change understandable.
Technology is part of the answer, not the starting question
Performance work is most effective when measurement continues after the initial fix. Traffic mix, catalogue size, extensions, content and business processes change, so monitoring should make regressions visible before they become major incidents.
Where specialist capability comes from our wider engineering team, we are transparent about the proposed delivery model and match the person or team to the actual requirement rather than presenting a long list of technologies as if every project needs all of them.
Measure the customer path and the production workload together
A homepage can achieve a good laboratory score while logged-in account pages, search or checkout remain slow. Conversely, a heavy marketing page can make Core Web Vitals poor while the backend is healthy. We separate these concerns and then reconnect them to the business journeys that matter: category browsing, search, product view, cart, checkout, admin operations and scheduled processing.
For Magento and other dynamic platforms, we also look at what happens outside the browser. Indexers, imports, queue consumers and cron can compete for database, CPU or search resources. Improvements are prioritised so speeding one background process does not simply move the bottleneck into customer traffic.
Useful information for an initial assessment
- Pages or workflows users report as slow
- Traffic and peak-period behaviour
- Real-user or APM monitoring already available
- Infrastructure and caching/CDN architecture
- Recent changes correlated with regression
- Performance target tied to a commercial or operational outcome
Use the level of ownership that fits your team
Defined project
Midoriweb owns an agreed scope with clear milestones, acceptance criteria and release responsibilities.
Specialist workstream
Bring us into one technically difficult area while your existing team or agency owns the wider programme.
Team augmentation
Add developers to your existing process for a fixed period or an ongoing roadmap.
Ongoing technical partner
Combine support, maintenance, monitoring and planned improvement under continuing technical ownership.
Questions worth answering before work starts
Can you improve Core Web Vitals?
Yes, but we separate frontend user-experience metrics from backend response and infrastructure issues so improvements target the right layer.
Do you optimise Magento?
Yes. Magento performance is a major specialism and can involve PHP, database, Redis, OpenSearch, cache, cron, queues and extensions.
Will a bigger server solve the problem?
Sometimes additional resource is justified, but we prefer to measure whether the workload is inefficient before recommending infrastructure spend.
Can you investigate intermittent slowness?
Yes. Time-based monitoring and logs are often essential for issues that cannot be reproduced on demand.
Can you work with our hosting provider?
Yes. We can provide technical findings and coordinate changes where the infrastructure is managed by another supplier.
Can performance work be ongoing?
Yes. Monitoring and periodic review can protect gains as the platform changes.
Continue exploring
Have a requirement in this area?
Send the current situation, desired outcome, platform or systems involved and any important deadline. We can review the detail first or discuss it in a short consultation.