You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some sites I use a CDN to either accelerate page loads or provide DDoS-protection. At this moment, the CDN (either CloudFlare or CloudFront in my case) can also cache things like assets and images thanks to the Cache-Control headers that Zotonic sets on those things. This works quite well, in one case saving me about a TB of traffic per month, so thanks for that.
But, I'd like to go one step further and also allow the CDN to cache pages. Currently, this is essentially impossible because Zotonic treats every visitor as unique, and sends them cookies and sets up either a websocket or comet connection for them on every page, even if this doesn't seem to be necessary.
For a website that caters mostly to people who are logged-in and doing things, this is hard to avoid, so I don't think we should complicate matters here.
But, most of the websites I host aren't like that at all and are mostly geared towards anonymous visitors. One such anonymous visitor or the next asking for the same page are going to get the exact same result, so there is no reason for me to generate and send that page twice. They also aren't typically going to be getting a lot of notifications and such, making the websocket/comet connection rather a waste of resources.
So, I propose the following:
Zotonic should set a cookie only if there is a need to remember the visitor. For example, if the visitor logs in.
Zotonic should clear the cookie entirely when the visitor logs out, so that such a visitor is once again fully anonymous
Zotonic should only set up a websocket or comet connection if there is something on the page that requires it.
Zotonic should send a cache-control header with each anonymous page (i.e., one generated with no cookie from the client), instructing caches and browsers that the page may be cached for a certain amount of time.
Zotonic should send a cache-control: private header (like is already done) for pages generated with cookies
There should a way in the admin interface to set a page-specific TTL to override a default ttl so that pages that are updated frequently, are cleared from cache more frequently too
There should be a way to serve public assets (photos, attachments, css, js, etc.) from a separate domain so that even if the user is logged in, they don't send their cookie along with such requests.
Now, I'm not completely sure if the above is possible with respect to the websocket or comet connection; perhaps it is used for more than I thought or the cookie is needed to identify what page the visitor is on. Perhaps this is site-specific, and this functionality should be configurable as it would work for one site but not another.
Another thing to consider is that caches need to be able to differentiate between pages that have the same url but were generated for either a logged-in user or anonymously, so that the latter isn't sent the former's page. The former has cookies so this shouldn't be too difficult; but it may require also setting Vary headers or some such thing.
It seems to me that if it's possible to do so, then adding this functionality as a module with its own configuration would be the most logical way.
The text was updated successfully, but these errors were encountered:
For some sites I use a CDN to either accelerate page loads or provide DDoS-protection. At this moment, the CDN (either CloudFlare or CloudFront in my case) can also cache things like assets and images thanks to the Cache-Control headers that Zotonic sets on those things. This works quite well, in one case saving me about a TB of traffic per month, so thanks for that.
But, I'd like to go one step further and also allow the CDN to cache pages. Currently, this is essentially impossible because Zotonic treats every visitor as unique, and sends them cookies and sets up either a websocket or comet connection for them on every page, even if this doesn't seem to be necessary.
For a website that caters mostly to people who are logged-in and doing things, this is hard to avoid, so I don't think we should complicate matters here.
But, most of the websites I host aren't like that at all and are mostly geared towards anonymous visitors. One such anonymous visitor or the next asking for the same page are going to get the exact same result, so there is no reason for me to generate and send that page twice. They also aren't typically going to be getting a lot of notifications and such, making the websocket/comet connection rather a waste of resources.
So, I propose the following:
Now, I'm not completely sure if the above is possible with respect to the websocket or comet connection; perhaps it is used for more than I thought or the cookie is needed to identify what page the visitor is on. Perhaps this is site-specific, and this functionality should be configurable as it would work for one site but not another.
Another thing to consider is that caches need to be able to differentiate between pages that have the same url but were generated for either a logged-in user or anonymously, so that the latter isn't sent the former's page. The former has cookies so this shouldn't be too difficult; but it may require also setting Vary headers or some such thing.
It seems to me that if it's possible to do so, then adding this functionality as a module with its own configuration would be the most logical way.
The text was updated successfully, but these errors were encountered: