Systems | Development | Analytics | API | Testing

A full page cache is a powerful performance optimization for web-applications with numerous visitors. Instead of performing all the PHP and database work to render the same page over and over again, you cache the resulting HTML once and serve that time and again for a period. But there is room for even more improvement, especially in e-commerce applications that use full page caching.

In our second Release in 2025, we’re introducing additional performance insights to help you identify and resolve even more Bottlenecks faster and more effectively. Detailed information is now integrated in our Weekly Report, namely the number and types of the observations discovered in your application. We’re eager to make it easier than ever to stay on top of optimizations.

Every year, like clockwork, a new version of PHP is released at the end of November. Naturally, you want to know, how much performance gain is in this new release across common frameworks and applications? Our tests show that, in general, the performance between 8.2, 8.3 and 8.4 does not move much for a Laravel, Symfony and WordPress demo application. Upgrading to the latest PHP version is not a magic pill to improve performance.

Regular expressions are usually not top of mind when you think of performance bottlenecks in your application, but inefficient patterns or sub-optimal use of the APIs can make them slow. A wonderful learning opportunity for this is a recent roughly factor of 2x performance improvement patch to Doctrine DBAL’s SQL Parser. This patch was submitted by Soner from Shopware fame, thank you to him.

By default PHPs maximum execution time is set to 30 seconds of CPU time. Since your webserver has a maximum limit of requests it can handle in parallel, this leads to an interesting question or performance and webserver throughput.

How does your Shopware 6 store’s PHP backend performance compare to other operators of Shopware in general? To answer this question, we have aggregated and anonymized performance data from over 150 Shopware 6 stores over the last quarter and computed benchmark numbers to compare to for the most important page types: Product details, Category, Search, and Homepage.

For our first Release in 2025, we have cooked up more precise performance insights for you and can now, with Automatic Bottleneck Detection, serve you bottlenecks on a silver platter including recipes on how to fix them. Work on several improvements, like Native Worker Support in the PHP Extension, has kept us busy over the winter. A series of instrumentation improvements has chased away the winter blues and is now making way for a spring full of user-friendliness.

The year 2024 was special for us in several respects. It’s been a decade since the unveiling of Tideways’ predecessor, and we’ve come a long way since then. We would like to express gratitude to our customers, partners, colleagues, friends, and family for their ongoing support and dedication. Without you, we wouldn’t be where we are today. We are particularly pleased to be able to welcome many new partners this year.

We recently helped our customer Holocafé prepare its Laravel application for a TV appearance on the German edition of Dragons’ Den (Höhle der Löwen) and the corresponding peak in traffic. The primary change was to utilize Cloudflare as an HTTP reverse proxy to cache the main page of the site and a few other mostly static pages that users were most likely to click on. The expectation was that 80-90% of the curious users could be served with pages from the HTTP cache.

In applications that use closures excessively, understanding stack traces as part of the debugging experience has historically been complicated by the fact that the names of closures did not include the source location. In a PHP stack trace, whenever a frame was represented by a closure, it only contained the reference {closure} and the namespace the closure was declared in, leading to all closures within a namespace looking identical.