As a consultant I have the opportunity to look into other peoples work. I'm hired to do technical scans, write the technical demands on new projects and keep an eye on it if they are taken into account. In these reviews I notice a lot that Extbase is (ab)used for everything. And I mean for everything.

We all know how financially important it is for your app’s server architecture to handle peaks of load. Primarily, you need to understand the key actions that are necessary to enhance the efficiency of your server-side PHP code. But: Why do you need to take those actions? If your application is running smoothly right now, is it worth the effort? Some actions require big investments.

Let's put this right in your face: Extbase does costly operations regarding performance. In short; It is a performance killer. Especially on websites with large amounts of pages and records with high traffic.

Some of my clients are universities, which have huge websites. 100.000+ pages are very common. Therefor you need to be aware of every action you take, and that includes the use of Extbase.

Extbase is only helpful if you use the full featureset. Most of that featureset handles ORM, or Object Relational Mapping, using repositories. At universities much of the operations are connections with external systems, using SOAP, json, LDAP connections or even talking with Exchange Web Services. For all these operations you cannot use the Extbase repositories.

Recently I did a technical review on a newly delivered website. Pretty soon I discovered that almost every extension, XHR response or simple content element was done with Extbase. The reason for this can be multiple:

• The developers were lazy and just took what they knew
• The developers were not aware of the performance impact
• The developers were not familiar with other options

First of all, with every functionality you are programming, you need to think: Does it need Extbase?

I've seen multiple examples of content elements which could easily be rendered using a few lines of TypoScript and a FLUIDTEMPLATE content object, but were bootstrapping Extbase for each and every time one of these content elements were rendered.

TypoScript can be costly as well, regarding performance, but when applied properly, it can be way faster than Extbase.  

Most XHR (Ajax) responses need to be fast, very fast.

There are many examples on the internet describing how to make an XHR (Ajax) response in TYPO3. Surprisingly most of the examples are using a typeNum. Using a typeNum in the URL will bootstrap the whole frontend rendering of TYPO3. Add some Extbase to it as an extra flavour and you are applying everything what XHR does NOT stand for.

When you want to have fast responses, use the eID mechanism TYPO3 offers. With eID you can decide what to include. But be carefull with that. With a few lines of code you are back to zero (actually the miliseconds will rise). Try to keep your operations very basic, like raw database calls.

I'm aware not all XHR responses will do basic operations, but sometimes writing your own functionality without extensive API will be a bless for performance.  

When not the full featureset of Extbase is needed, you might consider writing everything with your own classes/objects. It probably will take more time than using Extbase (although in most cases I doubt that), but it will be much faster. Simply because you just use what you need.  

I'm not trying to give Extbase a bad name here. It is a Swiss army knife which takes away a lot of work from the developers. However, this comes with a price if not applied properly. Be aware of that at all time.