[Bug]: why raster rendering is so slow compared to the same WMS layer rendered in QGIS Desktop

[gioman]

What is the bug? (in English)

Rendering time for a raster layer (geotiff) is much slower on Lizmap (3.9.0) compared to the rendering time of the same layer pushed as WMS (from the same lizmap project) in QGIS Desktop. "Fun" fact: lowering the raster resolution from 1 to 10m improves things a little... it should make a huge difference!

Steps to reproduce the issue

Lizmap 3.9.0 installed with #5567 (comment)

Can't install/test 3.9.1 because of #5964

Versions, safeguards, check summary etc

Versions :

• Lizmap Web Client : 3.9.0 - commit 4a0d5ea 4a0d5ea52
• Lizmap plugin : 4.5.3
• QGIS Desktop : 3.40.8
• QGIS Server : 3.40.10
• Py-QGIS-Server : 1.9.6
• QGIS Server plugin lizmap_server : 2.13.1

List of Lizmap Web Client modules :

* lizmapdemo : 3.6.0a1

List of safeguards :

* Mode : normal
* Allow parent folder : no
* Prevent other drive : yes
* Prevent PG service : yes
* Prevent PG Auth DB : yes
* Force PG user&pass : yes
* Prevent ECW : yes

Check Lizmap plugin

• I have done the step just before in the Lizmap QGIS desktop plugin before opening this ticket. Otherwise, my ticket is not considered valid and might get closed.

Operating system

Ubuntu 24.04 (server) Windows (browser)

Browsers

Chrome

Browsers version

latest

Relevant log output

[gioman]

Lizmap:

Screen.Recording.2025-08-24.192739.mp4

QGIS:

Screen.Recording.2025-08-24.192933.mp4

[gioman]

Screen.Recording.2025-08-24.193130.mp4

[Antoviscomi]

@gioman I suppose that this is the answer:

1. QGIS Desktop acts a Local Rendering
   When you're using QGIS Desktop and adding a WMS layer, you are making requests to a remote server. The key difference is that once the data is received, the rendering, styling, and display of that data are handled by your computer's local resources.
   Single Request, Local Processing: When you zoom or pan, your QGIS client sends a request to the WMS server for an image (or a set of tiles) for the new view. The server processes this request and sends back the image data. Your local machine, with its CPU and GPU, is responsible for rendering this single image on the screen, overlaying it with other local layers, and applying on-the-fly CRS transformations.
   Persistent Connection: QGIS maintains a continuous, direct connection to the WMS server, and data is transferred efficiently. The bottleneck is primarily the server's processing time and your internet connection speed to download the image.

2. Lizmap acts by Server-Side Rendering and Network Demands
   In contrast, Lizmap is a web client that uses a QGIS Server (or PY-QGIS-Server) as its back-end. This changes the entire dynamic.
   Multiple, Separate Requests: When you load a Lizmap project, the web browser isn't making a single, large request. Instead, it sends multiple, individual requests to the QGIS Server for each layer or group of layers. These requests are for small, square tiles that make up your map view. For a single screen view, there can be dozens of tile requests per layer.
   Server Processing and Bandwidth: For every pan or zoom, the QGIS Server has to process each of these tile requests. This involves loading the QGIS project file, fetching the underlying data, rendering each small tile according to the project's symbology and styling, and then sending each of those small images back over the network to the client. This puts a heavy load on the server's CPU and consumes a significant amount of network bandwidth. The larger the map and the more complex the styling, the more requests are made and the more data is transferred.
   Client-Side Assembly: The web client (your browser) then has to download all of these individual tiles and piece them together to form a seamless map. This process, coupled with the initial latency of each network request, is why Lizmap often feels slower than QGIS Desktop.

[mdouchin]

Indeed, this should not be the case.
What is the format declared in the Layers tab of the plugin, group "Map options"

If it is PNG, try with WebP or JPEG, which produce images 5 times smaller

[gioman]

@gioman I suppose that this is the answer:

1. QGIS Desktop acts a Local Rendering
   When you're using QGIS Desktop and adding a WMS layer, you are making requests to a remote server. The key difference is that once the data is received, the rendering, styling, and display of that data are handled by your computer's local resources.
   Single Request, Local Processing: When you zoom or pan, your QGIS client sends a request to the WMS server for an image (or a set of tiles) for the new view. The server processes this request and sends back the image data. Your local machine, with its CPU and GPU, is responsible for rendering this single image on the screen, overlaying it with other local layers, and applying on-the-fly CRS transformations.
   Persistent Connection: QGIS maintains a continuous, direct connection to the WMS server, and data is transferred efficiently. The bottleneck is primarily the server's processing time and your internet connection speed to download the image.
