影響: 編寫上述帶有濃鬱上世紀風格的HTML程式碼可能導致標記複雜程度過高，進而在不同瀏覽器中出現彼此相異的運作效果。此外，我們也沒有任何理由在微軟Edge甚至是IE新版本（包括IE 9、10與11）當中使用此類複雜的標記方式。
元素處理內容佈局了，另外嚴格限制其在顯示表格資料時的使用頻率。充分了解目前有哪些標記選項可供使用，具體可以點擊此處查看whatwg.org中的總結。使用HTML程式碼來描述頁面內容，而非定義內容的顯示方式。若要正確顯示設計內容，請優先使用CSS。 2. 「在我的瀏覽器中明明沒有問題…」
錯誤: 開發人員可能會偏愛某款特定瀏覽器或極度鄙視另一款瀏覽器，而且會將這種帶有偏見的觀點帶入網頁測試工作當中。在某些情況下，我們甚至有可能將來自網路的範例程式碼直接納入專案當中，而並沒有測試其能夠在其它瀏覽器中正確得以渲染。再有，某些瀏覽器會在樣式方面有不同的預設值設定。
影響: 編寫一個只適用於特定瀏覽器的網站很可能會為使用其它瀏覽器的使用者帶來非常糟糕的存取體驗。
如何避免: 在開發過程中針對每一款瀏覽器及其版本進行網頁測試顯然是不現實的。不過我們可以每隔特定一段時間就利用多種瀏覽器來檢查自己的網站是否能夠正常運作，這算是種比較理想的折衷辦法。目前無論大家使用哪種首選開發平台，都有大量免費工具可以幫助各位實現測試工作，具體包括免費虛擬機器或網站掃描工具。 Browsershots或BrowserStack等網站也能提供快照，幫助我們了解特定頁面在不同瀏覽器/版本/平台上有怎樣的渲染效果。而Visual Studio等工具也能夠利用不同瀏覽器顯示我們目前正在開發的單一頁面。當利用CSS進行設計時，請記得對所有預設值進行「重新設定」。
如果大家的網站使用了任何面向單一瀏覽器所創建的特殊CSS功能，那麼請留心處理各類提供程序前綴，包括-webkit-、moz-或者-ms-。作為產業趨勢指南，我建議大家認真查閱以下提供的各參考網站（皆為英文原文）：
• 微軟Edge開發部落格: A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachach
• QuirksMode.org: CSS vendor prefixes considered harmful
• Bruce Lawson: On Internet Explorer supporting -webkit- vendor prefixes🀜？可點擊此處透過具體建議了解更多解決方法（英文原文）。
3. 注意調整格式
錯誤: 透過提示的方式向使用者索取資訊（特別是以輸入文字欄位的方式），並單純假設該資料能夠如預期般向使用者取得。
影響: 在預設信任使用者輸入資訊時，我們有可能面臨大量意料之外的麻煩。如果所要求的資料未能被正確取得，或所獲得的資料與底層資料格式不相容，那麼頁面很可能會發生錯誤。更嚴重的是，某些針對網站資料庫的故意違反行為甚至足以構成注入式攻擊。
如何避免:第一個建議就是要確保使用者能夠清楚地了解到網站要求其輸入哪種資料類型。就目前而言，單純給予「請輸入地址」的提示可能代表使用者需要輸入公司地址、家庭住址甚至是電子郵件地址！除了做出針對性說明之外，我們還應充分發揮現代HTML當中所提供的資料有效性驗證技術。無論資料在瀏覽器端是否被視為有效，我們務必在伺服器端同樣對其進行驗證。永遠不要在未確認欄位內容符合資料類型要求的情況下，允許使用者所輸入的多行索引T-SQL語句使用網站資料。
4. 反應速度太過緩慢
錯誤: 對於包含有大量高品質圖像以及/或圖片的頁面，我們應當利用![web開發人員最容易犯下的十種常見錯誤]()
元素對其高度及寬度屬性進行調整。而來自頁面中的CSS以及JavaScript等檔案連結往往也體積龐大。另外，來源HTML標記的存在經常會帶來不必要的複雜性與載入負擔。
影響: 如何某個頁面的完全渲染時間過長，那麼一部分用戶可能會放棄訪問甚至不耐煩地重新加載整個頁面。在某些情況下，如果頁面的處理時耗太長，甚至可能引發其它未知錯誤。
如何避免: 不要以為互聯網的傳輸速度越來越快就可以毫無顧忌地設計出臃腫的頁面成果。相反，將往返瀏覽器與站點之間的每一點流量視為營運成本。圖片可以說是頁面臃腫問題的罪魁禍首，因此為了最大限度降低圖片給頁面帶來的加載成本，請從以下三個角度進行考慮：
問問自己：「頁面中所包含的所有圖片都是必要的嗎？大家也可以點擊此處對自己的網站進行掃描，以獲得建議以了解哪些圖片可以進行壓縮。
利用Shrink O’Matic或RIOT這類工具來將自己的圖片尺寸控制在最低水平。
採取圖片預載方案。這雖然不會降低初始下載的具體成本，但卻能夠讓網站上其它使用相關圖片的頁面擁有更出色的載入速度。
另一種降低成本的方式則是壓縮CSS與JavaScript連結檔案的體積。目前我們可以選擇大量工具來幫助自己完成這項評估工作，其中包括Minify CSS以及Minify JS。
在結束第四點錯誤之前，我們還得提一句，請在HTML當中使用
5. 寫出「應該能夠起效」的程式碼
錯誤: 無論是JavaScript或是運行在伺服器端的程式碼，身為開發人員我們都應透過測試來驗證其實際運作效果，從而保證其一定能夠部署之後發揮預期作用。大家的程式碼在執行時不應引發任何錯誤，因為在此之前我們已經對其進行了充分測試。
影響: 包含未經測試程式碼的網站很可能以極其糟糕的方式在供最終用戶使用時產生各類錯誤。這不僅會嚴重影響使用者的實際感受，同時錯誤訊息內容的具體類型也可能會向打算入侵網站的駭客透露那些本應受到嚴格保護的細節線索。
如何避免: 人是不可避免會犯錯的，因此我們應當將這種哲學思維帶入程式工作。在JavaScript當中，我們應確保利用一切最佳技術手段來避免錯誤的發生，並在其實際出現後及時捕捉。另外一種有助於提高程式碼品質的方法就是針對未來可能出現的變更對程式碼進行單元測試。
伺服器端的程式碼錯誤必須要在使用者尚未察覺時即被發現並加以修復。只向使用者顯示必要的錯誤提示，而且請大家再用點心，把自己的HTTP 404錯誤頁面設計得漂亮一點。
6. 編寫fork程式碼
錯誤:出於支援所有瀏覽器及其各個版本的崇高理念，某些開發人員會創建不同的程式碼來對應每一種可能的運行場景。這些程式碼以if語句迴圈為基礎，並針對各類實際方向提供對應的fork版本。
影響: 隨著瀏覽器版本的不斷更新，對fork程式碼檔案的管理將變得非常複雜甚至無法實現。另外正如第一點所言，這樣做其實完全沒有必要。
如何避免: 在程式碼內部進行功能偵測，而非針對瀏覽器/版本著手。功能檢測技術方案的出現顯著降低了程式碼數量，也保證了程式碼更易於閱讀並管理。大家可以考慮利用Modernizr等函式庫來幫助自己在實現功能偵測的同時，以自動化方式為那些已經無法適應HTML 5或CSS 3的陳舊瀏覽器提供後備支援。
7. 採用非響應式設計
錯誤: 在進行網站開發工作時，假設使用者擁有與開發人員/設計師相等同的顯示器尺寸。
影響: 當在行動裝置或某些超大型螢幕上查看網站時，使用者體驗也會因此受到影響－例如無法檢視到頁面中的某些重要方面，甚至無法導覽至其它頁面。
如何避免: 將響應式設計納入開發考量。在站點當中使用響應式設計，甚至以同樣的方式進行圖片尺寸調節，在這方面Bootstrap這款高人氣庫絕對能夠幫上各位大忙。
8. 建立毫無意義的頁面
錯誤: 在面向公眾的頁面當中包含有實用性內容及信息，但不提供任何與搜尋引擎相關的關鍵字、標籤及提示。不提供無障礙存取功能。
影響: 在這種情況下，用戶將很難透過搜尋引擎找到我們的頁面，這將導致其難以甚至根本無法獲得理想的訪問量。另外頁面內容需要經過精心設計，以確保不會在使用者查看過程中操作其視力。
如何避免: 使用SEO（即搜尋引擎最佳化）機制並支援HTML存取性。在SEO方面，請確保新增標籤以提供包含關鍵字及相關描述的有意義頁面內容。要實現更出色的可訪問體驗，大家可以檢查每一條![web開發人員最容易犯下的十種常見錯誤]()
或標籤下的alt="your image description"屬性。當然，單純做到這些還遠遠不夠，大家可以點擊此處造訪了解頁面是否與Section 508相容。
9. 開發出的頁面中包含太多刷新操作
錯誤: 創建的站點在每項操作中包含太多頁面刷新步驟。
影響: 與臃腫頁面類似（見第四點），頁面載入時間這一重要效能指標也會因此受到影響。如果刷新過多，使用者體驗將缺乏流暢性，而每次內容更新都可能造成頁面的短暫（或長時）重置。
如何避免: 解決這一問題的便捷方式之一在於檢查各項操作是否真有必要與伺服器端取得聯繫。舉例來說，如果無需依賴伺服器端資源進行處理，那麼我們可以利用客戶端本身的腳本提供即時性結果。當然，大家也可以使用AJAX技術或更進一步，選擇單一頁面應用SPA方案。目前各類高人氣JavaScript函式庫/框架都提供眾多能簡化這方面難題的辦法，例如JQuery、KnockoutJS以及AngularJS。
10. 工作強度太大
錯誤: 開發人員可能會投入太多時間來創建Web內容。這些時間可能被用於進行重複勞動，或簡單地輸入大量文字內容。
影響: 在網站剛剛上線或進行後續更新時，開發人員投入其中的時間往往太過誇張。而當有其他開發者能夠用更短時間及更少精力達到同樣的效果時，我們投入的時間成本將得不到理想的回報。這種簡單重複的體力勞動會導致錯誤的出現，而診斷錯誤往往比開發專案更耗費時間。
如何避免: 自行尋找解決方法。我們可以考慮使用新型工具或新的工作流程技術來搞定開發中的每個階段。舉例來說，大家目前正在使用的程式碼編輯器與Sublime Text或Visual Studio相比孰優孰劣？無論大家所使用的是哪一款程式碼編輯器，您有沒有深入挖掘過其中的功能設定？也許只要花點時間認真閱讀說明文檔，我們就能找到足以在未來幫自己節約下數小時甚至更長的新用法。
另外不要錯過網路上任何可能幫得上忙的現成工具！舉例來說，在dev.modern.ie網站上搜尋那些能夠簡化測試（涵蓋多種平台及裝置）及故障排查工作的工具。
大家也可以透過自動化流程降低時間要求與出錯機率。例如，我們可以使用Grunt等工具來自動完成檔案體積壓縮等任務。另外，Bower則可以幫助大家更有效率地管理函式庫與框架。
那麼Web伺服器本身又存不存在最佳化空間？我們可以選擇微軟Azure Web Apps，並藉此快速創建出一個幾乎適用於任何開發場景的站點，這對於擴展業務絕對可算理想方案！
總結陳詞
透過列舉以上常見錯誤，Web開發人員能夠消除許多曾經坑害過無數前輩們的陷阱。除了意識到這些陷阱的存在，我們也了解了這些錯誤的影響以及解決辦法，並據此設計出一套開發流程，從而在適合自身習慣的同時培養工作信心。同志們，加油！
原文標題：10 Common Web Developer Mistakes
