優化某網頁的加載速度

js方法：
<script type="text/javascript"> 
window.onload=function(){ 
var userName="xiaoming"; 
alert(userName); 
} 
</script>
jquery方法：
<script type="text/javascript"> 
$(document).ready(function(){ 
var userName="xiaoming"; 
alert(userName); 
}); 
</script> 
或者簡寫：
$(function(){ 
var userName="xiaoming"; 
alert(userName); 
});
如何肯定一個js是否加載徹底或者頁面中的全部js加載徹底，具體辦法以下：

function loadScript（ url, callback） {
    var script = document.createElement("script");
    script.type = "text/javascript";
    if (script.readyState) {
        script.onreadystatechange = function() {
            if (script.readyState == "loaded" || script.readyState == "complete") {
                script.onreadystatechange = null;
                callback();
            }
        }
    } else {
        script.onload = function() {
            callback();
        }
    }
    script.src = url;
    document.getElementsByName("head")[0].appendChild(script);
}
如何讓腳本的執行順序按照你設定的順序執行，使用嵌套的方式：
loadScript("file1.js", function() {
    loadScript("file2.js", function() {
        loadScript("file3.js", function() {
            alert("All files are loaded");
        });
    });
});
網頁加載速度優化：
一、減小請求
最大的性能漏洞就是一個頁面須要發起幾十個網絡請求來獲取諸如樣式表、腳本或者圖片這樣的資源，這個在相對低帶寬和高延遲的移動設備鏈接上來講影響更嚴重。
CDNs（內容分發網絡）把資源放在離用戶地理位置更近的地方對解決這個問題能起到很大做用，可是比起獲取請求，大量的請求對頁面加載時間的影響更爲嚴重，並且最近的發現代表，CDNs對移動端用戶的性能影響愈來愈低。
二、整合資源
對開發者來講，將Javascript代碼和CSS樣式放到公共的文件中供多個頁面共享是一種標準的優化方法，這個方法能很簡單的維護代碼，而且提升客戶端緩存的使用效率。
在Javascript文件中，要確保在一個頁面中相同的腳本不會被加載屢次，當大團隊或者多個團隊合做開發的時候，這種冗餘的腳本就很容易出現，你可能會對它的發生頻率並不低感到很是吃驚。
Sprites是css中處理圖片的一項技術，Sprites就是將多張圖片整合到一個線性的網狀的大圖片中，頁面就能夠將這個大圖片一次性獲取回來而且作爲css的背景圖，而後使用css的背景定位屬性展現頁面須要的圖片部分，這種技術將多個請求整合成一個，能顯著地改善性能。
平穩地改進可是須要對資源有控制權限，根據開發者的網站不一樣權限，一些資源並不須要被整合起來（例如，一些由CMS生成的資源），還有，對於一些外部域引用的資源，強行整合可能會致使問題，馬海祥提醒你們須要注意的是，整合資源對手機瀏覽器來講是一把雙刃劍，整合資源確實會在首次訪問減小請求，可是大的資源文件可能會致使緩存失效，因此，須要當心地使用各類技術整合資源，以達到優化本地存儲的目的。
三、使用瀏覽器緩存和本地緩存
如今全部的瀏覽器都會使用本地資源去緩存住那些被Cache一Control或者Expires頭標記的資源，這些頭能標記資源須要緩存的時間，另外，ETag（實體標籤）和Last一Modified頭來標識當資源過時後是否須要從新請求，瀏覽器爲了減小沒必要要的服務器請求，儘量地從本地緩存中獲取資源，而且將那些已通過期的、或者當緩存空間減少的時候將那些好久不用的資源進行清理，瀏覽器緩存一般包括圖片，CSS，Javascript代碼，這些緩存能合理地提升網站的性能（好比爲了支持後退和前進的按鈕，使用一個單獨的緩存來保存整個渲染的頁面）。
移動瀏覽器緩存，一般是比桌面PC小的多，這就致使了緩存的數據會很常常被清理，HTML5的緩存基於瀏覽器緩存提供了一個很好的替換方案，Javascript的localStorage已經在全部主流的桌面和移動端瀏覽器上都實現了，使用腳本代碼能簡便地支持HTML5的localStorage操做，能夠讀寫鍵值數據，每一個域名大概有5MB的容量，雖然不一樣的移動瀏覽器上讀寫速度相差很大，可是localStorage大容量的緩存使得它很適合做爲客戶端的緩存，從localStorage獲取資源明顯快於從服務器上獲取資源，並且在大多數移動設備上也比依靠緩存頭或者瀏覽器的本地緩存更靈活可靠，這是移動瀏覽器比桌面PC更有優點的一個地方，在桌面PC上，本地緩存仍然優先使用標準的瀏覽器緩存，致使桌面PC本地緩存的性能落後於移動瀏覽器。
在此，馬海祥要提醒各位一下：雖然localStorage的機制易於實現，可是它的一些控制機制倒是很是複雜的，你須要考慮到緩存帶給你的全部問題，好比緩存失效（何時須要刪除緩存？），緩存丟失（當你但願數據在緩存中的時候它並不在怎麼辦？），還有當緩存滿的時候你怎麼辦？
四、首次使用的時候在HTML中嵌入資源
HTML的標準是使用連接來加載外部資源，這使得更容易在服務器上（或者在CDN上）操做更新這些資源，而不是在每一個頁面上修改更新這些資源，根據上文討論的，這種模式也使得瀏覽器能從本地緩存而不是服務器上獲取資源。
可是對尚未緩存到瀏覽器localStorage的資源來講，這種模式對網站的性能有負面的影響，通常來講，一個頁面須要幾十個單獨的請求來獲取資源從而渲染頁面。
因此說，從性能的角度來講，若是一個資源沒有很高的被緩存的概率的話，最好把它嵌入到頁面的HTML中（叫inlining），而不是使用連接外部，腳本和樣式是支持內嵌到HTML中的，可是圖片和其餘的二進制資源其實也是能夠經過內嵌包含base64編碼的文原本嵌入到HTML中的。
內嵌的缺點是頁面的大小會變得很是大，因此對於Web應用來講，關鍵的是可以跟蹤分析這個資源何時須要從服務端獲取，何時已經緩存到客戶端了。
另外，在第一次請求資源後必須可以使用代碼在客戶端緩存資源，所以，在移動設備上，使用HTML5 localStorage能很好地作到內嵌。
因爲不知道用戶是否已經訪問過這個頁面了，因此須要網站有機制能生成不一樣版本的頁面。
五、使用HTML5服務端發送事件
Web應用已經使用了各類從服務器上輪詢資源的方法來持續地更新頁面，HTML5的EventSource對象和Server一Sent事件能經過瀏覽器端的JavaScript代碼打開一個服務端鏈接客戶端的單向通道，服務端可使用這個寫通道來發送數據，這樣能節省了HTTP建立多個輪詢請求的消耗。
這種方式比HTML的WebSocket更高效，WebSocket的使用場景是，當有許多客戶端和服務端的交互的時候（好比消息或者遊戲），在全雙工鏈接上創建一個雙向通道。
這個技術是基於具體的技術實現的，若是你的網站當前是使用其餘的Ajax或者Comet技術來輪詢的，轉變成Server一Sent事件須要重構網站的Javascript代碼。
六、消除重定向
當用戶在一個移動設備上訪問桌面PC網站的時候，Web網站應用一般讀取HTTP的user一agent頭來判斷這個用戶是不是來自移動設備的，而後應用會發送帶有空HTTP body和重定向HTTP地址頭的HTTP 301（或者302）請求，把用戶重定向到網站的移動版本上去，可是這個額外的客戶端和服務端的交互一般在移動網絡上會消耗幾百毫秒，所以，在原先的請求上傳遞移動的web頁會比傳遞一個重定向的信息並讓客戶端再請求移動頁面更快。
對於那些想要在移動設備上看桌面PC網站的用戶來講，你能夠在移動web頁面上提供一個連接入口，這樣也能同時表示你的網站是並不提倡這種行爲的。
雖然這個技術在理論上是簡單的，可是實際上並不易於實施，因爲有些m.sites是宿主在其餘地方的，因此許多網站會選擇重定向到一個不一樣的服務器上，有的網站則是會在重定向請求的時候種植上Cookie告訴Web應用這個用戶是在使用移動設備，這種方法可能對web應用來講更容易控制。
七、減小資源負載
關於移動端頁面的大小問題，渲染小頁面更快，獲取小資源也更快，減少每一個請求的大小一般不如減小頁面請求個數那麼顯著地提升性能。
可是有些技術在性能方面，特別是在須要對帶寬和處理器性能精打細算的移動設備環境下，仍然是能帶來很大利益的。
八、壓縮文本和圖像
諸如gzip這樣的壓縮技術，依靠增長服務端壓縮和瀏覽器解壓的步驟，來減小資源的負載，可是，通常來講，這些操做都是被高度優化過了，並且測試代表，壓縮對網站仍是起到優化性能的做用的，那些基於文本的響應，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS能夠減小大約70%的大小。
瀏覽器在Accept一Encoding請求頭中申明它的解壓縮技術，而且當它們接收到服務端返回的Content一Encoding響應頭標示的時候，就會按照這個響應頭自動作解壓操做。
馬海祥以爲這種方法的優勢就是易於實現，若是設置正確的話，如今全部的Web服務器都支持壓縮響應，可是，也有一些桌面PC的安全工具會將請求頭中的Accept一Encoding頭去掉，這樣即便瀏覽器支持解壓縮，用戶也沒法獲取到壓縮後的響應。
九、代碼簡化
簡化一般是使用在腳本和樣式文件中，刪除一些沒必要要的字符，好比空格，換行符，或者註釋等，不須要暴露給外部的命名就能夠被縮短爲一個或者兩個字符，好比變量名，合適的簡化資源一般在客戶端不須要作任何其餘的處理，而且平均減小20%的資源大小，內嵌在HTML中的腳本和樣式文件也是能夠精簡的，有不少很好的庫來作精簡化的操做，這些庫通常也同時會提供合併多個文件這樣減小請求數的服務（具體可查看馬海祥博客《手機網站製做的經常使用方法及優化技巧》的相關介紹）。
簡化帶來的好處並不侷限於減小帶寬和延遲，對於那些移動設備上緩存沒法保存的過大資源來講，也是頗有改善的，Gzip在這個方面並無任何幫助，由於資源是在被解壓後才被緩存起來的。
Google的Closure Compiler已經難以置信地完成了理解和簡化Javascript的工做，可是CSS的簡化則沒有那麼容易，由於對不一樣瀏覽器來講有不一樣的CSS技術能迷惑CSS簡化工具，而後讓CSS簡化後沒法正常工做，馬海祥提醒你們必需要注意的是，已經有這樣的案例了，即便只是刪除了沒必要要的字符，簡化工做也有可能破壞頁面，因此當你應用簡化技術以後，請作一下完整的功能測試工做。
十、調整圖片大小
圖片一般是佔用了Web頁面加載的大部分網絡資源，也佔用了頁面緩存的主要空間，小屏幕的移動設備提供了經過調整圖片大小來加速傳輸和渲染圖片資源的機會，若是用戶只是在小的移動瀏覽器窗口中看圖片的話，高分辨率的圖片就會浪費帶寬、處理時間和緩存空間。
爲了加速頁面渲染速度和減小帶寬及內存消耗，能夠動態地調整圖片大小或者將圖片替換爲移動設備專用的更小的版本，不要依靠瀏覽器來將高分辨率的圖片轉換成小尺寸的圖片，這樣會浪費帶寬。
另一個方法是先儘快加載一個低分辨率的圖片來渲染頁面，在onload或者用戶已經開始和頁面交互之後將這些低分辨率的圖片替換成爲高分辨率的圖片。
特別應用在高度動態化的網站是有優點的。
十一、使用HTML5和CSS 3.0來簡化頁面
HTML5包括了一些新的結構元素，例如header，nav，article和footer，使用這些語義化的元素比傳統的使用div和span標籤能使得頁面更簡單和更容易解析，一個簡單的頁面更小加載更快，而且簡單的DOM（Document Object Model）表明着更快的JavaScript執行效率，新的標籤能很快地應用在包括移動端的新瀏覽器版本上，而且HTML5設計讓那些不支持它的瀏覽器能平穩過渡使用新標籤。
HTML5的一些表單元素提供了許多新屬性來完成本來須要javascript來完成的功能，例如，新的placeholder屬性用於顯示在用戶輸入進入輸入框以前顯示的介紹性文字，autofocus屬性用於標示哪一個輸入框應當被自動定位。
也有一些新的輸入框元素能不用依靠Javascript就能夠完成一些通用的需求，這些新的輸入框類型包括像e一mail，URL，數字，範圍，日期和時間這樣須要複雜的用戶交互和輸入驗證的元素，在移動瀏覽器上，當須要輸入文本的時候，彈出的鍵盤一般是由特定的輸入框類型來作選擇的，不支持指定的輸入類型的瀏覽器就會只顯示一個文本框。
另外，只要瀏覽器支持內建的層次，圓角，陰影，動畫，過渡和其餘的圖片效果，CSS 3.0就能幫助你建立輕便簡易的頁面了，而這些圖片效果原先是須要加載圖片才能完成的，這樣，這些新特性就能加速頁面渲染了。
人工地作這些改動是很是複雜和耗時的，若是你使用CMS，它能夠幫你生成許多你不須要控制的HTML和CSS（具體可查看馬海祥博客《製做移動端手機網站過程當中的SEO優化方法技巧》的相關介紹）。
十二、延遲渲染」BELOW一THE一FOLD」內容
能夠肯定的是若是咱們將不可見區域的內容延遲加載，那麼頁面就會更快地展示在用戶面前，這個區域叫作「below the fold」，爲了減小頁面加載後須要從新訪問的內容，能夠將圖片替換爲正確的高寬所標記的<img>標籤。
一些好的Javascript庫能夠用來處理這些below一the一fold 延遲加載的圖像。
1三、延遲讀取和執行的腳本
在一些移動設備上，解析Javascript代碼的速度能達到100毫秒每千字節，許多腳本的庫直到頁面被渲染之後都是不須要的加載的，下載和解析這些腳本能夠很安全地被推遲到onload事件以後來作。
例如，一些須要用戶交互的行爲，好比託和拽，都不大可能在用戶看到頁面以前被調用，相同的邏輯也能夠應用在腳本執行上面，儘可能將腳本的執行延遲到onload事件以後，而不是在初始化頁面中重要的可被用戶看到的內容的時候執行。
這些延遲的腳本多是你本身寫的，更重要的是，也有多是第三方的，對廣告、社交媒體部件、或者分析的差勁的腳本優化會致使阻塞頁面的渲染，會增長珍貴的加載時間，固然，你須要當心地評估諸如jquery這樣爲移動網站設計的大型腳本框架，特別當你僅僅只是使用這些框架中的一些對象的時候更要當心評估。
許多第三方的框架如今提供延遲加載的異步版本的API，開發者只須要將原先的邏輯轉化到這個異步版本，一些JavaScript要作延遲加載會有些複雜，由於在onload以後執行這些腳本須要注意不少注意事項（例如，你有個腳本須要綁定到onload事件上，你須要作什麼？若是你將腳本延遲到onload事件以後，就必定就會失去不少執行的時機）。
1四、使用Ajax來加強進程
Ajax（Asynchronous JavaScript and XML）是一項使用XHR（XMLHttpRequest）對象來從Web服務器上獲取數據的技術，它並不須要更新正在運行的頁面，Ajax能更新頁面上的某個部分而不須要從新構建整個頁面，它一般用來提交用戶的交互相應，可是也能夠用來先加載頁面的框架部分，而後當用戶準備好瀏覽網頁的時候再填充詳細的內容。
儘管是這個名字，可是XMLHttpRequest並不強制要求你只能使用XML，你能夠經過調用overrideMineType方法來制定「application/json」類型來使用json替換XML，使用JSON.parse會比使用原生的eval()函數快了幾乎兩倍，而且更爲安全。
同時，切記Ajax的返回響應也會得益於那些應用在普通的返回響應的優化技術上面，確保對你的Ajax返回響應使用了緩存頭，簡化，gzip壓縮，資源合併等技術。
因爲這個技術是根據具體應用不一樣而不一樣的，因此很難量化，或許因爲跨域問題，你須要使用XHR2，這個技術能使用外部域的資源，從而能進行跨域的XHR請求。
1五、根據網絡情況進行適配處理
因爲使用更多帶寬會使用更多移動網絡的費用，因此只有能檢測網絡的類型才能使用針對特定網絡的優化技術。
例如，預加載將來使用到的請求是很是聰明的作法，可是若是用戶的帶寬很稀有，而且加載的有些資源是永遠不會用到的話，這個技術就是不合理的了。
在Android 2.2+，navigator.connection.type屬性的返回值能讓你區分Wifi和2G/3G/4G網絡，在Blackberry上，blackberry.network也能提供類似的信息，另外，服務端經過檢測請求中的User一Agent頭或者其餘的嵌入到請求中的信息能讓你的應用檢測到網絡情況。
檢測網絡信息的API最近已經有所變化了，接口如今不是直接定義Wi一Fi，3G等網絡情況，而是給出了帶寬信息和諸如「很是慢，慢，快和很是快」這樣的建議，有個屬性能給出估計的MB/s值和一個「meterd」的Boolean值來表示它的可信度，可是對瀏覽器來講，很難根據這個來判斷環境，判斷當前網絡環境而後適配仍然是一種最好的方法（具體可查看馬海祥博客《百度移動搜索開放適配服務的3種方法》的相關介紹），可是這種方法正在被考慮被替換。
1六、對多線程來講儘可能使用HTML5的WEB WORKER特性
HTML5中的Web Worker是使用多個線程併發執行Javascript程序，另外，這種特別的多線程實現能減小困惑開發者多年的，在其餘平臺上遇到的問題，例如，當一個線程須要改變一個正在被其餘線程使用的資源該如何處理，在Web Worker中，子線程不能修改主用戶界面（UI）線程使用的資源。
對提升移動站點的性能來講，Web Worker中的代碼很適合用來預處理用戶完成進一步操做所須要的資源的，特別是在用戶的帶寬資源不緊缺的狀況下，在低處理器性能的移動設備上，過多的預加載可能會干擾當前頁面的UI響應，使用多線程代碼，讓Web Worker對象（而且儘量使用localStorage來緩存數據）在另一個線程中操做預加載資源，這樣就能不影響當前的UI表現了。
要特別說明的是，Web Worker只在Android 2.0以上的版本實現，並且iphone上的ios5以前的版本也不支持，在桌面PC上，老是落後的IE只在IE 10才支持Web Worker。
雖然這項技術並非很是難實現，可是對Web Workers來講，有一些限制須要強制遵照，Web Workers不能進入到頁面的DOM，也不能改變頁面上的任何東西，Web Worker很適合那種須要後臺計算和處理的工做。
1七、將CLICK事件替換成TOUCH事件
在觸摸屏設備上，當一個用戶觸碰屏幕的時候，onclick事件並無當即觸發，設備會使用大約半秒（大多數設備差很少都是300毫秒）來讓用戶肯定是手勢操做仍是點擊操做，這個延遲會很明顯地影響用戶指望的響應性能，要使用touchend事件來替換才能解決，當用戶觸碰屏幕的時候，這個事件會當即觸發。
爲了要確保不會產生用戶不指望的行爲，你應該也要使用touchstart和touchmove事件，例如，除非同時有個touchstart事件在button上，不然不要判斷touchend事件在button上就意味着點擊行爲，由於用戶有可能從其餘地方觸碰開始，而後拖拽到button上觸碰結束的，你也能夠在touchstart事件以後使用touchmove事件來避免將touchend事件誤判爲點擊，固然前提是須要假設拖拽的手勢並非預期產生點擊行爲。
另外，你也須要去處理onclick事件來讓瀏覽器改變button的外觀從而標識爲已點擊的狀態，同時你也須要處理那些不支持touch事件的瀏覽器，爲了不代碼在touchend和onclick代碼中重複執行，你須要在確保用戶觸碰事件已經在touchend執行了以後，在click事件中調用preventDefault和stopPropagation方法。
這種技術須要更多工做才能在一個頁面中增長和維護連接，touch事件的代碼必須考慮其餘手勢，由於替換click的還有多是縮放或者敲擊動做。
1八、支持SPDY協議
應用層HTTP和HTTPS協議致使的一些性能瓶頸，使得不管是桌面仍是移動端的網站都很是難受，在2009年，谷歌開始研發一種叫作SPDY（諧意是「speedy」）的協議來替換已有的協議，這種協議宣稱能突破這些限制，這個協議的目標是讓多種瀏覽器和多種Web服務都能支持，因此這個協議是開源的，可是初步地，只有Google的Chrome瀏覽器（在版本10及以後的）和google的站點支持，一旦一個Web服務支持SPDY，那麼它上面的全部站點均可以和支持這個協議的瀏覽器使用SPDY進行交互，將SPDY應用在25個top100的Internet網站上，Google收集到的數據是網站的速度會改善27%到60%不等。
SPDY自動使用gzip壓縮全部內容，和HTTP不一樣的是，它連header的數據也使用gzip壓縮，SPDY使用多線程技術讓多個請求流或者響應流能共用一個TCP鏈接，另外SPDY容許請求設置優先級，好比，頁面中心的視頻會比邊框的廣告擁有更高的優先級。
或許SPDY中最變革性的發明就是流是雙向的，而且能夠由客戶端或者服務端發起，這樣能使得信息能推送到客戶端，而不用由客戶端發起第一次請求，例如，當一個用戶第一次瀏覽一個站點，尚未任何站點的緩存，這個時候服務端就能夠在響應中推送全部的請求資源，而不用等候每一個資源被再次獨立請求了，做爲替換協議，服務端能夠發送暗示給客戶端，提示頁面須要哪些資源，同時也容許由客戶端來初始化請求。即便是使用後一種這樣的方式也比讓客戶端解析頁面而後本身發現有哪些資源須要被請求來得快。
雖然SPDY並無對移動端有什麼特別的設置，可是移動端有限的帶寬就使得若是支持SPDY的話，SPDY在減小移動網站的延遲是很是有用的。
依據網站和服務的環境來進行平穩操做或進一步考慮，Google有一個SPDY模塊支持Apache2.2 – mod_spdy – 這個模塊是免費的；可是mod_spy有線程上的問題，而且和mod_php協做並非很好，因此要求你使用這個技術的時候要確保你的網站的正常運行。
複製代碼