爲什麼要CSS和JS不通過Django？

按this answer到Can I gzip JavaScript and CSS files in Django?：爲什麼要CSS和JS不通過Django？

你的CSS和JS不應該通過Django的生產系統上會。你需要配置Apache（或Nginx，或其他）來提供這些，當你這樣做時，你將能夠在那裏設置gzip壓縮，而不是在Django。

該問題的答案沒有解釋此要求/建議的原因。從不同的服務器提供靜態內容（圖像/ CSS/JS）是否只是一種很好的速度練習？或者還有更多嗎？

來源

2011-05-26 super9

Apache和Nginx的速度比Django更快（因爲它們做的更少，更簡單）。因此，用Django提供CSS和JS是浪費資源。

雖然「應該」在這裏太強大了，IMO。「應該，如果你有高流量」，而是。

來源

2011-05-26 08:52:18

另外。 Web交易中最慢的部分是桌面。你想（慢）Django實例推動無盡的靜態內容流？或者你想限制（慢）Django實例推動重要的動態HTML頁面？ – 2011-05-26 11:11:43

不可否認，django.views.static中的[django靜態模塊]（https://docs.djangoproject.com/zh/dev/howto/static-files/）對於大多數服務來說已經足夠好了，而且如果你得到比他們能夠處理的流量更多，您的應用程序效率相當低，或者您將擁有處理單獨服務靜態文件的資源。 – sleepynate 2011-05-26 13:17:04

@sleepynate：「對於大多數服務都足夠好」。我們並沒有發現這種情況。我們發現讓Django做得非常非常少，並且儘可能讓Apache做更多的擴展。與Apache相比，Python速度較慢。 – 2011-05-26 13:35:15

Web服務器提供的內容可以大致分爲兩類。

靜態
動態

靜態文件（CSS/JS /圖...）通常不會改變（即它們可以從磁盤讀取和發送到客戶端。（推）

動態文件（動態HTML頁面之前無需預處理），通常需要以各種方式（DB數據+形式+處理的消息......要處理），發送給客戶端。

當一個事物沒有改變並且對任何用戶保持不變時，不要將該作業分配給web框架（它的額外負擔），讓web服務器處理它。

來源

2011-05-26 10:42:58

在生產環境中，你已經有它連接到Django的真正 HTTP服務器（通過mod_python的，FCGI或WSGI），所以它只是常識，直接從它提供文件服務。

它會發送響應速度快：

當你成爲通過正確配置Apache或nginx的開銷靜態文件將是最小的。根據請求，服務器檢查指定路徑中的文件是否存在，然後將其發送到瀏覽器（當然添加一些標題）。
當您通過Django的提供靜態文件配置背後Apache或nginx的首先Web服務器連接到Django的，那麼Django的處理事情的方式更加複雜：
- 創建請求對象，
- 運行urlpatterns的REGEXP匹配，直到找到負責線路對於靜態，
- 運行一些靜態服務代碼，將其發回給用戶...

這將消耗更少的資源：

每個Django的進程佔用內存很多，認爲這樣比成爲同一個靜態文件相同的方式配置Apache進程的10倍，

它會更好地縮放：

prope RLY nginx的配置可以處理100倍以上的要求消耗更少的CPU &內存...

可以外包：

雖然它是寫你需要配置Apache或nginx的你可能不 - 你可以將這些文件外包給諸如Amazon S3或Google API之類的服務，這樣js & css將與用戶「更接近」，並且在像Google API這樣的服務中，您希望添加的庫（如jQuery）已經被緩存在用戶瀏覽器中。

所有這些東西加在一起將簡單地使您的網站加載更快。

來源

2011-05-26 21:35:20 rombarcz

爲什麼要CSS和JS不通過Django？

回答

相關問題