Forum Discussion
Embed Web report Publish to Web with Azure Map visual
- 11 months ago
Hi lousmith22,
What you’re seeing is the Azure Maps visual doing a full "fit to data" and re-clustering a large set of points on first render. In a public Publish to web embed, that first pass can be heavy: the map requests tiles, applies clustering math, animates zoom/pan, and then repeats when anything changes (filters, auto-zoom, layers). That’s why slicing first (fewer points) feels instant.
Below is how I’d tame it.
- Keep Auto zoom Off and set a fixed default view
In the visual’s Format pane, turn Auto zoom Off and explicitly set Zoom, Latitude, and Longitude so the map starts where you want. Save the report with this state. (Details and property names in Microsoft’s “Get started” doc: Get started with Azure Maps Power BI visual.) - Load fewer points by default (use a bookmark)
Apply a page or visual filter like “Last 7 days,” Update a bookmark called “Default,” and set it as the page’s initial state. Add a “Show all” button for users who want everything. This avoids the heavy first render. (General perf guidance: Power BI optimization guide.) - Tune clustering to reduce recompute work
If you’re using Cluster bubbles, increase the cluster radius so the visual produces fewer clusters at wide zooms (less churn while panning). If available in your version, set sensible min/max zoom on layers so clustering doesn’t keep recalculating at extreme zooms. (See Azure Maps cluster/bubble docs: Cluster bubbles, and layer zoom options: Layers in Azure Maps.) - Prefer Latitude/Longitude over address geocoding
Feed lat/long columns into the visual instead of addresses. It eliminates geocoding work during render. (See “Fields” guidance in: Get started with Azure Maps.) - Cap or aggregate the data going to the visual
Use visual-level filters (e.g., TopN by a measure) or an aggregated table so the map isn’t receiving tens of thousands of points on first paint. (Data reduction strategies: Data point limits & strategies and broader tips: Optimization guide.) - Keep the first view light
Disable non-essential layers (traffic/reference/tile overlays) for the initial state. Re-enable via bookmarks if needed. Extra layers mean extra network/CPU on first paint. (Layer behaviors and zoom: Layers in Azure Maps.) - Sanity-check Publish to web constraints
Publish to web is supported for most reports but has specific considerations; make sure your scenario aligns and test the public embed after each tweak. (Overview: Publish to web considerations.)
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
- Keep Auto zoom Off and set a fixed default view
Hi lousmith22,
What you’re seeing is the Azure Maps visual doing a full "fit to data" and re-clustering a large set of points on first render. In a public Publish to web embed, that first pass can be heavy: the map requests tiles, applies clustering math, animates zoom/pan, and then repeats when anything changes (filters, auto-zoom, layers). That’s why slicing first (fewer points) feels instant.
Below is how I’d tame it.
- Keep Auto zoom Off and set a fixed default view
In the visual’s Format pane, turn Auto zoom Off and explicitly set Zoom, Latitude, and Longitude so the map starts where you want. Save the report with this state. (Details and property names in Microsoft’s “Get started” doc: Get started with Azure Maps Power BI visual.) - Load fewer points by default (use a bookmark)
Apply a page or visual filter like “Last 7 days,” Update a bookmark called “Default,” and set it as the page’s initial state. Add a “Show all” button for users who want everything. This avoids the heavy first render. (General perf guidance: Power BI optimization guide.) - Tune clustering to reduce recompute work
If you’re using Cluster bubbles, increase the cluster radius so the visual produces fewer clusters at wide zooms (less churn while panning). If available in your version, set sensible min/max zoom on layers so clustering doesn’t keep recalculating at extreme zooms. (See Azure Maps cluster/bubble docs: Cluster bubbles, and layer zoom options: Layers in Azure Maps.) - Prefer Latitude/Longitude over address geocoding
Feed lat/long columns into the visual instead of addresses. It eliminates geocoding work during render. (See “Fields” guidance in: Get started with Azure Maps.) - Cap or aggregate the data going to the visual
Use visual-level filters (e.g., TopN by a measure) or an aggregated table so the map isn’t receiving tens of thousands of points on first paint. (Data reduction strategies: Data point limits & strategies and broader tips: Optimization guide.) - Keep the first view light
Disable non-essential layers (traffic/reference/tile overlays) for the initial state. Re-enable via bookmarks if needed. Extra layers mean extra network/CPU on first paint. (Layer behaviors and zoom: Layers in Azure Maps.) - Sanity-check Publish to web constraints
Publish to web is supported for most reports but has specific considerations; make sure your scenario aligns and test the public embed after each tweak. (Overview: Publish to web considerations.)
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.