프로덕션 환경의 정적 파일 현실

Letting Flask serve your assets is perfectly fine while you build locally. In production, though, it is the wrong tool for the job. 🏭

Sending a file through Python ties up a worker that should be running your views. Real web servers move bytes far more efficiently.

In production a server like Nginx handles /static directly. It reads files from disk and never bothers your Python app at all.

You point the web server's location for /static at your folder on disk. Requests for assets stop short of Flask entirely.

Dedicated servers add compression, range requests, and smart cache headers for free, all things Flask would have to do manually.

For global reach, push assets to a CDN. Copies live near your users, so files load fast no matter where they are. 🌍

Because you used url_for, switching to a CDN is mostly a config change. Set a static_url_path or host and links follow.

No reverse proxy yet? WhiteNoise wraps your app to serve static files with proper caching, a solid step up from raw Flask.

Through every option your templates stay the same. They keep calling url_for, and only the serving layer underneath changes.

The big idea is separation: let your app do dynamic work and let infrastructure handle plain files. Each does what it does best.

Decide your production static strategy before launch. Retrofitting a CDN or proxy under traffic is far harder than planning it up front.

In production, why hand static files to Nginx instead of Flask?

You saw why real deployments hand /static to Nginx, a CDN, or WhiteNoise, keeping Flask focused on dynamic work. Course complete! 🎉