在StackExchange上有人問了這樣一個問題：What should every programmer know about web development?（關於Web開發，什麼是所有程序員需要知道的？）裏面給出的答案非常不錯，所以，我翻譯轉載過來。 順便說一下，StackExchange真是非常好，大家可以對同一個答案做貢獻和修訂，看看這個問題的修訂過程你就知道了——專業的問答網站應該怎麼去做。這就是我在這篇文章中也說過真正的用戶體驗是什麼樣的。
好了，下面是正文（我對原文做了一些批註，也許不對或有誤導，請大家指正）
下面的這些東西可能對於大多數人並不陌生，但是可能會有些東西你以前並沒有看過，或是沒有完全搞懂，甚至都沒有聽說過。（陳皓注：我相信當你看完這個列表後，你會覺得對於我國的Web開發有點弱了，還是那句話，表面上的東西永遠是膚淺的）
接口和用戶體驗
小心瀏覽器的實現標準上的不一致，確信讓你的網站能夠適當地跨瀏覽器。至少，你的網站需要測試一下下面的瀏覽器：
最新的 Gecko 引擎 (Firefox)，
一個 Webkit 引擎 (Safari, Chrome, 或是其它的移動設備上的瀏覽器)
IE 瀏覽器 (測試IE的兼容性你可以使用微軟IE的 Application Compatibility VPC Images)
Opera 瀏覽器。
最後，你可以使用一下這個工具 來看看你的網頁在不同的瀏覽器下是怎麼被顯示出來的（陳皓注：這個工具就是以前本站介紹過的在不同瀏覽器和平臺上檢查你的網站的兼容性）
多考慮一下人們是怎麼來訪問你的網站而不是那些主流的瀏覽器：手機，讀屏軟件和搜索引擎，例如：一些Accessibility的東西： WAI 和 Section508, 移動設備開發：MobiForge.
部署Staging：怎麼部署網站的更新而不會影響用戶的訪問。 Ed Lucas的答案 可以讓你瞭解一些（陳皓注：Ed說了一些如版本控制，自動化build，備份，回滾等機制）。
千萬不要直接給用戶顯示不友好的錯誤信息。
千萬不要把用戶的郵件地址以明文顯示出來，這樣會被爬蟲爬走並被讓用戶的郵箱被垃圾郵件搞死。
爲用戶的鏈接加上 rel="nofollow" 的屬性以 避免垃圾網站的干擾。（陳皓注：nofollow是HTML的一個屬性，用於通知搜索引擎“這個鏈接所指向的網頁非我所能控制，對其內容不予置評”，或者簡單地說，該鏈接不是對目標網站或網頁的“投票”，這樣搜索引擎不會再訪問這個鏈接。這個是用來減少一些特定垃圾頁面對原網站的影響，從而可以改善搜索結果的質量，並且防止垃圾鏈接的蔓延。）
爲網站建立一些的限制 - 這個屬於安全性的範疇。（陳皓注：比如你在Google註冊郵箱時，你一口氣註冊超過兩個以上的郵箱，gmail要求給你發短信或是給你打電話認證，比如Discuz論壇的會限制你發貼或是搜索的間隔時間等等，更多的網站會用CAPTCHA來確認是人爲的操作。 這些限制都是爲了防止垃圾和惡意攻擊）
學習如何做 Progressive Enhancement. （陳皓注：Progressive Enhancement是一個Web Design的理念，如：1）基礎的內容和功能應該可以被所有的瀏覽器存取，2）頁面佈局的應該使用外部的CSS鏈接，3）Javascript也應該是外部鏈接還應該是 unobtrusive 的，4）應該讓用戶可以設置他們的偏好）
如果POST成功，要在POST方法後重定向網址，這樣可以阻止用戶通過刷新頁面重複提交。
嚴重關注Accessibility。因爲這是法律上的需求（陳皓注：Section 508是美國的508法案，其是美國勞工復健法的改進，它是一部聯邦法律，這個法律要求所有技術要考慮到殘障人士的應用，如果某個大衆信息傳播網站，如果某些用戶羣體（如殘疾人）瀏覽該網站獲取信息時，如果他們無法正常獲得所期望的信息（如無法正常瀏覽），那可以依據相關法規，可以對該網站依法起訴）。 WAI-ARIA 爲這方面的事提供很不錯的資源.
安全
在網上有很多關於安全的文章，但是 OWASP 開發指導 涵蓋了幾乎所有關於Web站點安全的東西。（陳皓注：OWASP(開放Web應用安全項目- Open Web Application Security Project)是一個開放的非營利性組織，目前全球有130個分會近萬名會員，其主要目標是研議協助解決Web軟體安全之標準、工具與技術文件，長期 致力於協助政府或企業瞭解並改善網頁應用程式與網頁服務的安全性。OWASP被視爲Web應用安全領域的權威參考。2009年下列發佈的美國國家和國際立法、標準、準則、委員會和行業實務守則參考引用了OWASP。美國聯邦貿易委員會(FTC)強烈建議所有企業需遵循OWASP十大WEB弱點防護守則）
瞭解什麼是 SQL 注入攻擊 並知道怎麼阻止這種攻擊。
永遠不要相信用戶的輸入（包括Cookies，因爲那也是用戶的輸入）
對用戶的口令進行Hash，並使用salt，以防止Rainbow 攻擊（陳皓注：Hash算法可用MD5或SHA1等，對口令使用salt的意思是，user 在設定密碼時，system 產生另外一個random string(salt)。在datbase 存的是與salt + passwd 產的md5sum 及salt。 當要驗證密碼時就把user 輸入的string 加上使用者的salt，產生md5sum 來比對。 理論上用salt 可以大幅度讓密碼更難破解，相同的密碼除非剛好salt 相同，最後存在database 上的內容是不一樣的。google一下md5+salt你可以看到很多文章。關於Rainbow 攻擊，其意思是很像密碼字典表，但不同的是，Rainbow Table存的是已經被Hash過的密碼了，而且其查找密碼的速度更快，這樣可以讓攻擊非常快）。使用慢一點的Hash算法來保存口令，如 bcrypt (被時間檢證過了) 或是 scrypt (更強，但是也更新一些) (1, 2)。你可以閱讀一下 How To Safely Store A Password（陳皓注：酷殼以前曾介紹過bcrypt這個算法，這裏，我更建議我們應該讓用戶輸入比較強的口令，比如Apple ID註冊的過程需要用戶輸入超過8位，需要有大小寫和數字的口令，或是做出類似於這樣的用戶體驗的東西）。
不要試圖自己去發明或創造一個自己的fancy的認證系統，你可能會忽略到一些不容易讓你查覺的東西而導致你的站點被hack了。（陳皓注：我在騰訊那坑爹的申訴系統中說過這個事了，我說過這句話——“真正的安全系統是協同整個社會的安全系統做出來的一道安全長城，而不是什麼都要自己搞”，當然，很遺憾不是所有的人都能看懂這個事，包括一些資深的人）
瞭解 處理信用卡的一些規則 . (這裏也有一個問題你可以查看一下) （陳皓注：有兩上vendor可以幫助你，一個是 Authorize.Net 另一個是 PayFlow Pro）
使用 SSL/HTTPS 來加密傳輸登錄頁面或是任可有敏感信息的頁面，比如信用卡號等。
知道如何對付session 劫持。（陳皓注：請參看wikipedia的這Session Hijacking，）
避免 跨站腳本攻擊(XSS)。（陳皓注：參看酷殼站前幾天發的《新浪微博的XSS攻擊事件》）
避免 跨站僞造請求攻擊 cross site request forgeries (XSRF).
保持你的系統裏的所有軟件更新到最新的patch。
確保你的數據庫連接是安全的。
確保你能瞭解最新的攻擊技術，以及你係統的脆弱處。
請讀一下 The Google Browser Security Handbook.
請讀一下 The Web Application Hacker’s Handbook.
（陳皓注：之前本站的“一些資源”提到過Mozilla的安全編程規範，還有Ruby on Rails的Web安全的開發教程）
性能
只要需要，請實現cache機制，瞭解併合理地使用 HTTP caching 以及 HTML5 Manifest.
優化頁面 —— 不要使用20KB圖片來平鋪網頁背景。（陳皓注：還有很多網頁頁面優化性的文章，你可以STFG – Search The Fucking Google一下。如果你要調試的話，你可以使用firebug或是chrome內置的開發人員的工具來查看網頁裝載的性能）
學習如何 gzip/deflate 網頁 (deflate 更好).
把多個CSS文件和Javascript文件合併成一個，這樣可以減少瀏覽器的網絡連數，並且使用gzip壓縮被反覆用到的文件。
學習一下 Yahoo Exceptional Performance 這個網站上的東西，上面有很多非常不錯的改善前端性能的指導，以及 YSlow 這個工具。 Google page speed 是另一個用來做性能採樣的工具。這兩個工具都需要安裝 Firebug 。
爲那些小的圖片使用 CSS Image Sprites，就像工具條一樣。 (參看 “最小化 HTTP 請求” ) （陳皓注：把所有的小圖片合併成一個圖片，然後用CSS把顯示其中的一塊，這樣，這些小圖片只用傳輸一次，酷殼的Wordpress樣式的那個RSS訂閱列表中的小圖標就是這樣做的）
繁忙的網絡應該考慮把網頁的內容分開存放在不同的域名下。（陳皓注：比如有專門的圖片服務器——圖片相當耗帶寬，或是專門的Ajax服務器）
靜態網頁 (如，圖片，CSS，JavaScript，以及一些不需要訪問cookies的網頁) 應該放在一個不使用cookies的獨立的域名下，因爲所有在同一個域名或子域名下的cookie會被這個域名下的請求一同發送。另一個好的選擇是使用 Content Delivery Network (CDN).
使用單個頁面的HTTP請求數最小化。
爲Javascript使用 Google Closure Compiler 或是 其它壓縮工具（陳皓注：壓縮Javascript代碼可以讓你的頁面減少網絡傳輸從而可以得到很快的喧染。注意，並不是所有的工具都可以正確壓縮Javascript的，Google的這個工具甚至還可以幫你優化你的代碼）
確認你的網站有一個 favicon.ico 文件放在網站的根下，如 /favicon.ico. 瀏覽器會自動請求這個文件，就算這個圖標文件沒有在你的網頁中明顯說明，瀏覽器也會請求。如果你沒有這個文件，就會出大量的404錯誤，這會消耗你的服務器帶寬。（陳皓注：服務器返回404頁面會比這個ico文件可能還大）
SEO (搜索引擎優化)
使用 “搜索引擎喜歡的” URL，如：使用 example.com/pages/45-article-title 而不是 example.com/index.php?page=45 (陳皓注：這裏的URL是說Wordpress的，後者是默認的)
如果你的動態頁面要使用 # ，那麼請把其改成 #! ，而在服務端，你需要處理$_REQUEST["_escaped_fragment_"] 這是Google搜索引擎需要的。換句話說，./#!page=1 會被Google搜索引擎轉成 ./?_escaped_fragments_=page=1。 （陳皓注：通常來說URL中的#後的東西都不會被傳到服務器上，所以，爲了要讓Google可以抓取AJAX的東西，你需要使用#!，而Google會把“#!”轉成“_escaped_fragment_”來向服務器發請求，Twitter的大量的鏈接者是#!的，比如：https://twitter.com/#!/your_activity）。另外，用戶也許會使用Firefox 或 Chromium， history.pushState({"foo":"bar"}, "About", "./?page=1"); 是一個很不錯的命令。所以，就算是我們的地址欄上的地址改變了，頁面也不會重新裝載。這可以讓你使用 ? 而不是 #! 也能無刷地保住當前的動態的頁面，這可以讓AJAX的請求被瀏覽器記住。
別使用 “click here” 這樣的鏈接。這樣一來，無法SEO，而且對於一些需要使用讀屏人來說很不友好（陳皓注：關於讀屏軟件，可參看本站的“如果看不見你還能編程嗎”）
做一個 XML sitemap，並放在網端的根下 /sitemap.xml. （陳皓注：這個文件可以讓搜索引擎瞭解你的網站圖）
當你有多個URL指向同一個網頁的使用，使用 <link rel="canonical" ... /> 你可以使用 Google Webmaster Tools 來查看相關的問題。
使用 Google Webmaster Tools 和 Yahoo Site Explorer.
安裝 Google Analytics (或是別的開源的網站分析工具，如： Piwik).
瞭解 robots.txt 和搜索引擎爬蟲是如何工作的。
重定向請求 (使用 301 重定向網站) ，如果你要把 www.example.com 定向到 example.com(或是其它的變更) 這樣可以防止Google的rank因爲域名的變化發生改變。（陳皓注：301重定向一般用作域名變更）
知道並不是所有的爬蟲都是好的，有些爬蟲的行爲並不好。（陳皓注：比如向你的網站發大量的請求導致服務器性能低下）
如果你有一些非文本的內容需要在 Google’s sitemap 中，比如視頻什麼的。Tim Farley的答案，可以讓你看到很多有價值的東西。
技術
理解什麼是 HTTP 比如 GET, POST, sessions, cookies等，瞭解什麼是 “stateless” 無狀態。
讓你的 XHTML/HTML 和 CSS 符合 W3C 規範，並確認他們都是 合格的。我們的目標是避免瀏覽器的 “quirks mode”，並且可以讓其更容易地能和非標準的瀏覽器工作，比如讀屏器或移動設備。
理解瀏覽器是怎麼處理 JavaScript 的。（陳皓：你會看到有些Javascript代碼在頁面上前面，有些則是在後面，所以你需要對其瞭解清楚爲什麼是這樣）
瞭解瀏覽器是怎麼裝載 JavaScript，CSS和其它資源的，瞭解其對視覺上的影響。（陳皓注：10年前我做網頁的時候因爲HTML還很弱，所以只能使用table來佈局，使用table佈局的問題就是整個table讀完後頁面纔會顯示，用戶的視覺體驗並不好）。在某些情況下，你可能需要把你的腳本放在頁面的後面。
理解 JavaScript 的 sandbox 是怎麼怎麼工作的，尤其是你想使用iframes。
請注意 JavaScript 可能會被禁止，這樣會讓你的AJAX失效。就算是大多數用戶都開啓了Javascript功能，但是也可能在一些情況下腳本是不被運行的，比如移動終端上，搜索引擎抓網頁的時候也並不會執行你的腳本。
學習 301 和 302 轉向的區別 (這也是一個SEO的問題).
儘可能多地學習你的部署平臺。（比如：操作系統，Web Server：Apache/Nginx，防火牆，數據庫，等等）
考慮使用一個 Reset Style Sheet.
考慮使用 JavaScript 框架(如： jQuery, MooTools, Prototype, Dojo 或 YUI 3)，它們會很好的兼容於不同的瀏覽器。（陳皓注：強烈推薦你看一下本站的開源中最好的WEB開發資源一文）
把視覺效果和JS框架合在一起討論，考慮使用一個Service，如：Google Libraries API 來裝載框架，這樣可以讓瀏覽器可能早就把這個JS框架已經cache了而不需要再從你的網站上下載了。
Bug fixing
明白你會花20%的時間寫代碼，而80%的時候在維護，所以你要小心編碼。（陳皓注：參看本站的“多些時間可以少些代碼”一文）
設計一個好的錯誤報告機制。
設計一個入口可以讓人們聯繫到你並給你建議和批評。
爲你開發的東西形成文檔，這樣可以讓後來的人容易維護你的軟件和系統。
頻繁備份（也可確保你的這些備份功能正常） Ed Lucas 的回答 有一些忠告。你還需要有一個恢復策略，而不只是一個備份策略。
使用一個版本控制系統來保存你的代碼，如： Subversion 或 Git.
別忘了做Acceptance Testing，使用 Selenium 能幫到你。
確保你有足夠的日誌，你可以使用 log4j, log4n 或 log4r。如果出了問題，這是可以讓你快速找到問題的方式。
當你寫日誌的時候，確保你記錄了你捕獲了處理和未處理異常。報告和分析日誌可以讓你知道你網站的問題。
這裏有多的東西被省略了，並不是因爲那些可能不是有幫助的答案，而是因爲那些東西都太細節了，超出了這個問題的範圍，因爲這本來就是一個Web開發需要了解東西的Overview。我想你可以去看一下其它人的答案，我有時間，我也會補充別人的答案進來。請隨意編輯這個答案，因爲可能有些東西忘了，也有可能有些東西不對。
好了，下面是正文（我對原文做了一些批註，也許不對或有誤導，請大家指正）
下面的這些東西可能對於大多數人並不陌生，但是可能會有些東西你以前並沒有看過，或是沒有完全搞懂，甚至都沒有聽說過。（陳皓注：我相信當你看完這個列表後，你會覺得對於我國的Web開發有點弱了，還是那句話，表面上的東西永遠是膚淺的）
接口和用戶體驗
小心瀏覽器的實現標準上的不一致，確信讓你的網站能夠適當地跨瀏覽器。至少，你的網站需要測試一下下面的瀏覽器：
最新的 Gecko 引擎 (Firefox)，
一個 Webkit 引擎 (Safari, Chrome, 或是其它的移動設備上的瀏覽器)
IE 瀏覽器 (測試IE的兼容性你可以使用微軟IE的 Application Compatibility VPC Images)
Opera 瀏覽器。
最後，你可以使用一下這個工具 來看看你的網頁在不同的瀏覽器下是怎麼被顯示出來的（陳皓注：這個工具就是以前本站介紹過的在不同瀏覽器和平臺上檢查你的網站的兼容性）
多考慮一下人們是怎麼來訪問你的網站而不是那些主流的瀏覽器：手機，讀屏軟件和搜索引擎，例如：一些Accessibility的東西： WAI 和 Section508, 移動設備開發：MobiForge.
部署Staging：怎麼部署網站的更新而不會影響用戶的訪問。 Ed Lucas的答案 可以讓你瞭解一些（陳皓注：Ed說了一些如版本控制，自動化build，備份，回滾等機制）。
千萬不要直接給用戶顯示不友好的錯誤信息。
千萬不要把用戶的郵件地址以明文顯示出來，這樣會被爬蟲爬走並被讓用戶的郵箱被垃圾郵件搞死。
爲用戶的鏈接加上 rel="nofollow" 的屬性以 避免垃圾網站的干擾。（陳皓注：nofollow是HTML的一個屬性，用於通知搜索引擎“這個鏈接所指向的網頁非我所能控制，對其內容不予置評”，或者簡單地說，該鏈接不是對目標網站或網頁的“投票”，這樣搜索引擎不會再訪問這個鏈接。這個是用來減少一些特定垃圾頁面對原網站的影響，從而可以改善搜索結果的質量，並且防止垃圾鏈接的蔓延。）
爲網站建立一些的限制 - 這個屬於安全性的範疇。（陳皓注：比如你在Google註冊郵箱時，你一口氣註冊超過兩個以上的郵箱，gmail要求給你發短信或是給你打電話認證，比如Discuz論壇的會限制你發貼或是搜索的間隔時間等等，更多的網站會用CAPTCHA來確認是人爲的操作。 這些限制都是爲了防止垃圾和惡意攻擊）
學習如何做 Progressive Enhancement. （陳皓注：Progressive Enhancement是一個Web Design的理念，如：1）基礎的內容和功能應該可以被所有的瀏覽器存取，2）頁面佈局的應該使用外部的CSS鏈接，3）Javascript也應該是外部鏈接還應該是 unobtrusive 的，4）應該讓用戶可以設置他們的偏好）
如果POST成功，要在POST方法後重定向網址，這樣可以阻止用戶通過刷新頁面重複提交。
嚴重關注Accessibility。因爲這是法律上的需求（陳皓注：Section 508是美國的508法案，其是美國勞工復健法的改進，它是一部聯邦法律，這個法律要求所有技術要考慮到殘障人士的應用，如果某個大衆信息傳播網站，如果某些用戶羣體（如殘疾人）瀏覽該網站獲取信息時，如果他們無法正常獲得所期望的信息（如無法正常瀏覽），那可以依據相關法規，可以對該網站依法起訴）。 WAI-ARIA 爲這方面的事提供很不錯的資源.
安全
在網上有很多關於安全的文章，但是 OWASP 開發指導 涵蓋了幾乎所有關於Web站點安全的東西。（陳皓注：OWASP(開放Web應用安全項目- Open Web Application Security Project)是一個開放的非營利性組織，目前全球有130個分會近萬名會員，其主要目標是研議協助解決Web軟體安全之標準、工具與技術文件，長期 致力於協助政府或企業瞭解並改善網頁應用程式與網頁服務的安全性。OWASP被視爲Web應用安全領域的權威參考。2009年下列發佈的美國國家和國際立法、標準、準則、委員會和行業實務守則參考引用了OWASP。美國聯邦貿易委員會(FTC)強烈建議所有企業需遵循OWASP十大WEB弱點防護守則）
瞭解什麼是 SQL 注入攻擊 並知道怎麼阻止這種攻擊。
永遠不要相信用戶的輸入（包括Cookies，因爲那也是用戶的輸入）
對用戶的口令進行Hash，並使用salt，以防止Rainbow 攻擊（陳皓注：Hash算法可用MD5或SHA1等，對口令使用salt的意思是，user 在設定密碼時，system 產生另外一個random string(salt)。在datbase 存的是與salt + passwd 產的md5sum 及salt。 當要驗證密碼時就把user 輸入的string 加上使用者的salt，產生md5sum 來比對。 理論上用salt 可以大幅度讓密碼更難破解，相同的密碼除非剛好salt 相同，最後存在database 上的內容是不一樣的。google一下md5+salt你可以看到很多文章。關於Rainbow 攻擊，其意思是很像密碼字典表，但不同的是，Rainbow Table存的是已經被Hash過的密碼了，而且其查找密碼的速度更快，這樣可以讓攻擊非常快）。使用慢一點的Hash算法來保存口令，如 bcrypt (被時間檢證過了) 或是 scrypt (更強，但是也更新一些) (1, 2)。你可以閱讀一下 How To Safely Store A Password（陳皓注：酷殼以前曾介紹過bcrypt這個算法，這裏，我更建議我們應該讓用戶輸入比較強的口令，比如Apple ID註冊的過程需要用戶輸入超過8位，需要有大小寫和數字的口令，或是做出類似於這樣的用戶體驗的東西）。
不要試圖自己去發明或創造一個自己的fancy的認證系統，你可能會忽略到一些不容易讓你查覺的東西而導致你的站點被hack了。（陳皓注：我在騰訊那坑爹的申訴系統中說過這個事了，我說過這句話——“真正的安全系統是協同整個社會的安全系統做出來的一道安全長城，而不是什麼都要自己搞”，當然，很遺憾不是所有的人都能看懂這個事，包括一些資深的人）
瞭解 處理信用卡的一些規則 . (這裏也有一個問題你可以查看一下) （陳皓注：有兩上vendor可以幫助你，一個是 Authorize.Net 另一個是 PayFlow Pro）
使用 SSL/HTTPS 來加密傳輸登錄頁面或是任可有敏感信息的頁面，比如信用卡號等。
知道如何對付session 劫持。（陳皓注：請參看wikipedia的這Session Hijacking，）
避免 跨站腳本攻擊(XSS)。（陳皓注：參看酷殼站前幾天發的《新浪微博的XSS攻擊事件》）
避免 跨站僞造請求攻擊 cross site request forgeries (XSRF).
保持你的系統裏的所有軟件更新到最新的patch。
確保你的數據庫連接是安全的。
確保你能瞭解最新的攻擊技術，以及你係統的脆弱處。
請讀一下 The Google Browser Security Handbook.
請讀一下 The Web Application Hacker’s Handbook.
（陳皓注：之前本站的“一些資源”提到過Mozilla的安全編程規範，還有Ruby on Rails的Web安全的開發教程）
性能
只要需要，請實現cache機制，瞭解併合理地使用 HTTP caching 以及 HTML5 Manifest.
優化頁面 —— 不要使用20KB圖片來平鋪網頁背景。（陳皓注：還有很多網頁頁面優化性的文章，你可以STFG – Search The Fucking Google一下。如果你要調試的話，你可以使用firebug或是chrome內置的開發人員的工具來查看網頁裝載的性能）
學習如何 gzip/deflate 網頁 (deflate 更好).
把多個CSS文件和Javascript文件合併成一個，這樣可以減少瀏覽器的網絡連數，並且使用gzip壓縮被反覆用到的文件。
學習一下 Yahoo Exceptional Performance 這個網站上的東西，上面有很多非常不錯的改善前端性能的指導，以及 YSlow 這個工具。 Google page speed 是另一個用來做性能採樣的工具。這兩個工具都需要安裝 Firebug 。
爲那些小的圖片使用 CSS Image Sprites，就像工具條一樣。 (參看 “最小化 HTTP 請求” ) （陳皓注：把所有的小圖片合併成一個圖片，然後用CSS把顯示其中的一塊，這樣，這些小圖片只用傳輸一次，酷殼的Wordpress樣式的那個RSS訂閱列表中的小圖標就是這樣做的）
繁忙的網絡應該考慮把網頁的內容分開存放在不同的域名下。（陳皓注：比如有專門的圖片服務器——圖片相當耗帶寬，或是專門的Ajax服務器）
靜態網頁 (如，圖片，CSS，JavaScript，以及一些不需要訪問cookies的網頁) 應該放在一個不使用cookies的獨立的域名下，因爲所有在同一個域名或子域名下的cookie會被這個域名下的請求一同發送。另一個好的選擇是使用 Content Delivery Network (CDN).
使用單個頁面的HTTP請求數最小化。
爲Javascript使用 Google Closure Compiler 或是 其它壓縮工具（陳皓注：壓縮Javascript代碼可以讓你的頁面減少網絡傳輸從而可以得到很快的喧染。注意，並不是所有的工具都可以正確壓縮Javascript的，Google的這個工具甚至還可以幫你優化你的代碼）
確認你的網站有一個 favicon.ico 文件放在網站的根下，如 /favicon.ico. 瀏覽器會自動請求這個文件，就算這個圖標文件沒有在你的網頁中明顯說明，瀏覽器也會請求。如果你沒有這個文件，就會出大量的404錯誤，這會消耗你的服務器帶寬。（陳皓注：服務器返回404頁面會比這個ico文件可能還大）
SEO (搜索引擎優化)
使用 “搜索引擎喜歡的” URL，如：使用 example.com/pages/45-article-title 而不是 example.com/index.php?page=45 (陳皓注：這裏的URL是說Wordpress的，後者是默認的)
如果你的動態頁面要使用 # ，那麼請把其改成 #! ，而在服務端，你需要處理$_REQUEST["_escaped_fragment_"] 這是Google搜索引擎需要的。換句話說，./#!page=1 會被Google搜索引擎轉成 ./?_escaped_fragments_=page=1。 （陳皓注：通常來說URL中的#後的東西都不會被傳到服務器上，所以，爲了要讓Google可以抓取AJAX的東西，你需要使用#!，而Google會把“#!”轉成“_escaped_fragment_”來向服務器發請求，Twitter的大量的鏈接者是#!的，比如：https://twitter.com/#!/your_activity）。另外，用戶也許會使用Firefox 或 Chromium， history.pushState({"foo":"bar"}, "About", "./?page=1"); 是一個很不錯的命令。所以，就算是我們的地址欄上的地址改變了，頁面也不會重新裝載。這可以讓你使用 ? 而不是 #! 也能無刷地保住當前的動態的頁面，這可以讓AJAX的請求被瀏覽器記住。
別使用 “click here” 這樣的鏈接。這樣一來，無法SEO，而且對於一些需要使用讀屏人來說很不友好（陳皓注：關於讀屏軟件，可參看本站的“如果看不見你還能編程嗎”）
做一個 XML sitemap，並放在網端的根下 /sitemap.xml. （陳皓注：這個文件可以讓搜索引擎瞭解你的網站圖）
當你有多個URL指向同一個網頁的使用，使用 <link rel="canonical" ... /> 你可以使用 Google Webmaster Tools 來查看相關的問題。
使用 Google Webmaster Tools 和 Yahoo Site Explorer.
安裝 Google Analytics (或是別的開源的網站分析工具，如： Piwik).
瞭解 robots.txt 和搜索引擎爬蟲是如何工作的。
重定向請求 (使用 301 重定向網站) ，如果你要把 www.example.com 定向到 example.com(或是其它的變更) 這樣可以防止Google的rank因爲域名的變化發生改變。（陳皓注：301重定向一般用作域名變更）
知道並不是所有的爬蟲都是好的，有些爬蟲的行爲並不好。（陳皓注：比如向你的網站發大量的請求導致服務器性能低下）
如果你有一些非文本的內容需要在 Google’s sitemap 中，比如視頻什麼的。Tim Farley的答案，可以讓你看到很多有價值的東西。
技術
理解什麼是 HTTP 比如 GET, POST, sessions, cookies等，瞭解什麼是 “stateless” 無狀態。
讓你的 XHTML/HTML 和 CSS 符合 W3C 規範，並確認他們都是 合格的。我們的目標是避免瀏覽器的 “quirks mode”，並且可以讓其更容易地能和非標準的瀏覽器工作，比如讀屏器或移動設備。
理解瀏覽器是怎麼處理 JavaScript 的。（陳皓：你會看到有些Javascript代碼在頁面上前面，有些則是在後面，所以你需要對其瞭解清楚爲什麼是這樣）
瞭解瀏覽器是怎麼裝載 JavaScript，CSS和其它資源的，瞭解其對視覺上的影響。（陳皓注：10年前我做網頁的時候因爲HTML還很弱，所以只能使用table來佈局，使用table佈局的問題就是整個table讀完後頁面纔會顯示，用戶的視覺體驗並不好）。在某些情況下，你可能需要把你的腳本放在頁面的後面。
理解 JavaScript 的 sandbox 是怎麼怎麼工作的，尤其是你想使用iframes。
請注意 JavaScript 可能會被禁止，這樣會讓你的AJAX失效。就算是大多數用戶都開啓了Javascript功能，但是也可能在一些情況下腳本是不被運行的，比如移動終端上，搜索引擎抓網頁的時候也並不會執行你的腳本。
學習 301 和 302 轉向的區別 (這也是一個SEO的問題).
儘可能多地學習你的部署平臺。（比如：操作系統，Web Server：Apache/Nginx，防火牆，數據庫，等等）
考慮使用一個 Reset Style Sheet.
考慮使用 JavaScript 框架(如： jQuery, MooTools, Prototype, Dojo 或 YUI 3)，它們會很好的兼容於不同的瀏覽器。（陳皓注：強烈推薦你看一下本站的開源中最好的WEB開發資源一文）
把視覺效果和JS框架合在一起討論，考慮使用一個Service，如：Google Libraries API 來裝載框架，這樣可以讓瀏覽器可能早就把這個JS框架已經cache了而不需要再從你的網站上下載了。
Bug fixing
明白你會花20%的時間寫代碼，而80%的時候在維護，所以你要小心編碼。（陳皓注：參看本站的“多些時間可以少些代碼”一文）
設計一個好的錯誤報告機制。
設計一個入口可以讓人們聯繫到你並給你建議和批評。
爲你開發的東西形成文檔，這樣可以讓後來的人容易維護你的軟件和系統。
頻繁備份（也可確保你的這些備份功能正常） Ed Lucas 的回答 有一些忠告。你還需要有一個恢復策略，而不只是一個備份策略。
使用一個版本控制系統來保存你的代碼，如： Subversion 或 Git.
別忘了做Acceptance Testing，使用 Selenium 能幫到你。
確保你有足夠的日誌，你可以使用 log4j, log4n 或 log4r。如果出了問題，這是可以讓你快速找到問題的方式。
當你寫日誌的時候，確保你記錄了你捕獲了處理和未處理異常。報告和分析日誌可以讓你知道你網站的問題。
這裏有多的東西被省略了，並不是因爲那些可能不是有幫助的答案，而是因爲那些東西都太細節了，超出了這個問題的範圍，因爲這本來就是一個Web開發需要了解東西的Overview。我想你可以去看一下其它人的答案，我有時間，我也會補充別人的答案進來。請隨意編輯這個答案，因爲可能有些東西忘了，也有可能有些東西不對。
