3 ms·
Most websites are more dynamic than they look. Anything with frequent updates (news for example), user accounts, any kind of personalization / geo-based content
by ricardobeat 7y ago
Most websites are more dynamic than they look. Anything with frequent updates (news for example), user accounts, any kind of personalization / geo-based content, or running A/B testing will demand dynamic rendering.
That's not an excuse for terrible performance either way. At this point it's trivial to handle hundreds (or thousands) of req/s on common hardware if you just choose the right software to run.
- tacon 7y agoThe JAMstack pitch is to sprinkle a bit of JavaScript on a mainly static site to achieve personalization, geo-based content, etc. A recent intro video shows exactly how to do that with news displayed based on browser language settings, etc.[0] It is a bit more complicated than a plain static site, but with recent tooling, not much more complicated. [0] https://www.youtube.com/watch?v=A_l0qrPUJds https://www.youtube.com/watch?v=A_l0qrPUJds
- deleted 7y ago[deleted]
- PKop 7y agoeven then it's only a question of how long can "stale" data be served, or is the dynamic-ness worth it? You can you lamba/cloud functions as webhooks for your CMS to ping when a rebuild of the static site is necessary. Netlify helps you set this up easily. Even if you updated a dozen times a day, it would take only a few minutes or less to rebuild and deploy. edit: yes per-user data is a primary use case for dynamically rendered sites. But public pages that all users load make sense as static if possible
- ricardobeat 7y agoNot dozens, think millions/billions of combinations for dynamic content. You cannot pre-render all the possibilities.