В достаточно малых масштабах это не имеет значения. Если ваша рабочая нагрузка составляет несколько десятков сотрудников, использующих внутренний веб-сервис, который не требует большого количества ресурсов на запрос, то сделайте все, что сможете быстро развернуть. это может означать передачу статического контента через обработчик в вашем веб-приложении на одном сервере.
Когда вы начинаете расширяться, вещи, которые раньше не имели значения, становятся заметными.
Первое, что становится заметно в приведенной выше конфигурации (статический контент обрабатывается веб-приложением), это то, что страницы загружаются намного дольше. Это потому, что только одна часть страницы на самом деле является динамической, сам HTML, но изображения, javascript, css и любые другие шансы и концы вашей страницы также следуют тому же жизненному циклу.
Одна вещь, которую вы можете сделать для улучшения ситуации, - это интеллектуально обслуживать статический контент в вашем обработчике, чтобы использовать преимущества кэшей и прокси-серверов, устанавливая заголовки Expires и ETag и возвращая 304 Not Modified, когда это необходимо.
Но это все, что статический веб-сервер уже делает. Кроме того, статический веб-сервер может быть значительно лучше оптимизирован для этой конкретной рабочей нагрузки. Когда вы действительно начинаете увеличивать масштабирование, перенося эту рабочую нагрузку на другой хост, чтобы сервер приложений даже не видел ее, - это один из самых простых способов извлечь больше производительности из вашего веб-приложения за очень небольшую цену.