Layer Performance
If layers are taking a long time to load or render, the following issues may apply.
Use the Profiler First
Before changing layer settings, measure where the slowdown is occurring.
Use QGIS’s profiling tools to check whether the issue is related to project load time, map rendering, or a specific layer or data source.
See Project Configuration > Performance Testing for the recommended profiling workflow.
Server Capacity
Use the server’s performance monitoring tools to determine if the server is under load. If CPU is constantly under load, look at what services are running on the server. Anti-virus and other services may be consuming CPU and memory.
Data Format
Large file-based layers can perform very differently depending on the format used.
GeoJSON can be convenient, but it is often a poor choice for large local datasets in QGIS projects. If a large file-based layer is slow to load, test whether a format such as GeoPackage or SHP performs better.
Scale Dependency
If a layer is slow to redraw, consider whether it needs to be visible at every zoom level.
Applying scale dependencies can reduce rendering time by only drawing detailed layers when users are zoomed in far enough for the data to be useful. This is a usability and performance tradeoff, so choose scales that still suit the user workflow.
Projection Consistency
If many layers are being reprojected on the fly, rendering overhead can increase.
Where practical, keep source layers aligned with the project CRS to reduce unnecessary transformations during map display.
Data Location
Data stored on slow network paths can affect both load time and rendering performance.
If you suspect storage location is contributing to the issue, compare the performance of the same layer when accessed locally versus over the network.
Web-hosted datasets can also introduce latency and reliability issues. Where practical, prefer cached local copies or well-performing database sources for layers that are critical to the user experience.
Spatial Indexing
Layers usually render faster when the source data has an appropriate spatial index.
If a layer is consistently slow to draw or query, check whether the source format or database supports spatial indexing and whether an index has been created.
Generalised Datasets
Very large or complex layers can sometimes perform better when served from a simplified or generalised copy prepared specifically for Pozi.
This can be useful for datasets such as contours, environmental overlays, or other geometry-heavy layers where the full source detail is not needed at every scale.
Project Scope
Broad scale ranges and too many default-visible layers can significantly increase the amount of data requested when users first open the map or move around it.
Keep the active catalogue focused, remove obsolete or duplicate layers where possible, and be cautious about making large numbers of layers visible by default.
WFS Layers
Layers that are enabled for WFS are loaded by the Pozi app in full. This includes every feature, every geometry in its raw, unsimplified form, and every attribute.
When layers take a long time to load, the following issues may apply:
- The layer has a large number of features
- The layer has complex geometries
- The layer has a large number of fields
If you suspect that any of these could be contributing to slow loading, consider using WMS for your layer. You can configure the layer to use WMS instead of WFS by disabling WFS for the layer. By doing this, Pozi will instead utilise QGIS Server for rendering the layer for the current map view without loading the entire dataset.
If your project relies heavily on SQL Server and remains slow after the usual optimisation steps, QGIS metadata-based optimisation may also help reduce project or catalogue load times. See SQL Server.