Power Pages Performance: Why Your Portal Loads Slowly and How to Fix It

Why do Power Pages portals load slowly?

A slow portal page is almost always slow in one of two places, and the fixes are different. Either the server takes a long time to produce the HTML, because the page template runs many Dataverse queries through Liquid, lists or table permissions, or the browser takes a long time to download and run what the page sends, because of large scripts, stylesheets, images and client-side data loading. Customers experience both as "the portal is slow", which is why guessing wastes weeks.

The usual causes we find when reviewing a portal are consistent:

• Liquid templates that run a fetchxml query inside a for loop, so one page issues a query per row.
• Queries that return every column, or every row, when the page shows a handful.
• Lists or custom scripts that load a whole table into a client-side grid and page it in the browser.
• Table permissions with long relationship chains, applied to every query on the page.
• Several large JavaScript libraries and full theme stylesheets loaded on every page, most of them unused.
• Full-size images uploaded as web files and scaled down in the browser.
• Dataverse itself under load from plugins on retrieve or from batch jobs running during the day.

What should you measure first on a slow Power Pages portal?

Build a small, repeatable baseline before touching code, so every change can be proven. You do not need admin rights for any of this.

Pick the five pages customers use most and complain about, then capture each one the same way, several times, from the region where your customers are. Measure as an anonymous visitor and as a signed-in test contact with a realistic web role, because signed-in pages run table permission checks and are typically cached less. Record the first load after a quiet period separately from repeat loads, since the first request can be noticeably slower.

How do you reduce and cache Liquid queries on each page?

Liquid runs on the server for every request, so each fetchxml tag, entityview or list on a page is work done before the customer sees anything. Start with the page whose time to first byte is worst and open its web template and page template.

Once the query count is down, lean on the caching Power Pages already does rather than building your own. Power Pages caches Dataverse data on the server and offers output caching for the header and footer through site settings, with the substitution tag for small per-user fragments inside a cached block. Cache behaviour, the site settings involved and how quickly changes in Dataverse appear on the site vary by data model and release, so check the current Power Pages caching documentation before relying on a specific behaviour.

• Remove queries inside for loops. Replace the per-row query with one fetchxml that uses link-entity to bring the related data back in a single result.
• Request only the attributes the page renders, and set a count or top that matches what is shown instead of retrieving the whole table.
• Filter in the fetchxml, not in Liquid after the data has come back.
• Query once near the top of the template, assign the result to a variable and reuse it, rather than repeating the same query in several includes.
• Move rarely changing content, such as navigation, reference lists and footer links, into cached header and footer templates or content snippets.
• Keep per-user content, such as a greeting or a basket count, small and isolated so the rest of the template can stay cacheable.
• Review table permissions on the tables the page reads. Deep parent chains add cost to every query, and the correct model is covered in our table permissions guide, which should be your reference before simplifying anything.

How should lists and Web API calls page data on the server?

Page data on the server and send the browser only one page of rows. The most expensive pattern we see is a custom grid that calls the portal Web API or a Liquid JSON template for every row in a table and then pages, sorts and filters in JavaScript. It gets slower every month as the table grows, and it moves more data to the customer than they ever look at.

• Use the built-in list with a sensible page size, and keep the list view to the columns people actually need. The list pages on the server.
• When you call the portal Web API, always use $select, filter on the server with $filter, and request a page at a time with $top or a maximum page size preference, following the next link only when the customer asks for more. Check the current Power Pages Web API documentation for the query options it supports.
• Enable the Web API only for the tables and columns the site needs; the site settings that control this are a security decision as well as a performance one.
• Load dependent data when a customer opens a row or a tab, not for every row up front.
• Debounce search boxes so a query is not sent on every keystroke.
• If the portal slows down at particular times of day, check whether a batch job is consuming Dataverse capacity; our guide to protecting interactive users from Dataverse API limits covers that collision in full.

How do you slim down web files, scripts and CSS?

Every script and stylesheet referenced in the layout template is downloaded, parsed and often executed on every page. Makers can change most of this in the design studio code editor or the Visual Studio Code integration without admin involvement.

• Inventory every web file and every script or link tag in the layout, header and page templates, and remove the ones no page uses.
• Bundle and minify custom JavaScript into one file per purpose rather than many small files, and load it with defer so it does not block rendering.
• Load page-specific scripts only on the pages that need them, not in the site-wide layout.
• Remove unused CSS from theme and custom stylesheets, and avoid loading a second full CSS framework on top of the one the site already uses.
• Resize and compress images before uploading them as web files, use modern formats where the audience browsers support them, and set width and height to avoid layout shift.
• Avoid third-party widgets and tag scripts that are no longer used; each one adds requests the site does not control.

How do you lazy-load content below the fold?

Render what the customer sees first, then load the rest as it is needed. Add loading="lazy" to images below the fold, keep hero images small and served at the size displayed, and fetch data for tabs, accordions and secondary panels only when they are opened. For long knowledge or catalogue pages, render the first set of items on the server and load further items on request through paged calls. Measure again after each change: lazy-loading content that is actually visible on load makes the page feel slower, not faster.

Which Power Pages performance fixes need an administrator?

Some levers are not available to a maker, and asking for them with evidence from your baseline gets a much faster answer. Separate them clearly in your plan so maker work is not blocked waiting for admin decisions.

Portal performance work sits inside the wider question of whether the platform fits the portal. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

How do you check the portal stays fast under real load?

A page that is fast for one tester can still collapse when a renewal deadline or a campaign brings many customers at once. After the fixes, repeat the baseline and then test the busiest journeys at the concurrency you expect, with realistic signed-in users rather than an administrator account, from outside your corporate network. The planning for load checks before a go-live, and the concurrency sales has promised, is covered in our 90-day Power Pages delivery plan. Keep the baseline pages and timings in the repository or wiki so the next release can be compared against them.

When does a slow Power Pages portal need a redesign rather than tuning?

Tuning has run out when the baseline shows server time dominated by work the page genuinely needs on every request, when the journeys are highly interactive and application-like rather than forms and lists, or when performance targets are strict enough that you need full control over hosting, caching and front end build. At that point the choices are a partial redesign of the heaviest journeys, or a different front end.

The trade-offs between staying on Power Pages and a React or Next.js front end, including licensing as the audience grows and who maintains each, are set out in our comparison of a Power Pages portal or a custom front end. Where a portal on your own database is the better answer, our custom CRM development team builds it on React, Node.js, PostgreSQL or .NET.

How does Solzet help with a slow Power Pages portal?

We start with the baseline on your slowest pages and a written finding for each: where the time goes, which fixes a maker can make, which need an administrator and what each is expected to change. Then we make the template, query, list and web file changes, re-measure and hand over the baseline so your team can keep it fast. Power Pages build and rebuild work, including table permissions, web templates and load testing, is part of our Power Platform consulting service, delivered by senior consultants and full-stack developers with 8+ years of Dynamics 365, Power Platform and custom CRM work, directly or white-label for Microsoft partners.