Field formatters are convenient precisely because they hide complexity — a date formatter handles timezones, an image formatter handles responsive derivatives, a link formatter handles URL generation. That convenience has a cost: every formatter runs its own logic, its own theme function, its own cache-metadata bubbling, for every single field on every single entity in a listing. Cap that cost by being deliberate about which formatters actually run.
What you'll learn in this lesson
- Why "just hide the field" and "use a lighter formatter" are different, both valid, techniques
- How Manage Display's per-view-mode settings let you use expensive formatters only where you need them
- Programmatically limiting formatter output for custom render paths
The cheapest fix: a dedicated, minimal view mode
Every content type has multiple view modes (Full content, Teaser, and any custom ones you add) — each with its own Manage Display configuration at /admin/structure/types/manage/article/display. A "Teaser" view mode rendering 20 articles in a listing has no reason to run the same heavy formatters as the "Full content" mode that renders one article on its own page. Hide fields entirely in Teaser that only matter on the full page, and swap expensive formatters (a full WYSIWYG-rendered body) for cheap ones (a trimmed plain-text summary) specifically there.
Programmatic formatter overrides
// In a preprocess function, force a lighter formatter for one specific
// render path without touching the shared Manage Display configuration.
function mymodule_preprocess_node(&$variables) {
if ($variables['view_mode'] === 'search_result') {
$variables['content']['field_body']['#formatter'] = 'text_summary_or_trimmed';
}
}field_example_color_background vs. a plain text formatter, from the Field API topic) is a bigger structural change. The programmatic override above swaps the plugin ID itself for one specific view mode, which is a heavier hammer — prefer the Manage Display UI when the change should apply consistently.Formatters that are expensive by nature
Some formatters are inherently costly regardless of settings: an image formatter generating a responsive image style derivative for the first time triggers actual image processing (resize, crop, encode) synchronously on that request. A rendered-entity-reference formatter (showing a full related node inline) recursively triggers that related entity's own view builder, with all of its own fields and formatters. Watch for these specifically when auditing a slow listing — they rarely show up as "field rendering" in a profiler, they show up as image processing or nested entity loads.
Quick check: a "Related Articles" field uses the "Rendered Entity" formatter, showing each related article's full Teaser view mode inline. Three related articles means how many total entity renders for that one field? If you said 4 (the parent entity plus 3 full nested renders), you've spotted exactly the kind of hidden cost this lesson is about.
Key takeaways
- Use dedicated view modes (Teaser, a custom "Search Result" mode) to keep expensive formatters confined to where they're actually needed.
- Hiding a field in Manage Display is cheaper than formatting it and hiding the result with CSS — the field never renders at all.
- Image and rendered-entity-reference formatters carry hidden recursive costs — audit these first in a slow listing.
- Programmatic formatter overrides in a preprocess function are a targeted tool for one specific render path, not a replacement for Manage Display configuration.
Coming up next
You've now trimmed both the load side (which entities/fields you fetch) and the render side (which formatters run). Next, we look at the query layer that sits underneath both: writing entity queries that are actually fast.