There are many nice articles about web site performance optimization accross the Internet. As long as this is really important topic, I think there can't be too many of them. That's why I'd like to share some suggestions on how to make Kentico run faster.
Scheduled Tasks: turn off any unnecessary scheduled tasks; make sure all enabled tasks are running with meaningful frequency
Output Filters: output filters goes through rendered page markup and fix some elements within it. If you feel confident about quality of your HTML you are good to turn them off. Keep in mind there might be a lot of markup added by content editors through editable text web part
Caching: Kentico provides us with great caching capabilities out of the box - do not hesitate to use it! Data caching is a key to a good performance. Kentico allows us to cache almost everything and almost everywhere. With cache dependencies we can easily specify when system should update cached data. We can cache data retrieved with data source web parts, viewers, macro, page data and any data we read from database in custom code. It is extremely useful with custom transformation methods
Macro: make sure all macros are signed with valid signature
Event Log: check event log for any errors in it and resolve if any
Debug: make sure debug is disabled in production. It could be enabled only in case you need to troubleshoot some issue and should be disabled immediately after completion
Continuous Integration: CI is developer’s tool to synchronize their working environments. It should never be used to transfer changes from QA to production, which means it should never be enabled in production
CSS: put all you styles into (one) Kentico stylesheet. Try to avoid adding CSS into transformation, web part containers, etc.
Resources compression: allow resources compression and minification of JS and CSS. This will increase processing for the first request, but speed all furthers ones
CMS Tree: keep your CMS Tree organized and well structured, avoid placing 100500 pages under the same parent, use a couple of levels instead. In addition to performance benefits you get, this will allow content editors to navigate easier
Web part IDs: do not populate/use web part name, you can always specify some meaningful ID for web part, which will help you to identify the responsibilities of the actual web part
Content before/after: Kentico provides us with web part containers, which is very convenient way to wrap web part with some markup. Unfortunately, is not efficient, as it adds extra loading and processing. Content before/after is much more efficient, as it loads along with other properties of the web part, however it is not convenient as it requires knowledge of HTML
Check permissions: make sure this property of the web part is set to false in case of public content. This also could be setup on the global level in Settings in case of publicly available web site
Columns: make sure you're loading only data you need. If you leave this property of a web part blank, Kentico will load all available column. In some cases, number of column could be around 200. Usually we need 5-20 columns on page
Files: store files in file system - it is much faster to load them from there. Also you do not overwhelm your database with gigabytes of files
Media: store all media files into Media Library instead of CMS Tree
Data: often we choose custom page type as best fit to store some data and/or content. Unfortunately, page types are not efficient performance wise. Kentico stores pages’ data into three different database tables and has a lot of processing around it. There are many benefits and features available for page types, those are not available for other objects: workflow, security, localization, same page type stored it in different locations, etc. But there are situations, when we do not need any of those features. In those cases, I'd recommend you to consider Custom Tables or Custom Modules. With any of those two you can easily provide content editors with nice interface to manage those objects. This also help you to prevent enormous amount of pages.
Tips I've mentioned here are not requirement and might not be even possible in some cases, but be sure to consider them.