---
title: "Caching for Extbase plugins"
manual: "TYPO3 Explained"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3coreapi:extbase-caching@main"
source: "ExtensionArchitecture/Extbase/Caching/Index.rst"
rendered: "2026-09-17T18:20:57+00:00"
---

# Caching for Extbase plugins {#caching-for-extbase-plugins}

TYPO3 caches the rendered output of a page so that the work to build it runs
once and every following visitor is served the stored result. This is what keeps
a content-heavy site fast: the database queries, the template rendering and any
business logic behind a page happen on the first request, and the cached output
answers the rest.

An Extbase plugin is part of that picture. By default its output is cached
together with the page it sits on, so a plugin action runs once and its result
is reused. That default is almost always what you want — but a plugin can also
opt out of it, and the moment it does, the trade-offs shift onto you. This
chapter is about those choices: when a plugin is cached, how to keep it cached
while still showing fresh data, and what it costs when you turn caching off.

> [!NOTE]
> **See also**
>
> This chapter covers only the Extbase-specific side of caching. For the
> caching framework itself — cache frontends and backends, configuration and
> the page cache — see [Caching](https://docs.typo3.org/permalink/t3coreapi:caching).
> The general concept of cacheable versus dynamic content is explained there
> through the [USER_INT](https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/ContentObjects/UserAndUserInt/Index.html#cobj-user-int)
> TypoScript object, which is exactly the mechanism an Extbase plugin uses under
> the hood.

## Why caching matters for an Extbase plugin {#why-caching-matters-for-an-extbase-plugin}

Every Extbase plugin is rendered as a content object on the page. In its default,
cached state that content object is built once and its output is stored in the
page cache; subsequent requests for the same page never re-run the action. A
plugin listing conferences runs its repository query on the first visit and then
serves the same markup to everyone until the cache is cleared.

Two things change that default:

-   **Declaring an action non-cacheable.** An action registered as non-cacheable
    is rendered on *every* request, outside the page cache. This is necessary for
    genuinely dynamic output, but it moves the responsibility for performance from
    the framework to you.
-   **Writing records through a repository.** When your plugin saves, updates or
    deletes a record, the cached pages that show that record must be refreshed —
    otherwise visitors keep seeing stale content. Extbase handles this
    automatically by default.

Both are covered in the pages below.

## What this Extbase caching chapter covers {#what-this-extbase-caching-chapter-covers}

**[Non-cacheable actions](https://docs.typo3.org/permalink/t3coreapi:extbase-caching-noncacheable@main)**

When and how to make an action non-cacheable with
`configurePlugin()`, what USER_INT rendering really costs, and how to
keep a non-cached plugin fast.

**[Cache tags](https://docs.typo3.org/permalink/t3coreapi:extbase-caching-cachetags@main)**

How Extbase tags the page cache for the records a repository reads, so
those pages can be invalidated precisely instead of disabling the cache.

**[Automatic cache clearing](https://docs.typo3.org/permalink/t3coreapi:extbase-caching-autoclearing@main)**

How saving through a repository clears the cache of the affected pages,
what `enableAutomaticCacheClearing` controls, and where it
stops.