頁面加載上的AJAX不好嗎？

Question

我已經在書呆子晚餐和其他網站上看到了這一點。 在頁面加載時（通過瀏覽器在JavaScript中），AJAX請求將發出請求，以從呈現初始頁面的同一服務器中獲取一些數據。 數據將很小，並且沒有技術上的限制，否則會阻止它們僅從第一位提取數據。

這不是一件壞事嗎？ 這似乎是對AJAX調用的浪費，因為他們可以將數據與頁面的其余部分一起呈現為JavaScript。

我的銀行使用AJAX提取信息以構建“轉帳資金”表單的表單元素。 該信息只有幾千字節，那里的AJAX請求似乎有些過分。

在書呆子晚餐中，至少在我看到的MIX09視頻中，他們正在查詢（通過AJAX）一組晚餐，以在頁面加載時呈現在地圖控件上。

我可以理解，如果我們正在談論大量數據，否則將花費很長時間將其拉低，但是如果其長度在10至15kb之間，那么用標記拉低數據會更好嗎？ 他們是否這樣做是為了避免緩存數據？

編輯：我建議的是，與其打開服務器的AJAX調用以拉低客戶端onload上的json數據，不如讓asp.net（或其他任何東西）在呈現其他內容時在頁面內容中呈現json 。 我只是覺得有必要指出這一點，因為實際的客戶端代碼將完全相同，除了json變量的來源。

Answer 1

一般來說，以我的經驗來看，您希望避免頁面上的任何Javascript。 我的意思是，如果您可以在服務器端而不是Javascript上執行此操作，則應該這樣做。 您的頁面加載速度更快，您將獲得更好的用戶體驗。

有時這可能需要更多工作，特別是如果稍后在頁面中使用了相同的加載AJAX調用時。 您可能通過在服務器端進行復制來復制代碼。 因此，要在性能和要編寫的代碼量之間進行權衡。

另一個方面是，出於安全和網站安全的考慮，有時會針對機器人，抓取工具，惡意軟件（例如，密鑰竊賊等）防御性地使用Javascript。 例如，這可能意味着僅使用Javascript加載頁面元素，這是因為它使得更難破解或抓取。 在您中間並非沒有可能，只是更加困難。

Answer 2

返回鍵

如果用戶單擊后退/前進，服務器將不會再次被調用，因為它將內容從緩存中拉出了。 但是，通過客戶端頁面加載上的ajax調用，服務器將始終被調用。

Answer 3

我會寫初始頁面服務器端，以包括第一個可能的AJAX調用，然后再使用實際的AJAX進行后續操作。 您想在終端上做更多的工作以使最終用戶更快。

我看過一個使用AJAX作為主要內容的網站。 當該面承受載荷時，它將顯示導航欄，然后再過5秒鍾您將看不到任何東西，因為它通過AJAX調用加載，並且您失去了排隊的位置。 真煩人。

Answer 4

我在加載時使用AJAX主要是為了避免重復工作並使事情簡單-如果我仍然需要為更新進行客戶端渲染，最好對初始渲染使用相同的代碼。

用javascript生成的所有內容確實會對搜索等產生影響，但是只要您在設計頁面時意識到這一點，就不會有太大的問題。

Answer 5

通常，您是對的，如果您最初是從服務器提取頁面，為什么還要再進行一次旅行以獲取更多數據？ 但是，如果數據很大，那么您也可能需要加載頁面，以便最終用戶可以看到一些內容，然后提取數據。

數據可能會被Ajax明智地拉出，因為頁面上經常使用類似的數據檢索方法。 如果無論如何都要進行一些Ajax加載，為什么還要為初始加載編寫單獨的數據提取機制。

另外，請始終記住，演示只是演示。 與其他優先事項相比，書呆子晚餐的人可能更感興趣於展示如何將AJAX與MVC一起使用。

無論如何，好收獲。

Answer 6

這就是我可以看到此操作的原因：

進行AJAX調用以加載初始數據可以作為一種方式來驗證Javascript是否已打開以及后續的AJAX調用是否可以正常工作。 否則，將發生由客戶端使用JavaScript進行的對服務器的第一次調用不起作用的情況，並且如果用戶未意識到其安全性設置是其原因，則用戶可能會對此感到沮喪而感到沮喪。

Answer 7

我同意亞當。 如果您有一個復雜的大頁面，可能需要花費一段時間才能渲染服務器，但是其中只有少量動態內容，那么通過積極地緩存HTML並使用Ajax加載動態內容，您可以獲得巨大的性能優勢。

例如，假設一個網站的主頁應該在角落顯示用戶名。 每個訪問您網站的人都會訪問該頁面，因此您可以為HTML管理的緩存越多越好。 通過使用Ajax填充用戶名，您可以為所有人提供相同的可緩存HTML版本，並分別提供更小的動態內容。

如果您使用的不是非常快的服務器技術，那么可訪問性就變得更加重要-可能會使用Ruby on Rails。 通過使用Varnish或Squid之類的代理為頁面提供服務，可以很好地提高服務器端的速度，該代理可以保留所提供的每個頁面的緩存副本。 后續的對同一資源的請求將從代理的緩存而不是服務器代碼中獲取，直到緩存變舊為止。

Answer 8

我不知道請求/響應的大小在這里有什么意義。 是否使用AJAX只是可用性問題，這里的一個因素是渲染初始頁面的時間。 用戶不想等待。 如果只需要2秒鍾在服務器端計算頁面元素，則絕對應該考慮先發送不包含該元素的頁面，然后再通過ajax獲取該元素。 即使該頁面元素只有幾個字節。

Answer 9

頁面加載時的AJAX調用是為了保持表示與內容/數據的分離。

演示文稿（HTML頁面）可以由瀏覽器緩存，並且AJAX調用僅檢索數據以更新UI。

這可以導致非常干凈的分離以及一些性能優勢。 實際上，由於您沒有傳遞HTML標記湯，因此實際上通過網絡傳輸的信息較少-不管您使用的是哪種數據表示形式。

Answer 10

主要問題不是大小，而是額外的請求延遲/可用並行請求槽的阻塞。

Answer 11

針對頁面加載中的Ajax

• 使用服務器上的額外可用連接來處理AJAX請求。
• 在嘗試完成通話時可以讓頁面保持空閑狀態。
• 不可被搜索引擎索引。

對於頁面加載中的Ajax

• 方便。 將數據保留在頁面之外。
• 使數據更容易更改。
• 能夠實現Ajax響應的緩存。
• 創建許多“小部件”，每個小部件都處理自己的呼叫。

很多這些也僅取決於您的建築物所在的站點。 您要對較大的站點小心，不要在頁面加載時就依賴大量的少量Ajax調用。

Answer 12

最好的解決方案似乎是在服務器端調用Ajax函數，並將json內容加載到pageload上。 這樣可以使事情保持一致，並避免啟動時的額外連接。

Answer 13

做到這一點的最好理由是只有一個內容來源 ：現在，每個實例都來自Ajax，而不是將第一個實例嵌入頁面中，而是將更新的實例從Ajax引入。

換句話說：按照自己的方式做是雙重工作，由於錯誤，兩個版本的行為可能會有所不同。