Your site can benefit by removing certain unneeded or unused portions of code.

1. Don't use jQuery? Don't load it!

concrete5 uses jQuery extensively, and we love it (at least, I do.) However, it's not necessary for all front-end functions. If you're not using jQuery in your site on every page, remove it from the required header for users who aren't logged in. This will ensure that the site doesn't load unnecesssary and costly JavaScript, while also keeping it editable.

To do this: 

NOTE: In 5.5+, for javascript it is added to the footer via $this->addFooterItem instead of $this->addHeaderItem, also ccm.base.* is replaced with ccm.app.*

1. Copy concrete/elements/header_required.php into your local elements/ directory.
2. Open this file, and locate these lines:

3. Change those lines to this:

2. Don't make your theme editable.

I think the way we've enabled designers to make editable stylesheets is one of concrete5's coolest, nearly-unknown features. (Click here for an introduction and example.) However, if you're working on a site for a client, you probably don't need this. Furthermore, did you know that by enabling this feature, you're parsing a stylesheet for editable rules, when you don't need to?

Granted, the stylesheet gets cached, and you're probably not losing a lot of performance. But every little bit helps, and waste is waste. To change this, look for any lines in your theme that are called this way:

and change them to:

3. Make sure you're running an opcode cache on your web server.

This is a must. Make sure you're at least running Zend Optimizer on your web server. If at all possible, forego Zend Optimizer entirely, and use something like APC, XCache, or memCache

4. Building Custom Blocks? Don't put expensive logic in their constructor!

We've seen it frequently, and we may even have been guilty of it from time to time. What's that? Putting block startup logic in the block constructor (the __construct) method.

Why is this bad? Isn't that where it's supposed to go? Well, block's get instantiated at several points in concrete5, and that means that the block is going to run those functions every time that happens. Instead, stick your block startup logic in a method named "on_start." That method only runs once (plus, you can be sure it will run at the right point.) 

5. Use API Methods whenever possible.

Rather than making custom calls to concrete5 tables, use the API methods if at all possible. How does this help performance? Well, here's the trick: it doesn't always. Sometimes (*gulp*) it might even hurt performance. 

But - and this is a big but - in the long run, these are the best methods to use for performance and code accuracy. In version 5.4, we addressed caching for a large number of built-in objects, including attributes, users and files (pages and their attributes are already cached.) This means that if you use the built-in API for files or users, you'll automatically get caching, and that means performance increases.