Cache mail messages

[hassanakbar4]

component_MailArchive: User Interface resolution_fixed type_defect | by mt@lowentropy.net

---

I'm currently browsing through emails on https://mailarchive.ietf.org/arch/browse/sframe/ It is taking 5-6 seconds to load each email as I click it. That's not great, but maybe that's just what it takes.

However, I note that there is no caching information attached to the response at all. So when I click on a message once, the next time I click on it, I see the same long delay again. That is unnecessary, wasteful, and it makes the overall experience much worse.

Adding Cache-Control: max-age=300 or similar to these responses would make a massive difference.

Based on what I'm seeing, with effectively immutable messages that have permanent identifiers, it might even be possible to use Cache-Control: immutable. That comes with risks, but a larger max-age would probably be safe enough.

---

Issue migrated from trac:3192 at 2021-09-22 16:57:59 +0500

[hassanakbar4]

@hassanakbar4 commented

---

In the meantime, if you need faster browsing, the static mode might help (see the settings menu).

[hassanakbar4]

@hassanakbar4 commented

---

Hi Martin,

Is this issue persistent for you? I ask because response times on the server end for these resources is typically well under 1 second. In order to address caching, are you referring to messages viewed in the double pane browse view, list above, message content below? Or messages in the full screen view, for example: https://mailarchive.ietf.org/arch/msg/sframe/k8oVzEzVwsUHMh64RQHll__zl24/. If you still experience long delays, is there any difference is delay between the two views described above?

Thanks, Ryan

[hassanakbar4]

@hassanakbar4 commented

---

Hi Ryan,

It doesn't seem to be very slow today, but the problem that was reported remains.

It is this view: [[Image(https://i.imgur.com/0QSy27C.png)]]

Note the network stats at the bottom, which show that the same resource was requested twice from the network and not the cache the second time.

Firefox reports these 600ms+ times as slow, but that was not my original concern at all. Though this is slow, I don't expect this to be super fast. However, I do expect the page to use very simple and easy-to-implement tricks (like caching) to minimize the effect of that slowness.

Adding Cache-Control is very easy and should make a huge improvement in perceived performance. If this is going via a CDN (which it appears to be), adding Cache-Control will not only make this a lot faster for me, it will make it a lot faster for everyone and reduce server load considerably. All for very little effort.

[hassanakbar4]

@hassanakbar4 commented

---

Hi Martin,

We do use Cache-Control to improve performance in other views and as you point out it looks like these resources could also benefit from it. I will work on getting this added. Thanks for your feedback to help make the site better.

Ryan

[hassanakbar4]

@hassanakbar4 changed status from new to accepted

[hassanakbar4]

@hassanakbar4 changed priority from n/a to major

[hassanakbar4]

@hassanakbar4 changed status from accepted to closed

[hassanakbar4]

@hassanakbar4 changed resolution from ` tofixed`

[hassanakbar4]

@hassanakbar4 commented

---

Added cache-control headers to message resources to allow caching.