Typically you serve up that content separately from the static content. We use it where it doesn't cache for logged in users but is on a rolling cache otherwise. Page updates invalidate the cache immediately as well.
On a dynamic site with user content, you're going to be using some sort of object caching depending on your framework and language of choice, Varnish is great for news sites and things of that nature though.
You can also cache some content on a page, even for logged-in users, and add in the dynamic parts using ESI. For example an ecommerce site could have a category page cached, and have one section at the top that says "Hello, John Doe" generated dynamically and added in using ESI.
I'm not disagreeing.. but lots of people either dislike relying on JS, or would prefer to have the initial page load be a complete page.
If your AJAX is pulling down HTML fragments rather than JSON, then Varnish's ESI gives you the best of both worlds, allowing varnish the gather and assemble the initial page from the same endpoints your JS would hit.
Varnish is extremely configurable regarding that. Not only can you cache certain paths and leave others dynamic, but you can actually cache pages while leaving certain HTML elements on the page dynamic. E.g., let's say you have a mostly static page, but with the username on top ("you are logged in as brunoqc"). You can tell Varnish to cache the page and leave the HTML element containing the username dynamic.
No. This makes dynamic content static, by definition. However, you can exempt certain content from cache, exempt certain people from cache, exempt certain pieces of certain content from cache, or any combination. You can also invalidate cache when content changes (if you're able to do this absolutely, this is effectively dynamic), or set low TTLs to not have new content roll in on a certain time basis.
Comments
I don't know much about caching.
Does this work when serving dynamic content? I mean in a situation where your user absolutely need to see an up-to-date version of your data.
Typically you serve up that content separately from the static content. We use it where it doesn't cache for logged in users but is on a rolling cache otherwise. Page updates invalidate the cache immediately as well.
On a dynamic site with user content, you're going to be using some sort of object caching depending on your framework and language of choice, Varnish is great for news sites and things of that nature though.
You can also cache some content on a page, even for logged-in users, and add in the dynamic parts using ESI. For example an ecommerce site could have a category page cached, and have one section at the top that says "Hello, John Doe" generated dynamically and added in using ESI.
https://www.varnish-cache.org/trac/wiki/ESIfeatures
Or pull the dynamic parts in via ajax - I find that works quite well.
I'm not disagreeing.. but lots of people either dislike relying on JS, or would prefer to have the initial page load be a complete page.
If your AJAX is pulling down HTML fragments rather than JSON, then Varnish's ESI gives you the best of both worlds, allowing varnish the gather and assemble the initial page from the same endpoints your JS would hit.
Varnish is extremely configurable regarding that. Not only can you cache certain paths and leave others dynamic, but you can actually cache pages while leaving certain HTML elements on the page dynamic. E.g., let's say you have a mostly static page, but with the username on top ("you are logged in as brunoqc"). You can tell Varnish to cache the page and leave the HTML element containing the username dynamic.
No. This makes dynamic content static, by definition. However, you can exempt certain content from cache, exempt certain people from cache, exempt certain pieces of certain content from cache, or any combination. You can also invalidate cache when content changes (if you're able to do this absolutely, this is effectively dynamic), or set low TTLs to not have new content roll in on a certain time basis.