Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the frontend only serves uncompressed assets over HTTP #23535

Closed
3 of 4 tasks
unclehack opened this issue Jan 1, 2025 · 1 comment · Fixed by #23555
Closed
3 of 4 tasks

the frontend only serves uncompressed assets over HTTP #23535

unclehack opened this issue Jan 1, 2025 · 1 comment · Fixed by #23555
Assignees
Milestone

Comments

@unclehack
Copy link

unclehack commented Jan 1, 2025

Checklist

  • I have updated to the latest available Home Assistant version.
  • I have cleared the cache of my browser.
  • I have tried a different browser to see if it is related to my browser.
  • I have tried reproducing the issue in safe mode to rule out problems with unsupported custom resources.

Describe the issue you are experiencing

The encoding is set to "gzip, deflate" in Firefox when using Home Assistant via HTTP. This limited set of encodings over HTTP is mentioned on this page https://hacks.mozilla.org/2015/11/better-than-gzip-compression-with-brotli/. The 2024.12 Home Assistant official image only includes brotli compressed assets. This forces all browsers which don't support brotli to download uncompressed assets.

This can be fixed by enabling zopfli in https://github.com/home-assistant/frontend/blob/dev/build-scripts/gulp/compress.js. Manually compressing these in a custom container image works.

Describe the behavior you expected

The HA frontend was supposed to have gzip compressed assets. The browser was supposed to receive the compressible assets in gzip format. These were supposed to be present in the image as they are for brotli.

Home Assistant OS is very locked down. Adding such gzip compressed assets there involves the use of a custom frontend build or something else. Running just a custom HA core image with a few basic improvements would make sense.

Is the size of the image a concern? The compression task can run on the container's startup if that's the problem.

Steps to reproduce the issue

  1. download HA core 2024.12 or HAOS with HA 2024.12
  2. open the HA URL in Firefox over HTTP
  3. open the developer toolbar
  4. disable the cache
  5. reload the page
  6. observe that the .js files and other compressible assets are uncompressed
  7. build a custom HA core container image with gzip compressed js files
  8. run a container based on the new image
  9. observe how the browser now receives gzip compressed js files
    ...

What version of Home Assistant Core has the issue?

2024.12.5

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

No response

Which operating system are you using to run this browser?

No response

State of relevant entities

No response

Problem-relevant frontend configuration

No response

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

@unclehack
Copy link
Author

The Dockerfile below compresses all json and js files for the HA frontend. It does the same thing for the knx frontend.

FROM ghcr.io/home-assistant/home-assistant:stable
RUN cd /usr/local/lib/python3.13/site-packages/hass_frontend/; \
    find . -name '*.js' -exec gzip -9k '{}' \; ;\
    find . -name '*.json' -exec gzip -9k '{}' \; ;\
    cd /usr/local/lib/python3.13/site-packages/knx_frontend/; \
    find . -name '*.js' -exec gzip -9k '{}' \; ;\
    find . -name '*.json' -exec gzip -9k '{}' \;

All other bundled frontend packages provide gzip compressed files both for es5 and for their latest versions of the bundles. The KNX frontend and the HA frontend are the only two which provide only brotli compressed static assets for the latest version and gzip compressed ones for the es5 one.

An image built using this Dockerfile is able to serve the gzip compressed frontend assets from the frontend_latest directory over HTTP when the browser says it accepts 'gzip, deflate' as encoding.

@bramkragten bramkragten self-assigned this Jan 2, 2025
@bramkragten bramkragten added this to the 2025.1 milestone Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants