Layout performance optimization
ExpertIdentify and resolve the most common layout design decisions that slow rendering: deep portals, unstored calc chains, and excessive conditional formatting.
What you'll learn
- The three most common layout performance bottlenecks
- How to profile a slow layout using the Data Viewer
- Specific changes that produce the largest performance gains
A slow layout almost always has one of three root causes: a portal with too many rows and deep unstored calculations in each row, conditional formatting on many fields with expensive expressions, or a layout based on a table occurrence that requires traversing a long relationship chain to display its fields.
Stuck is a valid status
Need a second brain on this one?
If this lesson just collided with your real schema, script stack, or deadline, book consulting and turn the confusion into a concrete plan.
Portal row count and unstored calculations
Every portal row evaluates every field on every row. A portal set to show 500 rows with 5 unstored calculations per row = 2,500 evaluations per render. Limit portal row counts and store intermediate calculations.
// Before: portal set to show 200 rows, 8 fields, 4 unstored calcs // → 200 × 4 = 800 evaluations per render // After: limit portal to 50 rows with a Show More button // → 50 × 4 = 200 evaluations // Use virtual list pattern for large sets
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo