A static asset can be built ahead of time and delivered as a file. A dynamic response is generated or changed when a request arrives. Many useful websites combine both approaches.
Images, styles, and public scripts often fit static delivery well. Content that depends on a hostname, a signed-in user, or current data may need request-time logic.
The boundary is a design choice. Keep frequently reused assets simple to deliver, and use dynamic work where it produces a meaningful difference for the visitor.
Picture this situation.
Imagine a publication whose articles can be prepared ahead of a visit. A separate search interaction can add usefulness without changing how the prose is delivered.
A second way to look.
Write down the responsibility before choosing a mechanism. A smaller, clearly owned part is often easier to explain than an elaborate arrangement with uncertain boundaries.
- Separate shared assets from request-specific content.
- Build ahead where the content permits it.
- Use runtime work for a clear requirement.
Follow a related question
Choose a representative sample.
How tools learn to work togetherInclude punctuation and varied text in a sample.
A CSV file has a dialectKeep learning
Related background to continue exploring this subject.
Cloudflare: serving static pages with Functions MDN: learn web development