The branding logo loader causes multiple 404 HTTP requests and visible delay on every page load

[olexii4]

Describe the bug

The branding logo loader causes multiple 404 HTTP requests and visible delay on every page load. Additionally, the favicon update is delayed because it depends on the full bootstrap process completing.

Problem 1: Logo Loading

Current Behavior

The brandingLoader.ts file implements a logo loading mechanism that:

1. Sequentially checks multiple image formats (jpg, jpeg, png, gif, webp, svg) using HEAD requests
2. Makes these requests on every page load without any caching
3. Results in multiple 404 responses for non-existent formats before finding the correct one
4. Causes a visible delay in logo display as requests are processed sequentially

Example Scenario

If the available logo format is loader.svg, the current implementation will:

1. Request loader.jpg → 404
2. Request loader.jpeg → 404
3. Request loader.png → 404
4. Request loader.gif → 404
5. Request loader.webp → 404
6. Request loader.svg → 200 ✓

This happens on every single page load.

Problem 2: Favicon Loading Delay

Current Behavior

The updateFavicon() method in bootstrap/index.ts:

1. Waits for fetchClusterConfig() to complete before updating favicon
2. Depends on the full Redux store being initialized
3. Runs as part of the bootstrap process, not during preload
4. Results in the default browser favicon showing until the API response is received

// Current implementation in bootstrap/index.ts
this.fetchClusterConfig().then(() => this.updateFavicon())

private updateFavicon() {
  const dashboardFavicon = selectDashboardFavicon(this.store.getState());
  if (dashboardFavicon?.base64data && dashboardFavicon?.mediatype) {
    const hrefAttribute = `data:${dashboardFavicon?.mediatype};base64,${dashboardFavicon?.base64data}`;
    // ... update DOM
  }
}

Impact

• User Experience: Users see default/placeholder favicon until cluster config loads
• Performance: Favicon update blocked by network request
• Inconsistency: Logo and favicon don't update together

Proposed Solution

1. Add Session Storage Caching

Add new keys to SessionStorageService:

export enum SessionStorageKey {
  BRANDING_LOGO_PATH = 'branding-logo-path',
  BRANDING_FAVICON = 'branding-favicon',
}

2. Move Favicon to Preload

Move updateFavicon logic to brandingLoader.ts so both logo and favicon:

• Load during the preload phase (before React bootstrap)
• Use cached values from session storage when available
• Fall back to API/format detection on first load

3. Caching Flow

First Load:

1. Detect correct logo format, cache path
2. Fetch favicon from cluster config API, cache base64 data
3. Update DOM with both

Subsequent Loads:

1. Read cached logo path → update immediately
2. Read cached favicon → update immediately
3. No 404 requests, no API delay

Che version

7.112@latest

Steps to reproduce

1. Deploy Eclipse Che to a cluster

2. Set custom loader image:

oc apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: dashboard-customization
  namespace: eclipse-che
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /public/dashboard/assets/branding
  labels:
    app.kubernetes.io/component: che-dashboard-secret
    app.kubernetes.io/part-of: che.eclipse.org
data:
  loader.jpg: <Base64_encoded_content_of_the_image> 
type: Opaque
EOF

3. Set custom favicon in CheCluster:

spec:
  components:
    dashboard:
      branding:
        dashboardFavicon:
          base64data: "<Base64_encoded_content>"
          mediatype: "image/png"

Reproduce Loader Issue

1. Open browser DevTools → Network tab
2. Navigate to Eclipse Che Dashboard or start a workspace
3. Observe HEAD requests for loader.jpg, loader.jpeg, loader.png, loader.gif, loader.webp before the correct format succeeds
4. Refresh the page
5. Same requests repeat - no caching between page loads
6. Note the visible delay before the loader image appears

Reproduce Favicon Issue

1. Clear browser cache
2. Navigate to Eclipse Che Dashboard
3. Observe the default browser favicon initially displayed
4. Wait for the page to fully load (~2-3 seconds)
5. Observe favicon updates only after cluster config API responds
6. Refresh the page - same delay repeats each time

Problem 1: Logo Loading

Current Behavior

The brandingLoader.ts file implements a logo loading mechanism that:

1. Sequentially checks multiple image formats (jpg, jpeg, png, gif, webp, svg) using HEAD requests
2. Makes these requests on every page load without any caching
3. Results in multiple 404 responses for non-existent formats before finding the correct one
4. Causes a visible delay in logo display as requests are processed sequentially

Example Scenario

If the available logo format is loader.svg, the current implementation will:

1. Request loader.jpg → 404
2. Request loader.jpeg → 404
3. Request loader.png → 404
4. Request loader.gif → 404
5. Request loader.webp → 404
6. Request loader.svg → 200 ✓

This happens on every single page load.

Problem 2: Favicon Loading Delay

Current Behavior

The updateFavicon() method in bootstrap/index.ts:

1. Waits for fetchClusterConfig() to complete before updating favicon
2. Depends on the full Redux store being initialized
3. Runs as part of the bootstrap process, not during preload
4. Results in the default browser favicon showing until the API response is received

// Current implementation in bootstrap/index.ts
this.fetchClusterConfig().then(() => this.updateFavicon())

private updateFavicon() {
  const dashboardFavicon = selectDashboardFavicon(this.store.getState());
  if (dashboardFavicon?.base64data && dashboardFavicon?.mediatype) {
    const hrefAttribute = `data:${dashboardFavicon?.mediatype};base64,${dashboardFavicon?.base64data}`;
    // ... update DOM
  }
}

Impact

• User Experience: Users see default/placeholder favicon until cluster config loads
• Performance: Favicon update blocked by network request
• Inconsistency: Logo and favicon don't update together

Expected behavior

After the first successful load, logo and favicon should appear immediately on subsequent page loads within the same session, without additional network requests or visible delay.

Runtime

OpenShift

Screenshots

No response

Installation method

chectl/next

Environment

macOS

Eclipse Che Logs

Additional context

No response