A performance-heavy Laravel batch, and the honest kind: as much about what didn’t work as what did, including a Laravel Octane experiment that got measured and reverted.
Jason McCreary’s Fast Laravel Case Study is a proper walkthrough of making Laravel News itself faster with plain Cloudflare page caching. The interesting part is that Laravel News looks uncacheable (hourly content, rotating sponsor cards, a newsletter form), and he cached it anyway. Three refactors did it: converting every page from Livewire to Blade components (only the newsletter form actually needed reactivity, so the rest were shedding wire: state that broke when cached and 419’d), swapping dynamic segments like the sponsor banner to Alpine AJAX fragments that hydrate a cached shell, and purging via model events plus a piggybacked scheduled command for scheduled posts. Result: 15% → 60% cached, edge responses around 20ms. No paid services, just HTTP caching done systematically.
Mattias Geniar’s Octane vs PHP-FPM is the counterpoint I wanted after last batch’s Octane-in-production piece. He moved a fleet of Oh Dear uptime-checker boxes from PHP-FPM to Octane on FrankenPHP, measured real traffic before and after, and moved every one of them back. The reason is clean: Octane’s whole trick is skipping the framework bootstrap per request, and for an I/O-bound workload (each request is a ~400ms outbound check), that bootstrap is a rounding error. Warm workers even pushed idle-box CPU up. The one real win was lower CPU peaks on busy boxes. His rule: Octane earns its keep on CPU-bound, framework-heavy requests served at high rates, not on anything dominated by waiting on the network. Measure your own workload, not the hello-world benchmark.
Daniel Petrica’s LaraPlugins Performance Audit is a fellow Romanian’s 3AM war story turned into 12 concrete fixes, all with real numbers. An 8GB VPS pinned at 90% memory, 12 Horizon supervisors with maxJobs: 0, and a weekly job that fired 50,000 Cloudflare purge jobs in one cycle. The fixes are the good kind of boring: cap maxJobs everywhere so workers recycle memory, a global scope to stop loading a fat packagist_metadata JSON column on every query, three indexes he’d simply forgotten, and, my favourite, collapsing 50,000 purge jobs into one self-rescheduling job that batches URLs through a Redis SADD set (which dedupes for free). His closing line lands: when monitoring goes noisy you either fix the cause or tune the alerts, and every day you tune the alerts you train yourself to ignore your own dashboard.
The Developer Awam piece on concurrency, parallelism & async in Laravel 13 + Livewire 4 reframes a class of slowness as an execution-strategy problem, not a database problem: the dashboard that calls three APIs in series, the export that blocks for ten seconds. It’s a member-only Medium story so I only read the framing in full, but the distinction it draws (concurrency vs parallelism vs async, and where each fits in a Laravel/Livewire request) is the right mental model, and Laravel’s own concurrency helpers plus queued/deferred work are the tools it points at. Worth it if you keep reaching for a queue when what you actually want is a parallel fan-out.
Tomáš Votruba’s 7 Tips to Improve Your ECS Config is a back-to-basics cleanup for anyone whose ecs.php has sprawled. His line (“if it’s longer than 15 lines, you’re probably doing it wrong”) is the whole ethos: prefer sets over listing individual rules, use withRootFiles() instead of naming stray files, and lean on the new levels to introduce a coding standard step by step (perfect for agent-driven per-rule PR trains on a legacy codebase). The final config he strives for is three lines of prepared sets plus paths. Feed it to your agent or learn it yourself; either way it’s a good spring clean.