Skip to content

Slow performance, full page load LCP 500ms ish. #1596

Closed as not planned
Closed as not planned

Description

@Ondjultomte

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?

Activity

  1. moved this to Non-Docker Issues in Issue & PR Trackeron Aug 31, 2026
  2. KodeStar commented on Sep 5, 2026

    @KodeStar
    Member

    There is no Heimdall setting that affects any of this. Taking the points in turn:

    • The Bitwarden extension time is browser-side and outside Heimdall.
    • HTTP/2 and Cache-Control headers 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 long Cache-Control for /css, /js, /img and /storage/icons at 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.

  3. KodeStar commented on Oct 3, 2026

    @KodeStar
    Member

    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:link on 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions