Performance tuning: layer views, query limits and element count

The dashboard that froze during the storm. Picture a storm night. Winds knock out power across three counties, and the emergency operations center shares its outage dashboard with field supervisors, the call center and the mayor's office. Suddenly three hundred people open it at the same moment. Every panel shows a spinning wheel, and the map takes a full minute to draw. Nothing was wrong with the data. The dashboard was simply asking for far too much of it, far too often. In this lesson we'll fix that. When people rely on a dashboard to decide where to send crews, a fast dashboard isn't a nice extra. It's part of the job.

What you will learn. By the end of this lesson you'll be able to do three things. First, you'll use hosted feature layer views, which are saved, filtered windows onto your online map data, so a dashboard receives only the rows and fields it actually shows. Second, you'll set query limits and refresh intervals that fit the situation, which is different for a live storm than for a weekly service request summary. Third, you'll keep the number of dashboard elements under control and measure whether your changes really made the dashboard faster. All the examples come from utility and public works operations: outages, water main breaks and service requests.

Where the time goes. Let's look at what happens when someone opens a dashboard. Each element that shows data, such as an indicator, a chart, a list or a map, sends its own query to the feature service. The feature service is the online source that stores your map data and answers questions about it. A query is simply one of those questions, like "give me all open outages." The service searches, sends the results back over the network, and the browser draws them. So there are three costs: the search, the transfer and the drawing. Think of a restaurant kitchen. Every element is a separate order ticket. Twenty tickets for the same table take longer than five, even if the food is identical.

Layer views: a smaller window onto the same data. The single biggest win is a hosted feature layer view. A view is a saved window onto an existing hosted layer. It doesn't copy the data, so edits from field crews show up instantly, but it can hide rows and hide fields. Say your service request layer holds five years of history with forty columns. The dashboard only shows open requests from the last thirty days, using eight columns. Create a view with that row filter and those eight fields, then point the dashboard at the view. Every query now searches a far smaller set, and every answer is smaller. As a bonus, a view can be shared more widely than the full layer.

Worked example: how much smaller?. Let's put rough numbers on it, for a list element that has to page through every record. The full layer has two hundred fifty thousand rows and forty fields. Multiply rows by fields by an average of twenty bytes per value, and the full layer comes to two hundred megabytes. The view keeps about one point two percent of the rows, which is three thousand open requests from the last month, and just eight fields. That comes to zero point four eight megabytes, under half a megabyte. The service returns at most two thousand records at a time, which is its maximum record count, so the full layer needs a hundred twenty five requests. The view needs only two.

Query limits and refresh intervals. Next, limit what each element asks for. Indicators, and charts that group and count by category, are efficient because the server calculates the total and sends back one small answer, like "four hundred twelve open outages." A chart built feature by feature, like lists and tables, is heavier, because it fetches actual features. So cap them: a list of the twenty five newest main breaks is more useful than a list of two thousand. Then set the refresh interval, which is how often the dashboard asks again. How fast does your data really change? During a storm, every thirty to sixty seconds makes sense. For a weekly service request summary, every fifteen minutes is plenty, and nobody will notice the difference.

Element count multiplies everything. Now multiply. A dashboard with twenty four elements refreshing every thirty seconds sends each element's query a hundred twenty times an hour, which is two thousand eight hundred eighty requests per viewer per hour. If you cut that to twelve elements refreshing once a minute, you're down to seven hundred twenty. Refresh every five minutes and it drops to a hundred forty four, which is twenty times fewer than where we started. Now remember the three hundred viewers from our storm night, and you can see why this matters so much. Merge indicators that say similar things, remove panels nobody reads, and use one category selector instead of five near-identical charts.

Keep the map light. The map element is usually the heaviest part of a dashboard, so give it the same care. Start from a web map that holds only the layers this operation needs. A storm map needs outages, crew locations and road closures, not every asset layer in your organization. Set visible scale ranges so that individual meters or hydrants load only when someone zooms in. For dense point data, like thousands of service requests, turn on clustering or a heat map so the browser draws a few dozen symbols instead of thousands. Finally, trim pop-ups to the fields crews actually read.

Measure before and after. Don't guess, measure. Open your dashboard in Chrome or Edge, press F12 to open the developer tools, and choose the Network tab. Reload the page and look at the bottom line: the number of requests and the total data transferred. Write those two numbers down. Then change one thing, such as switching a list to a view, reload, and compare. Also test on a phone using mobile data, because a field supervisor standing next to a broken water main won't have office Wi-Fi. A small table of before and after numbers also makes a strong case to your manager.

Common mistake: one giant layer for everything. Here's the mistake I see most often. Someone points every element straight at the full master layer, the one with years of history and every field, and then adds a filter inside each element to show only open outages. It looks right on screen, but each element still searches the whole layer on every refresh, and the dashboard becomes harder to maintain because the same filter lives in ten places. The fix is to filter once. Create one view per purpose, for example "open outages, storm event" or "service requests, last thirty days", and share each view with the right group.

Exercise: tune one real dashboard. Before the next lesson, tune one real dashboard. Pick one you own, or make a copy of a dashboard built on a Living Atlas layer such as traffic incidents. Open the Network tab, reload, and record the number of requests and the total data transferred. Then create one hosted layer view with a row filter and only the fields you need, and repoint one list or map element to it. Review the refresh intervals, remove or merge one element nobody would miss, and measure again. Bring your before and after numbers with you.

Recap. Let's recap. First, hosted feature layer views are your biggest win: filter rows and fields once, and every element and every viewer benefits. Second, set sensible limits. Cap the features shown in lists, lean on indicators and charts that let the server do the counting, and match the refresh interval to how fast the data really changes. Third, remember that elements, refreshes and viewers multiply each other, so keep the element count low, keep the map light, and prove your improvements with before and after numbers from the Network tab. Next lesson, we'll learn how to update dashboards like this safely.