2. Lizmap acts by Server-Side Rendering and Network Demands
   In contrast, Lizmap is a web client that uses a QGIS Server (or PY-QGIS-Server) as its back-end. This changes the entire dynamic.
   Multiple, Separate Requests: When you load a Lizmap project, the web browser isn't making a single, large request. Instead, it sends multiple, individual requests to the QGIS Server for each layer or group of layers. These requests are for small, square tiles that make up your map view. For a single screen view, there can be dozens of tile requests per layer.
   Server Processing and Bandwidth: For every pan or zoom, the QGIS Server has to process each of these tile requests. This involves loading the QGIS project file, fetching the underlying data, rendering each small tile according to the project's symbology and styling, and then sending each of those small images back over the network to the client. This puts a heavy load on the server's CPU and consumes a significant amount of network bandwidth. The larger the map and the more complex the styling, the more requests are made and the more data is transferred.
   Client-Side Assembly: The web client (your browser) then has to download all of these individual tiles and piece them together to form a seamless map. This process, coupled with the initial latency of each network request, is why Lizmap often feels slower than QGIS Desktop.

@Antoviscomi thanks for the reply. While I understand what you say, I'm not convinced. In both cases the requested image (in the same format and extent) is generated by the same QGIS server installation, on the same server. But for some reason in QGIS Desktop rendering is much faster. If you have a look at the short videos I posted you can see that there are no other layers involved. Also seems weird to me that testing a version of a raster at a much lower resolution than the original didn't yielded much improvement. Common sense says that the issue in not in QGIS Server (or the way it was installed/deployed) but rather in LMWC or one of its underlying libraries. I'm trying to gather some feedback here, trying to understand if is only a problem in my side or not. Because if is not a local issue than I think we have a problem, raster rendering is very slow.

[meyerlor]

@gioman i think this is more a individual problem then a general LWC one. for comparison, here a raster of one of my projects (the original raster is a 10cm orthofoto - pyramids are calculated, the gif you see was recorded on a 1:10.000 scale)

You can test for yourself (it's an open portal):

The original orthofoto i recieve is usually a set of tiles in raw .TIF format - this particiular image is originally 12GB. I convert it to CloudOptimizedGeoTIFF with this command:
C:\OSGeo4W\bin\gdal_translate.exe VRT.vrt raster.tif -a_srs EPSG:25832 -of COG -co BLOCKSIZE=512 -co COMPRESS=JPEG -co QUALITY=75 -co BIGTIFF=YES -co NUM_THREADS=ALL_CPUS -co OVERVIEW_RESAMPLING=AVERAGE -co OVERVIEW_COUNT=8 - before, i stitch together the tiles into one VRT with: C:\OSGeo4W\bin\gdalbuildvrt.exe -resolution average -a_srs EPSG:25832 -r nearest -allow_projection_difference -srcnodata 255 -input_file_list Liste.txt VRT.vrt

Before that, i create a Liste.txt with all .tif files in a folder with:

if NOT "Rasterpath" == "\" (
    dir "Rasterpath"*.tif /b /s > "Rasterpath_converted/Liste.txt"
    
    REM Calculate total size of input files recursively
    for /r "Rasterpath" %%F in (*.tif) do (
        set /a "total_size+=%%~zF/1024/1024"
    )
    echo Total input size: !total_size! MB
)

[mdouchin]

Also seems weird to me that testing a version of a raster at a much lower resolution than the original didn't yielded much improvement. Common sense says that the issue in not in QGIS Server (or the way it was installed/deployed) but rather in LMWC or one of its underlying libraries.

Lizmap only pass the request to QGIS Server, get its response and send it back. If you do not use server cache (which I do not recommend), LWC does nothing more than checking rights (which in a normal context is fast). The only time Lizmap uses a library (GD) is when you activate server cache and metatiling (which must be done for very specific needs)

To really compare QGIS Server and Lizmap, and see if one is slower than the other, please have a look at the logs, get one of the Lizmap request passed to QGIS Server, and test the direct request to QGIS Server, with wget or curl in the command line. This is this only way to know and not guess.

I'm trying to gather some feedback here, trying to understand if is only a problem in my side or not.

I proposed a first answer above, please have a look.

Because if is not a local issue than I think we have a problem, raster rendering is very slow.

It could be a local issue, we have no user complaining about raster performances. We also have seen big COG of 30Gb rendered smoothly by LWC.

[Antoviscomi]

@Antoviscomi thanks for the reply. While I understand what you say, I'm not convinced. In both cases the requested image (in the same format and extent) is generated by the same QGIS server installation, on the same server. But for some reason in QGIS Desktop rendering is much faster. If you have a look at the short videos I posted you can see that there are no other layers involved. Also seems weird to me that testing a version of a raster at a much lower resolution than the original didn't yielded much improvement. Common sense says that the issue in not in QGIS Server (or the way it was installed/deployed) but rather in LMWC or one of its underlying libraries. I'm trying to gather some feedback here, trying to understand if is only a problem in my side or not. Because if is not a local issue than I think we have a problem, raster rendering is very slow.

@gioman i tried according to @mdouchin suggestion, to set the render in .webp instead of default .png , and the rendering in mine comes speed up (my raster have native resolution 30x30cm pixel and it is stored as postgis raster) considering a little network latency and a latency in postgresql responses, the rendering speeds are very similar between QGIS and LWC.

see below:

for QGIS

Video.del.03-09-2025.10.33.00.webm

for LWC

Video.del.03-09-2025.10.21.38.webm

[gioman]

thanks all for the feedback, it seems I have some work/tests to do on my side.