Hi friends,

Overview: I live across the world from the discuss.tchncs.de server and have noticed when I “fresh load” (or browser reload, but not a shift-reload force) the banner image on the home page sidebar always re-downloading (it’s noticeable, takes 1-2 seconds). Once on the site, clicking “tchncs” top left to go back to the homepage does not trigger the re-download, fyi.

https://discuss.tchncs.de/pictrs/image/7285a9e0-5492-4461-8188-6778d7d594c7.jpeg

  • The image is only ~500kb (depending if you get the JPG or webp) and it 100% has proper cache-control headers being sent. It’s in 1920x1080 size and always gets down-sized into a smaller size to fit on the sidebar. There is nothing wrong with the server headers in the response.
  • Using the webdev console, I found is that Firefox does not seem to send If-modified-since headers in the request so the server has to always return a 200 instead of a 304 (use cached version). So it’s probably cached in my browser, by the browser isn’t sending the right type of request to trigger use of the cache on my side. Not sure if Lemmy code bug or Firefox bug not sending if-modified-since headers, not a webdev. :)

Suggestion: Since this image appears to only be used to always downscale on the browser side to fit in the sidebar (? I think?), we could probably pre-downscale it on the server side to half or 1/4 of it’s fileize. This would reduce network bandwidth for the server side and increase responsiveness on fresh load for users.

Thanks for reading.

  • straycatstrut@discuss.tchncs.deOP
    4·
    24 days ago

    Here’s the basic set of response headers showing the server is sending the proper cache-control directives on the image. The problem appears to be on the Firefox side using them properly.

    $ curl -I https://discuss.tchncs.de/pictrs/image/7285a9e0-5492-4461-8188-6778d7d594c7.jpeg

HTTP/2 200 
server: openresty
date: Tue, 02 Dec 2025 12:51:29 GMT
content-type: image/jpeg
access-control-expose-headers: content-type, accept-ranges, transfer-encoding, date, cache-control, last-modified
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
cache-control: max-age=31536000
last-modified: Mon, 30 Jun 2025 11:02:52 GMT
expires: Wed, 02 Dec 2026 12:51:29 GMT
cache-control: public
access-control-allow-origin: *
x-cache-status: HIT
    • straycatstrut@discuss.tchncs.deOP
      3·
      24 days ago

      Firefox webdev console request headers (minus my personal cookie), where I’m already on the page and just click the refresh button. No if-modified-since sent to the server to trigger a proper 304 response:

      GET /pictrs/image/7285a9e0-5492-4461-8188-6778d7d594c7.jpeg?format=webp HTTP/2
Host: discuss.tchncs.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: image/avif,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://discuss.tchncs.de/
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
Connection: keep-alive
DNT: 1
Sec-GPC: 1
Priority: u=5, i
TE: trailers
        • straycatstrut@discuss.tchncs.deOP
          1·
          24 days ago

          Sadly, no - I run an extension called “Don’t accept webp” causing that, I disabled it as soon as I saw the param to test and there’s no difference with or without the param. (webdev console request headers)