歷經多年的發展，Web仍停留在點選、換頁的浏覽方式。 AJax出現後，改寫了此種網頁必須不斷重新載入的互動模式，運用非同步技術，網頁只更新局部的內容，因此提供使用者更順暢、即時的互動模式。
少了「重新載入」的動作，Ajax呈現的是比傳統更酷炫效果，但是否該全面采用Ajax，企業除了看熱鬧外，更想了解「門道」。 AJax會不會拖慢效能？主要的學習門檻是什麼？搜尋引擎會不會因此找不到網頁內容，而影響了網站曝光度？其他RIA（Rich Internet Application）技術是否會取而代之？更重要的是，會不會引發資安的問題？
讓我們一網打盡所有關於Ajax的問題，幫助你打通任督二脈，快速了解AJax美麗與哀愁。
概念
Q1：采用AJax技術，除了酷炫效果之外，還有什麼好處？
答：所謂的「酷炫」應該是指可以隨意拖放網頁上的Widget、色彩漸層、元件的淡出／淡入、圖案變大／變小等效果，或者驚艷於Web Mail竟然可以提供類似Outlook的介面。
其實最直接而明顯的好處，是減少網頁重新載入的次數。
根據統計，購物網站每刷新一次網頁，就會有10%的消費者在等待的過程中「清醒」，發覺未必有購買的需要，而取消交易。當網頁不再因為少部分的資料被修改，就必須重新載入整個網頁，即可減少使用者等待的時間，提供更流暢的操控體驗。
無論是酷炫效果、精致的畫面，或者順暢的流程，對於網站的形象、商品銷售及使用者體驗都具加分的效果。
Q2：操控流暢對網站是有加分效果，但從企業的角度，關心的層面還包括Intranet的應用，Web應用程式適合加入AJax技術嗎？
答：在我們了解推推王、UrMap、Yahoo!及網擎Mail2000等的Ajax應用之後，發現Web應用程式還真的非常適合采用AJax技術。
注意力持續，有效提升生產力
應用程式的操作往往包含復雜的流程，然而Web化之後，流程變成了一連串網頁提交（Submit）的動作，每一次的更新網頁都需要數秒的等待，而且不能按「上一頁」退回前一個步驟。
在Web化的時代，企業最擔心的問題，並不是浪費了那幾秒等待載入網頁的時間，而是人在等待的空閒，很自然地會開啟另一個網頁，注意力就被導引到其他更有趣的資訊上，再次回神時，可能是半小時以後。
所以，對購物網站而言，注意力的持續是訂單的保證；對企業而言，則是生產力的提升。
延續桌面應用程式的操控體驗
不能按「上一頁」的操作模式，強烈地顯現出「應用程式」與「浏覽器」操作習性上的不同。當應用程式執行的環境搬到Web之後，使用者仍然期待保有桌面應用的操作體驗，透過AJax的非同步技術，即有機會消弭應用程式與浏覽器之間的鴻溝。
以Yahoo!郵件信箱與Mail 2000為例，在AJax化之後，使用者體驗的是與Outlook極其類似的操作方式。網擎資訊從用戶的回饋發現，由於操控方式的改變，使直覺與便利性向前躍進一大步，因此使用者滿意度明顯提升。
Q3：會不會拖慢Web伺服器效能？
答：可能是因為Ajax的酷炫效果，以及首次載入AJax網頁的時間比一般Html網頁長的原因，所以容易讓人誤以為采用AJax會拖慢伺服器效能。事實上，剛好相反！
AJax技術與傳統網頁與Web伺服器溝通方式各有不同。傳統的作法是用戶端送一個請求（Request）至Web伺服器，即使只需更動一個欄位的值，Web伺服器仍需重組一個完整的網頁，回應（Response）給用戶端，也因此浏覽器必須重新載入一次。
相較之下AJax技術使網頁具備程式能力，當使用者修改資料，觸發了Javascript程式，浏覽器便將使用者輸入的資料傳送至Web伺服器，Web伺服器會再把需要回傳的資料送至浏覽器，當JavaScript接收到資料之後，再把結果呈現在網頁上。
過程中完全沒有觸發提交動作，Web伺服器只回傳需要修改的內容，而且浏覽器也沒有重新載入的動作。這對伺服器負載、頻寬使用量及用戶端的操作體驗是三贏的局面。
根據UrMap改用AJax技術傳遞地圖資訊的經驗，在使用人數成長了10倍以上的情況下，伺服器的負擔相較於以往仍是減少，而頻寬使用量也沒有增加太多。
再以網擎資訊Mail 2000 4.5 Beta版改采AJax技術為例，觀察的結果發現，伺服器需要運算的資料量減少，頻寬成本也下降。以一頁的信件列表為例，過去100封郵件約需要傳送 120KB的資料量，現在則降為30KB。點選「新信檢查」功能，遞送的資料量約略是過去的1/5～1/4。
Q4：AutoComplete這類的AJax機制，頻繁地向伺服器要資料，應該會拖慢效能，是否有方法可解？
答：AutoComplete或內容自動更新等AJax機制，是使用者非常喜歡的功能。但人數眾多時，確實可能拖慢伺服器效能。
不過，此類問題可從設計上解決，例如設定快取機制、延長反應的時間、每填入3個英文字母才查詢一次，或者限制使用資料等，都是可能的解法。
帶領開發UrMap的友邁科技董事長卓政宏形容：「這是一種程式管理資源的方法。」他舉例：UrMap下載的地圖資訊，其實略多於網頁顯示的范圍， 使用者微幅地拖拉或縮放地圖時，其實叫用的是本機資料，並沒有對伺服器發出請求。所以，只要根據使用者的行為模式調整設計，就可以降低伺服器的負擔。
Q5：那麼AJax對用戶端的執行效能有何影響？
答：相對於傳統網頁，Ajax技術使得用戶端與伺服器傳遞的資料量變少，又避免了網頁重新載入的機會，AJax操作階段的效能的確是較佳的。
不過，首次登入網站時，下載的資料除了頁面呈現的內容外，還包含強化互動性的Javascript程式時，你可能會發現載入時間變長。針對用戶端的執行效能，Yahoo!國際資訊軟體工程師蔣定宇認為：「盡量縮短JavaScript程式碼，就可以將影響降到最低。」
Q6：企業如果要導入AJax，人才好不好找？
答：AJax包括JavaScript、DHtml、CSS、XMLHttpRequest、XML或JSON等，是眾多技術的集合，要了解這些技術，一定存在著門檻。
其實AJax主要是JavaScript的應用，但蔣定宇從面試Javascript工程師的經驗發現：「台灣比較重視ASP、Java和 PHP。」過去JavaScript是設計警告訊息或文數字檢查等輔助網頁輸入的稿本語言，所以開發者普遍認為Javascript、Html、CSS只 是網頁設計的輔助語言，所以好的JavaScript人才難尋。
網擎資訊研發經理張嘉淵提出類似觀點：「技術都不是問題，Javascript不難，但要寫得好，不容易。開發者必須用寫『核心』的心態開發JavaScript。」
Q7：那麼對於懂JavaScript的程式開發人員而言，AJax的門檻在哪裡？
從開發者的立場來看，推推王創辦人邱繼弘倒認為：「CSS和DOM是主要的門檻。」
AJax技術超出單純程式開發的范圍，開發者需要與設計人員合作，並了解網頁相關的CSS、DHtml、DOM等技術。即便成熟的工具相對降低學習的難度，但要學的東西變多了，同樣形成一種門檻。
Q8：這麼看來，網頁開發團隊的角色定位與合作方式，是否因為導入AJax而必須改變？
答：工作方式確實會受到沖擊。以Yahoo!為例，過去網頁設計分為VD（Visual Designer，視覺設計師）與RD（Research Developer，研發人員）兩種角色。 VD負責網頁設計，必須了解Html應用，RD則熟PHP、API、資料庫等技術，讓網頁串連後端程式與資料。
而今在VD與RD之間，多了一個WD（Web Developer，網頁開發人員），舉凡「檢視原始碼」可看到的內容，包括Html、CSS、JavaScript都是WD負責的范圍。
工作方式將產生明顯的變化，VD描繪出網頁應該有的樣子，WD則思考Html標簽的語義，使用正確的標簽做出正確的網頁結構，再搭配CSS給予外觀樣式。此外，最重要的工作就是運用JavaScript撰寫網頁的前端互動行為。
網頁設計流程到WD為止，仍是非真實的頁面，尚未連接後端真實的連結與資料。當網頁交給RD之後，RD人員負責套上真實的連結與資料。
這樣的開發流程並非台灣Yahoo!特有的設計，在美國Yahoo! ，他們稱WD為Front-end Engineer；而蕃薯籐稱為Web Master；趨勢科技則稱之為Prototyper。
工作形態的轉變是必然的趨勢。當前端網頁的設計，除了美工之外，還包含程式化機制，人員角色與開發流程都會隨之變化。即使在有限人力的情況下，必須 一人分飾兩角（通常是RD再身兼WD的工作），但設計（Designer）與開發（Developer）兩者的合作模式，仍不同於以往。
Q9：網頁包含CSS、Html，還有JavaScript程式，是否會不好維護？
答：根據Yahoo!的定義，網頁包括上述三種元素，Html定義結構、CSS設計樣式，而JavaScript控制行為。導入AJax將迫使網頁采用CSS，如此模組化的切分方式，反而是提高網頁的維護性。
不過，雖然維護AJax網頁並不困難，但相較於其他程式語言，即使JavaScript的開發工具已經逐漸成熟，除錯（Debug）方面的功能仍有 瓶頸。主要是因為各種浏覽器針對使用者的操作，所觸發的各種事件仍有差異，除非浏覽器走向標准化，否則開發工具要模擬各種浏覽器的行為仍有難度。
不過還是有一些選擇。就像IE浏覽器已經推出Internet Explorer Developer Toolbar，或者可以選擇IE Inspector推出的AxScripter等，而Firefox則提供Firefox Debugger。透過這些外掛套件的協助，已經逐漸降低除錯的難度。
Q10：既有的網站或Web應用程式，是否建議以AJax技術改寫嗎？
答：若是新興的網站或Web應用程式，尤其是產品化的Web應用程式或網站，采用Ajax技術幾乎可說是不得不的選擇，而且如果沒有提供AJax的效果，相形之下很容易失去競爭力。
然而，對既有的網站而言，「為技術而技術」是非理性的行為。卓政宏認為：「技術的進步總是會有幫助，但必須考量是否有投資的價值？企業應該思考AJax能做什麼？」
邱繼弘建議：「針對特定問題，運用AJax解決技術上的瓶頸就好。」許多功能往往是牽一發而動全身，稍加更動就必須全部改寫，全盤翻新的風險太高。
Ajax原本就是眾多技術的集合。對於初學者而言，AJax的門檻不低。即使只是微幅的修改，在測試與上線的過程中，仍有許多瑣碎的工作要面對，所以冒然采用未必是明智的決定。
Q11：AJax技術會不會有跨平台的限制？
答：若是問AJax能否跨作業系統平台，答案是Yes。
Q12：AJax技術跨浏覽器的問題該如何解決？
答：AJax在跨浏覽器遭遇的問題，在於浏覽器之間的行為差異，所以開發者需要測試JavaScript程式在各種浏覽器執行時的相容性，並針對差異的部分，撰寫不同版本的程式。
或者，最簡單的方式，就是套用YUI等Framework，透過平台解決相容性問題。
Q13：AJax開發的應用能否平順地在電腦、手機、PDA等不同裝置上順暢運行？
答：答案是No。隨想行動科技總經理馮彥文表示：「主要原因在於手機裝置對規格的支援不一，不論J2ME、Flash或AJax都會遇到相同的問題。」
再者，每款手機的螢幕大小都不同，況且一般網頁的資料量灌入手機螢幕會顯得冗長。若要講求美觀，都必須針對行動裝置提供特殊化的內容。例如國外知名的微型部落格網站Twitter，便針對手機平台設計特制的網站m.twitter.com。
Q14：聽說用AJax開發的網頁內容，搜尋引擎可能找不到，那不就會影響網站的能見度？
答：其實是設計上的問題。這關乎一個專有名詞稱為SEO（Search Engine Optimization，搜尋引擎最佳化）。關於SEO的顧慮，究其原理，搜尋引擎的機器人是根據網頁中的連結找到其他的網頁，再找到內容，所以網頁內 容必須使用固定網址（Permalinks），搜尋引擎才會找得到。
若是改由JavaScript動態產生內容，那麼將變成是由事件驅動（Event Driven），也就是使用者「開啟」網頁或「點選」連結才會產出內容，那麼搜尋引擎機器人便無法找到資料。
邱繼弘說：「這是網站設計的一種思維。希望增加曝光度，就要能夠被搜尋引擎找到。」推推王中關於AJax技術多半都用在視覺上，每筆資料都有獨立的網址，他們絕對不破壞「Content Unique」的原則。
Q15：什麼樣的應用不適合采用AJax？
答：以下幾種情況不建議使用AJax技術：
網頁需要變動的范圍比例很高
張嘉淵強調：「取決的關鍵點，就在於要搬多少資料到浏覽器。」AJax適合應用在局部、小量資料的修改，以減少網頁重新載入的機會，網頁中需要更新的比例很高，不如就重新載入吧！
排序
在ASP、JSP盛行之後，在網頁上利用DataGrid控制項建置動態查詢的報表是企業常見的應用。除了簡單的查詢功能，還可以任意地點選欄位變換排序的方式。此種應用便不適合采用AJax。
尤其是在資料筆數多的情況下，張嘉淵強調：「20筆和100筆資料的排序，對網頁效能的影響，絕對不只是5倍的差距。」對浏覽器而言，變更排序方式 就是整個DOM（Document Object Model，文件物件模型）的摧毀與重制，這類的應用反而是交給擅長資料處理的資料庫比較適合。
需要換頁的應用
Ajax訴求的就是實現不換頁的資料更新，所以網址列沒有變動，而這也就沒有「上一頁」、「下一頁」的記錄。因此有換頁需求，尤其使用者有可能按「上一頁」的應用，便不適合采用AJax。
Web應用程式之所以適合采用Ajax技術的原因，也在於應用程式沒有換頁的概念。因此，在開發AJax應用時，設計者也應在操作思維上，避開使用者會想按「上一頁」的可能性。
Q16：若講究高互動性，其他RIA技術例如微軟的Silverlight及Adobe的Flash，可以提供更即時互動的效果，為什麼選擇Ajax？ AJax會不會只是過渡性的技術？
答：這個問題必須分成以下兩個層面來回答：
Silverlight或Flash的門檻更高
習慣右腦思考的程式開發者，未必能兼擅需要以左腦設計的Flash或Silverlight。當我們詢問推推王的開發團隊這個問題時，相關人等全部搖頭晃 腦地表示不喜歡Flash。其中陳冠傑以過去嘗試使用Flash經驗表示：「Flash的效能比較差，程式化的行為必須寫在ActionScript 中。」
從微軟展示的Silverlight案例中，德國的女性購物網站OTTO、法國的法雅客購物網站，它們的圖像化、直覺式的流暢設計確實令人目炫神迷。
假如是沒有專業美工人才的網站，他們更難以面對Dreamweaver或Expression Blend，要接受以時間線（Timeline）結合圖層產生動感效果的概念，開發人員需跨過的門檻更高。
Flash、Silverlight與AJax可以並用
就微軟開發平台而言，企業若需要比Ajax更酷炫的視覺效果，可利用Expression Studio設計網頁、圖像及動畫等視覺元素，而邏輯運算的部分，則仍然是透過Visual Studio工具開發AJax應用，所以兩者並不沖突。
而Flash的應用，程式化采用的稿本語言是ActionScript，它的語法非常類似Javascript，但仍可能令開發者感到排斥。 Adobe現已提出解決的方案，為了強化Flash與Ajax的互動，Adobe推出Flex-AJax Bridge，讓JavaScript與ActionScript可以相互溝通，那麼AJax與Flash元件就可以並存。
安全性
Q17：使用AJax，是否讓網站曝露在更高的風險中？
答：所謂AJax，最狹義的說法是指非同步傳輸的溝通方式，也就是使用XMLHttpRequest這個浏覽器物件來處理用戶端與伺服 器端資料交換的過程。就通用說法而言，AJax進一步包含了使用Javascript操作CSS與DOM（文件物件模型），以呈現豐富的視覺效果。因此 AJax的技術早已存在，它就是JavaScript，而AJax只是一種應用的觀念。
JavaScript本身是用戶端的程式語言，是在網站使用者的電腦中執行，不像伺服器端的腳本程式，因此對網站本身造成威脅的機會極低。
有些人認為AJax程式能夠透過檢視程式碼的方式看到它的程式邏輯與變數使用方式，而增加對網站的攻擊面，不像伺服器端的程式，能隱藏程式語法。
事實上，一個安全的網站，原本就必須在前端資料傳遞到後端時，做好過濾與把關的工作，不要相信前端傳來的東西，這是一個網站開發人員必須牢記在心的 金科玉律。如果伺服器端程式在設計時能謹守本份，重視程式的安全規畫，那麼無論前端是由使用者輸入資料傳來的，或是由JavaScript程式傳遞而來， 都一樣安全。
反而是由伺服器端發展出來的AJax解決方案，例如DWR，能讓使用者能從前端程式使用後端Java語法，即可能有潛在的安全威脅。
Q18：使用XMLHttp Request進行非同步傳輸時，難道沒有潛在風險？
答：事實上，浏覽器在設計這個物件之初，就已經考量到安全性的問題，因而限制XMLHttpRequest請求的資源與呼叫的腳本程式，兩者必須在同一個 網域內，不能存取網域外的資源，借此降低風險。這可避免惡意程式任意抓取資料，或是上傳具危險性的程式給其他伺服器執行。
不過Web 2.0盛行的混搭（Mashup）方式，透過開放API進行資料交換，而這種方式的確就是繞過同一網域的限制，會產生一定的風險。設計這類API時，必須特別注意它的存取限制，以免讓駭客有機可趁。
Q19：AJax會向伺服器頻繁要求資訊，是否會對網站形成阻斷式攻擊（Denial of Service）的效應？
答：就AJax的設計模式而言，的確向伺服器發出要求的次數將會增加，往往一點異動，就會與網頁伺服器或資料庫互動，尤其互動效果越多，更是如此。
就拿Google搜尋時會采用自動完成的功能，列出可能的搜尋關鍵字，或是雅虎奇摩的字典查詢服務，也有相似設計，只要輸入文字，便會向伺服器要求待選字。
這個安全性問題應該就兩個層面來看。首先應用這類AJax語法時，原本就必須做好效能考量與測試，例如善用快取功能，記錄反覆查詢高的關鍵字，反而能降低伺服器的負擔。
其次，如果駭客打算使用DOS對一個網站發動攻擊時，事實上無論是不是采用Ajax都一樣，而且利用AJax發動DOS，不見得是有效率的作法。
Q20：如果AJax對伺服器端的危害有限，那麼對用戶端呢？
答：雖然采用AJax進行非同步傳輸時會受到本地端的限制，提供了一定的安全性，然而由於采用JavaScript，便會讓使用者遭到 跨站腳本攻擊（Cross-Site Scripting，XSS）的機會增加，而讓駭客可以趁機竊取使用者的帳號資訊或殖入惡意程式到使用者的電腦中。
過去使用者還可以透過關掉Javascript方式，以降低浏覽網站時的風險，不進入AJax網站關掉JavaScript，形同使用者拒絕進入該網站，因為基本功能都無法使用。
由這觀點來看，的確Ajax盛行，讓駭客更有機會透過XSS的手法侵害使用者，不過XSS之所以能成功，通常是網站本身已經存在資安防線上的漏洞， 例如沒有檢查使用者上傳的資料，或是應用程式、系統本身有漏洞，如果能做好這些資安防護，那麼即使采用再多的AJax功能，使用者一樣安全無虞。