Yes, I know, statics and static code analyzer has nothing common in the first place, but at last will code be better by using them. Harder. And so they contribute to a solid code structure that makes our applications more stable and better.

Roland Golla writes in the edition 5.2021 of the Entwickler Magazin: "Legacy code makes sick." His article is about PHPStan. How you integrate this static code analyzer in your development environment (and that doesn't mean your IDE only), not only to identify undiscovered sources of error but to improve your skills and your knowledge as developer.

You just can't know everything, development in PHP takes place in ever shorter release cycles. On the other hand, the customer's aging application is maintained. Every developer has to cover an enormous range of features that are made available by the PHP version used in the respective project.

In my opinion, the unbelievably beautiful and always fascinating thing about being a software developer is that you learn something every day. Really every day. And tools like static code analyzer can help. I think everyone knows the feeling when you look at code from three, maybe four years ago, shake your head and then after a courageous "git blame" would like to sink into the ground when you realize that you have produced this legacy code yourself.

Static code analyzers start with the first development and help you to write a lot of clean code. They don't necessarily help you to write better program logics, so you can still nest the business logic so uselessly and implement it difficult to understand. But hey, there are other tools like Performance Profiler (Blackfire etc.) that you can throw at this problem.

I can only recommend tools such as PHPStan, rector, Psalm etc. to anyone, in addition to the tools such as PHP-CS-Fixer or PHPMD, which have hopefully been used for years. To analyze code, refactor it, and most importantly, learn. Quasi as pair programming with a tool and not with another developer. Or as a code review before the actual code review.

Disclaimer: Roland Golla made the above-mentioned edition available to me free of charge, for which I thank him very much. I've lost sight of print products for a long time when it comes to programming or topics on the web. But once again it was a wonderful experience to have paper in hand while reading. I will not make a subscription now, but if I should ever travel by train or something again, I will look for such magazines at the station kiosk. Otherwise, I can recommend his YouTube channel "Never Code Alone", which I follow regularly. His videos are mainly about testing, refactoring and general topics about being a developer.

I haven't seen a message from all browsers besides Chrome that want to integrate Google's cookie “replacement” FLoC to track user behavior. But just to really make sure that your own website does not participate in the whole thing, you should prevent the whole thing with a Permissions Policy. Since there is currently only the OptOut using the HTTP response header, you have to put a stop to the whole thing either directly via the server configuration, the htaccess file or by setting the headers using TypoScript:

config {
    additionalHeaders {
		10.header = Permissions-Policy: interest-cohort=()
    }
}

Of course, please adjust the order in the additionalHeaders array, I'm assuming that there are a few more headers such as content security policy etc.

There are investigations for everything. Also for how the loading time of a website affects the possible bounce rate of the visitors. And it's hard to believe, but the bottom line is that the longer it takes a website to load, the higher the chance that the visitor will close the tab. Incredible.

So you should do everything possible to ensure that a website is delivered and, above all, displayed as quickly as possible. Apart from the fact that you should make sure that elements in the visible area are rendered first and certainly not flip back and forth while loading, another factor that can be easily influenced is keeping the number and the size of the required resources like stylesheets and JavaScript as small as possible.

The AssetCollector has been integrated with TYPO3 10.3. With this, scripts and stylesheets in Fluid files can be added to the rendering process with the ViewHelpers f:asset.script and f:asset.css. They behave similar to the renderAssetsForRequest already added in 8.6, with which you could render the corresponding code via the two Fluid sections HeaderAssets and FooterAssets.

The key difference is that, as the name suggests, the AssetCollector first collects the stylesheets and scripts and then only includes them once in the rendering. This means that I can reference the same JavaScript file in various Fluid files with the same name, which I need for example for a slider, but which is then only stored once in the document using a script tag at the end of the document.

Another advantage is that in this way you can ensure that only required resources are sent to the browser and not a JavaScript plugin for an accordion, which is not rendered on the page. Of course, this negates the concept that you always send the same resources to the browser so that it no longer requests them on the second page because it then takes them from its cache.

But with the simultaneous use of HTTP/2, which ensures that the resources for rendering the website are delivered to the browser before it even knows that it needs them, a speed advantage is still achieved in conjunction with the small data size and is especially noticeable in a faster rendering of the page. It is not at all bad that the resources are not integrated into the concatenation or compression process of TYPO3, as you were used to when you integrated your resources using TypoScript.

And so you have already made a few more visitors to your website happier.
And yes, I know, I have unfortunately not yet activated HTTP/2 on this page. It's not me. I'm sorry.