Performance

Measure before you change anything. A slow page can come from PHP, the database, an unoptimised image, a third-party script or a server that is simply too small.

Measure

• Lighthouse or PageSpeed Insights for the storefront, mobile profile.
• Server response time (TTFB) from the target region.
• Slow query log for menu, order and report queries.
• PHP-FPM and MySQL CPU/memory during peak orders.
• Real-device test on a mid-range Android phone.

Server and PHP

1. Use PHP 8.2+ with OPcache enabled.
2. Set opcache.memory_consumption to at least 128 MB for a large codebase.
3. Use PHP-FPM with a pool sized to available RAM, not the default.
4. Enable Redis or Memcached for cache/sessions if your build supports it.
5. Restart PHP-FPM and OPcache after every deploy.

Application cache

Cache configuration, routes and views in production. Clear the cache after changing settings or deploying. Never cache admin pages, authenticated API responses or payment callbacks at the edge; a cached order page can show one customer another customer's data.

Images and static assets

• Serve WebP/AVIF where supported, with a fallback.
• Resize menu images on upload; do not serve a 4 MB photo in a 300 px card.
• Use a CDN for images, CSS and JS.
• Set long cache headers on versioned assets; purge on release.
• Lazy-load below-the-fold images, but not the hero image.

Database

Index the columns used for order status, vendor, customer, zone and date filters. Archive old orders if the table grows into millions of rows. Run reports against a replica or a nightly aggregate if they compete with checkout. Check slow queries after every new report or module.

Load testing

Test the order path, not the homepage. Simulate 50–100 concurrent customers browsing menus and placing orders, plus vendor acceptance and rider updates. Watch the database connections and PHP-FPM queue. A site that loads fast but cannot accept orders at peak is not performant.