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.
An example to consider.
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.
Put it in perspective.
Look at the information that outlives a single operation. Its owner, meaning, and recovery path deserve as much attention as the operation that created it.
- 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
Define the understood inputs.
Where automation should hand backInspect the source and measurement method.
An outlier is a question firstKeep learning
Related background to continue exploring this subject.
Cloudflare: serving static pages with Functions MDN: learn web development
