In the Drupal community, we always recommend using the Drupal API, and best practices for development, management and deployment. This is for many reasons, including modularity, security and maintainability.
But it is also for performance that you need to stick to these guidelines, refined for many years by so many in the community.
By serving many clients over many years and specifically doing Drupal Performance Assessments, we have seen many cases where these guidelines are not followed, causing site slowdowns and outages.
Here are some examples of how not to do things.
Logic in the theme layer
We often find developers who are proficient in PHP, but new to Drupal misuse its API in many ways.
In extreme cases, they don't know they should write modules to house the application logic and doing data access, and leave only presentation to be done in the theme layer.
We saw a large site where all the application logic was in the theme layer, often in .tpl.php files. The logic even ended with an exit() statement!
This caused Drupal page caching mechanism to be bypassed, resulting in all page accesses from crawlers and anonymous users to be very heavy on the servers, and complicating the infrastructure by over-engineering it to compensate for such a development mistake.
Using PHP in content (nodes, blocks and views)
Another common approach that most developers start using as soon as they discover it, is placing PHP code inside nodes, blocks or views.
Although this is a quick and dirty approach, the initial time savings cause lots of grief down the road through the life cycle of the site. We wrote an article specifically about that, which you will find a link to below.
Heavy queries in the theme layer, when rendering views
In some cases, the logic for rendering individual nodes within a view is complex, and involves code in the view*.tpl.php file that has SQL queries, or calls to heavy functions, such as node_load() and user_load().
We wrote an article on this which you can find the link to below.
Following Drupal's best practices and community guidelines is always beneficial. Performance is just one of the benefits that you gain by following them.
Visitor (not verified)
Sometimes it is otherwiseThu, 2016/01/21 - 19:17
I have a client whose website has over 20,000 customer nodes, and the customer node has lots of fields. For reports we often need to loop through all those nodes but just for one or two values. I have found that using entity queries is very slow for this and it is better to just query the field table for the value I need. This can be the difference between taking 10 seconds to generate the page vs. a minute or more. I will admit though that when having to change/save those nodes, I'd rather use node_save for safety sake and put up with the slowness, but that is rare and usually a one-time operation. And didn't entity queries completely change from D6 to D7 to d8 anyway?