Repository navigation
Slow performance, full page load LCP 500ms ish. #1596
Description
Your page performance is generally good, but there are opportunities to improve the Largest Contentful Paint (LCP) and initial load speed.
Performance Observations
Largest Contentful Paint (LCP): The LCP for the main navigation was 556 ms, with the LCP element being an icon image. The primary bottleneck is Resource Load Delay (126 ms) and Element Render Delay (127 ms).
Main Thread Efficiency: The main thread is frequently interrupted by third-party script execution, specifically from the Bitwarden Password Manager extension, which accounted for approximately 45 ms of activity during the initial load.
Network Protocol: The site is using HTTP/1.1. Modern protocols like HTTP/2 would allow for better multiplexing of resources, potentially reducing the time spent waiting for scripts and stylesheets to download.
Would you like to investigate how to optimize the LCP image delivery or how to reduce the impact of render-blocking resources?
Optimize LCP image discovery
To optimize LCP image discovery, focus on reducing the time between the start of navigation and when the browser begins downloading the LCP element.
Root Causes
Missing Fetch Priority: The LCP element (a PNG icon) does not use fetchpriority="high". This results in the browser assigning it a "Medium" priority, potentially delaying its download behind other resources.
Resource Load Delay: In NAVIGATION_2, there is a 126 ms delay between the document finishing its TTFB and the LCP image request being queued. This is often caused by the browser waiting for the preload scanner to find the URL or for main thread tasks to clear.
Protocol Overhead: The page uses HTTP/1.1 http://10.x.y.z:7990/img/heimdall-icon-small.png. This limits the number of concurrent requests the browser can handle, contributing to the queuing delay.
Suggestions
Add fetchpriority="high": Add this attribute directly to the tag for the LCP element. This signals the browser to prioritize this request over other non-critical assets.
Use a Modern Protocol: Upgrade the server to support HTTP/2 or HTTP/3. This allows for request multiplexing, which would eliminate the head-of-line blocking seen with HTTP/1.1 and reduce the 126 ms load delay.
Optimize Image Format: The LCP element is a PNG. Consider using WebP or AVIF, which would reduce the 137 ms load duration by lowering the file size.
Improve Caching: The LCP resource currently has no Cache-Control header (or it's not being utilized for repeat visits), leading to wasted time re-downloading the same icon on every navigation.
Can any setting affect this ? Or do we need to fix it somehow?
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
KodeStar commentedon Sep 5, 2026
There is no Heimdall setting that affects any of this. Taking the points in turn:
Cache-Controlheaders are set by whatever serves the files: the nginx inside the linuxserver container (configured in the docker-heimdall image, not this repo) or your reverse proxy if you have one in front. Enabling HTTP/2 and adding a longCache-Controlfor/css,/js,/imgand/storage/iconsat the proxy is the biggest win here and needs no change to Heimdall.fetchpriority="high"on the first tile icon and WebP/AVIF for user icons would be small changes in Heimdall itself. Neither is planned right now; leaving this open as the tracking issue for that.For a dashboard that is already painting in around half a second, the proxy-level caching is the part worth doing.
KodeStar commentedon Oct 3, 2026
One correction to my earlier comment: there was something in Heimdall itself costing time on every request. In the Docker image, a startup check looked for a file the image does not ship, so Heimdall ran
php artisan storage:linkon every page load. In a quick benchmark against the 2.8.3 image (CLI, no opcache) that added roughly 30 ms to each request (about 165 ms vs 138 ms). It will be less under php-fpm with opcache, but it is pure waste. The fix is in #1607 and will be in the next release.The proxy-level HTTP/2 and caching advice above still applies and is the bigger win for static assets.