1. 從用戶角度而言，優(yōu)化能夠讓頁面加載得更快、對用戶的操作響應得更及時，能夠給用戶提供更為友好的體驗。
2. 從服務商角度而言，優(yōu)化能夠減少頁面請求數(shù)、或者減小請求所占帶寬，能夠節(jié)省可觀的資源。
h5的優(yōu)化
1.減少多余的dom節(jié)點嵌套
2.標簽的語義化使用，比如標題就用h1-h6，圖文列表用figure figcaption，頭部用 header，底部footer，導航nav，側邊菜單欄 aside，文章用article，模塊用section等
3.使用數(shù)據(jù)緩存，sessionStorage，localStorage，離線緩存，indexedDB本地數(shù)據(jù)庫
4.頁面SEO的優(yōu)化：title、keyword、description，圖片的alt，a標簽的title
圖片的優(yōu)化
1.減小圖片的的大小，小圖標使用svg,png，背景圖片用jpg
2.雪碧圖的使用，減少對服務器的請求次數(shù)
3.圖片預加載
4.字體圖標的使用（阿里巴巴字體圖標庫IconFont）
css優(yōu)化
1.壓縮image
使用雪花圖
使用雪花圖 www.spritecow.com/
使用矢量圖
使用矢量圖字體 fontawesome.dashgame.com/
使用阿里矢量圖庫 www.iconfont.cn/
使用矢量圖轉成字體 icomoon.io/
使用base64轉換
使用網(wǎng)站壓縮
使用無損壓縮 tinypng.com/
png轉換webp zhitu.isux.us/
合理使用格式圖片
jpg有損壓縮，壓縮率搞，不支持透明
png支持透明，瀏覽器兼容好
webp壓縮程度更好，在ios webview有兼容性問題
svg矢量圖，代碼內(nèi)嵌，相對于較小，圖片樣式相對簡單的場景
function checkWebp() {
try{
return (document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') == 0);
}catch(err) {
return false;
}
}
$(document).ready(function() {
var webp_good = checkWebp();
if(webp_good == false) {
$('img').each(function() {
var src = $(this).attr('src');
if(typeof src != 'undefined') {
src = src.replace('/format,webp', '/format,jpg'); //將webp格式轉換成jpg格式
$(this).attr('src', src);
}
var original = $(this).attr('original'); //針對用了懶加載的情況
if(typeof original != 'undefined') {
original = original.replace('/format,webp', '/format,jpg'); //將webp格式轉換成jpg格式
$(this).attr('original', original);
}
})
}
})
2.易維護：少用ID， !important，多用class
3.樣式用外部樣式，最好不要用行間樣式，內(nèi)嵌樣式
4.選擇器的層級最好不要超過4層，減少層級可減少渲染速度
5.可讀性：類名的命名規(guī)范
6.可擴展性：css的整體設計，公用的樣式抽取，減少冗余的，重復的樣式
7.樣式的引入放在頭部
8 避免使用CSS表達式
9.優(yōu)化CSS Sprite 圖片格式
10.圖像映射
11行內(nèi)圖片（Base64編碼）
12不要用HTML縮放圖片
13用小的可緩存的favicon.ico（P.S. 收藏夾圖標）
14
js優(yōu)化
1.打包js
2.減少全局變量，全局方法的定義
3.減少閉包的使用，避免多層循環(huán)的嵌套
4.減少dom節(jié)點的事件綁定 訪問
5.刪除多余的代碼，公用方法的抽取
6.減少http請求次數(shù)
7.js的引用放在底部
8.去除重復腳本
9.行為與頁面分離：js最好寫在外部文件
10.js的延遲加載 deffer
11 盡量使用css3動替代js動畫
12 設計模式
13把腳本放在底部
14
用戶體驗的優(yōu)化
1.加載頁面，請求接口的loading
2.頁面的平滑滾動，顏色的漸變，適當?shù)膭赢?br>
3.減少操作次數(shù)，減少表單輸入
4.優(yōu)化頁面加載的速度，緩存的合理使用，預加載的使用
5.操作圖標的易讀性，比如說
個人中心的icon
菜單的icon
6.符合用戶的行為，比如說菜單的點擊放在屏幕的右邊
7.搜索引擎的優(yōu)化能夠提升用戶的訪問量
一、頁面級優(yōu)化
1. 減少 HTTP請求數(shù)
這條策略基本上所有前端人都知道，而且也是最重要最有效的。都說要減少 HTTP請求，那請求多了到底會怎么樣呢 ?首先，每個請求都是有成本的，既包含時間成本也包含資源成本。一個完整的請求都需要經(jīng)過 DNS尋址、與服務器建立連接、發(fā)送數(shù)據(jù)、等待服務器響應、接收數(shù)據(jù)這樣一個 “漫長” 而復雜的過程。時間成本就是用戶需要看到或者 “感受” 到這個資源是必須要等待這個過程結束的，資源上由于每個請求都需要攜帶數(shù)據(jù)，因此每個請求都需要占用帶寬。另外，由于瀏覽器進行并發(fā)請求的請求數(shù)是有上限的 (具體參見此處 )，因此請求數(shù)多了以后，瀏覽器需要分批進行請求，因此會增加用戶的等待時間，會給用戶造成站點速度慢這樣一個印象，即使可能用戶能看到的第一屏的資源都已經(jīng)請求完了，但是瀏覽器的進度條會一直存在。
減少 HTTP請求數(shù)的主要途徑包括：
(1). 從設計實現(xiàn)層面簡化頁面
如果你的頁面像百度首頁一樣簡單，那么接下來的規(guī)則基本上都用不著了。保持頁面簡潔、減少資源的使用時最直接的。如果不是這樣，你的頁面需要華麗的皮膚，則繼續(xù)閱讀下面的內(nèi)容。
(2). 合理設置 HTTP緩存
緩存的力量是強大的，恰當?shù)木彺嬖O置可以大大的減少 HTTP請求。以有啊首頁為例，當瀏覽器沒有緩存的時候訪問一共會發(fā)出 78個請求，共 600多 K數(shù)據(jù) (如圖 1.1)，而當?shù)诙卧L問即瀏覽器已緩存之后訪問則僅有 10個請求，共 20多 K數(shù)據(jù) (如圖 1.2)。 (這里需要說明的是，如果直接 F5刷新頁面的話效果是不一樣的，這種情況下請求數(shù)還是一樣，不過被緩存資源的請求服務器是 304響應，只有 Header沒有Body ，可以節(jié)省帶寬 )
怎樣才算合理設置 ?原則很簡單，能緩存越多越好，能緩存越久越好。例如，很少變化的圖片資源可以直接通過 HTTP Header中的Expires設置一個很長的過期頭 ;變化不頻繁而又可能會變的資源可以使用 Last-Modifed來做請求驗證。盡可能的讓資源能夠在緩存中待得更久。關于 HTTP緩存的具體設置和原理此處就不再詳述了，有興趣的可以參考下列文章：
HTTP1.1協(xié)議中關于緩存策略的描述
Fiddler HTTP Performance中關于緩存的介紹
(3). 資源合并與壓縮
如果可以的話，盡可能的將外部的腳本、樣式進行合并，多個合為一個。另外， CSS、 Javascript、Image 都可以用相應的工具進行壓縮，壓縮后往往能省下不少空間。
(4). CSS Sprites
合并 CSS圖片，減少請求數(shù)的又一個好辦法。
(5). Inline Images
使用 data: URL scheme的方式將圖片嵌入到頁面或 CSS中，如果不考慮資源管理上的問題的話，不失為一個好辦法。如果是嵌入頁面的話換來的是增大了頁面的體積，而且無法利用瀏覽器緩存。使用在 CSS中的圖片則更為理想一些。
(6). Lazy Load Images（自己對這一塊的內(nèi)容還是不了解）
這條策略實際上并不一定能減少 HTTP請求數(shù)，但是卻能在某些條件下或者頁面剛加載時減少 HTTP請求數(shù)。對于圖片而言，在頁面剛加載的時候可以只加載第一屏，當用戶繼續(xù)往后滾屏的時候才加載后續(xù)的圖片。這樣一來，假如用戶只對第一屏的內(nèi)容感興趣時，那剩余的圖片請求就都節(jié)省了。曾經(jīng)的做法是在加載的時候把第一屏之后的圖片地址緩存在 Textarea標簽中，待用戶往下滾屏的時候才 “惰性” 加載。
2. 將外部腳本置底（將腳本內(nèi)容在頁面信息內(nèi)容加載后再加載）
前文有談到，瀏覽器是可以并發(fā)請求的，這一特點使得其能夠更快的加載資源，然而外鏈腳本在加載時卻會阻塞其他資源，例如在腳本加載完成之前，它后面的圖片、樣式以及其他腳本都處于阻塞狀態(tài)，直到腳本加載完成后才會開始加載。如果將腳本放在比較靠前的位置，則會影響整個頁面的加載速度從而影響用戶體驗。解決這一問題的方法有很多，而最簡單可依賴的方法就是將腳本盡可能的往后挪，減少對并發(fā)下載的影響。
3. 異步執(zhí)行 inline腳本(其實原理和上面是一樣，保證腳本在頁面內(nèi)容后面加載。)
inline腳本對性能的影響與外部腳本相比，是有過之而無不及。首頁，與外部腳本一樣， inline腳本在執(zhí)行的時候一樣會阻塞并發(fā)請求，除此之外，由于瀏覽器在頁面處理方面是單線程的，當 inline腳本在頁面渲染之前執(zhí)行時，頁面的渲染工作則會被推遲。簡而言之， inline腳本在執(zhí)行的時候，頁面處于空白狀態(tài)。鑒于以上兩點原因，建議將執(zhí)行時間較長的 inline腳本異步執(zhí)行，異步的方式有很多種，例如使用 script元素的defer 屬性(存在兼容性問題和其他一些問題，例如不能使用 document.write)、使用setTimeout ，此外，在HTML5中引入了 Web Workers的機制，恰恰可以解決此類問題。
4. Lazy Load Javascript（只有在需要加載的時候加載，在一般情況下并不加載信息內(nèi)容。）
隨著 Javascript框架的流行，越來越多的站點也使用起了框架。不過，一個框架往往包括了很多的功能實現(xiàn)，這些功能并不是每一個頁面都需要的，如果下載了不需要的腳本則算得上是一種資源浪費 -既浪費了帶寬又浪費了執(zhí)行花費的時間。目前的做法大概有兩種，一種是為那些流量特別大的頁面專門定制一個專用的 mini版框架，另一種則是 Lazy Load。YUI 則使用了第二種方式，在 YUI的實現(xiàn)中，最初只加載核心模塊，其他模塊可以等到需要使用的時候才加載。
5. 將 CSS放在 HEAD中
如果將 CSS放在其他地方比如 BODY中，則瀏覽器有可能還未下載和解析到 CSS就已經(jīng)開始渲染頁面了，這就導致頁面由無 CSS狀態(tài)跳轉到 CSS狀態(tài)，用戶體驗比較糟糕。除此之外，有些瀏覽器會在 CSS下載完成后才開始渲染頁面，如果 CSS放在靠下的位置則會導致瀏覽器將渲染時間推遲。
6. 異步請求 Callback（就是將一些行為樣式提取出來，慢慢的加載信息的內(nèi)容）
在某些頁面中可能存在這樣一種需求，需要使用 script標簽來異步的請求數(shù)據(jù)。類似：
Javascript:
/Callback 函數(shù)/
function myCallback(info){
//do something here
}
HTML:
cb返回的內(nèi)容 :
myCallback('Hello world!');
像以上這種方式直接在頁面上寫 <script>對頁面的性能也是有影響的，即增加了頁面首次加載的負擔，推遲了 DOMLoaded和window.onload 事件的觸發(fā)時機。如果時效性允許的話，可以考慮在 DOMLoaded事件觸發(fā)的時候加載，或者使用 setTimeout方式來靈活的控制加載的時機。
7. 減少不必要的 HTTP跳轉
對于以目錄形式訪問的 HTTP鏈接，很多人都會忽略鏈接最后是否帶 ’/'，假如你的服務器對此是區(qū)別對待的話，那么你也需要注意，這其中很可能隱藏了 301跳轉，增加了多余請求。具體參見下圖，其中第一個鏈接是以無 ’/'結尾的方式訪問的，于是服務器有了一次跳轉。
8. 避免重復的資源請求
這種情況主要是由于疏忽或頁面由多個模塊拼接而成，然后每個模塊中請求了同樣的資源時，會導致資源的重復請求
移動端
5.1 保證所有組件都小于25K
這個限制是因為iPhone不能緩存大于25K的組件，注意這里指的是未壓縮的大小。這就是為什么縮減內(nèi)容本身也很重要，因為單純的gzip可能不夠。
5.2 把組件打包到一個復合文檔里
把各個組件打包成一個像有附件的電子郵件一樣的復合文檔里，可以用一個HTTP請求獲取多個組件（記住一點：HTTP請求是代價高昂的）。用這種方式的時候，要先檢查用戶代理是否支持（iPhone就不支持）。
6 cookie
6.1 給Cookie減肥
使用cookie的原因有很多，比如授權和個性化。HTTP頭中cookie信息在web服務器和瀏覽器之間交換。重要的是保證cookie盡可能的小，以最小化對用戶響應時間的影響。
清除不必要的cookie
保證cookie盡可能小，以最小化對用戶響應時間的影響
注意給cookie設置合適的域級別，以免影響其它子域
設置合適的有效期，更早的有效期或者none可以更快的刪除cookie，提高用戶響應時間
6.2 把組件放在不含cookie的域下
當瀏覽器發(fā)送對靜態(tài)圖像的請求時，cookie也會一起發(fā)送，而服務器根本不需要這些cookie。所以它們只會造成沒有意義的網(wǎng)絡通信量，應該確保對靜態(tài)組件的請求不含cookie?？梢詣?chuàng)建一個子域，把所有的靜態(tài)組件都部署在那兒。
如果域名是www.example.org，可以把靜態(tài)組件部署到static.example.org。然而，如果已經(jīng)在頂級域example.org或者www.example.org設置了cookie，那么所有對static.example.org的請求都會含有這些cookie。這時候可以再買一個新域名，把所有的靜態(tài)組件部署上去，并保持這個新域名不含cookie。Yahoo!用的是yimg.com，YouTube是ytimg.com，Amazon是images-amazon.com等等。
把靜態(tài)組件部署在不含cookie的域下還有一個好處是有些代理可能會拒絕緩存帶cookie的組件。有一點需要注意：如果不知道應該用example.org還是www.example.org作為主頁，可以考慮一下cookie的影響。省略www的話，就只能把cookie寫到*.example.org，所以因為性能原因最好用www子域，并且把cookie寫到這個子域下。
服務器
7.1 Gzip組件
??前端工程師可以想辦法明顯地縮短通過網(wǎng)絡傳輸HTTP請求和響應的時間。毫無疑問，終端用戶的帶寬速度，網(wǎng)絡服務商，對等交換點的距離等等，都是開發(fā)團隊所無法控制的。但還有別的能夠影響響應時間的因素，壓縮可以通過減少HTTP響應的大小來縮短響應時間。
從HTTP/1.1開始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。
??如果web服務器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮響應。web服務器通過Content-Encoding相應頭來通知客戶端。
??盡可能多地用gzip壓縮能夠給頁面減肥，這也是提升用戶體驗最簡單的方法。
7.2 避免圖片src屬性為空
Image with empty string src屬性是空字符串的圖片很常見，主要以兩種形式出現(xiàn)：
straight HTML
JavaScript
var img = new Image(); img.src = “”;
這兩種形式都會引起相同的問題：瀏覽器會向服務器發(fā)送另一個請求。
?
7.3 配置ETags
??實體標簽（ETags），是服務器和瀏覽器用來決定瀏覽器緩存中組件與源服務器中的組件是否匹配的一種機制（“實體”也就是組件：圖片，腳本，樣式表等等）。添加ETags可以提供一種實體驗證機制，比最后修改日期更加靈活。一個ETag是一個字符串，作為一個組件某一具體版本的唯一標識符。唯一的格式約束是字符串必須用引號括起來，源服務器用相應頭中的ETag來指定組件的ETag：
??然后，如果瀏覽器必須驗證一個組件，它用If-None-Match請求頭來把ETag傳回源服務器。如果ETags匹配成功，會返回一個304狀態(tài)碼，這樣就減少了12195個字節(jié)的響應體。
GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified
7.4 對Ajax用GET請求
??郵箱團隊發(fā)現(xiàn)使用XMLHttpRequest時，瀏覽器的POST請求是通過一個兩步的過程來實現(xiàn)的：先發(fā)送HTTP頭，在發(fā)送數(shù)據(jù)。所以最好用GET請求，它只需要發(fā)送一個TCP報文（除非cookie特別多）。IE的URL長度最大值是2K，所以如果要發(fā)送的數(shù)據(jù)超過2K就無法使用GET了。
POST請求的一個有趣的副作用是實際上沒有發(fā)送任何數(shù)據(jù)，就像GET請求一樣。正如HTTP說明文檔中描述的，GET請求是用來檢索信息的。所以它的語義只是用GET請求來請求數(shù)據(jù)，而不是用來發(fā)送需要存儲到服務器的數(shù)據(jù)。
7.5 盡早清空緩沖區(qū)
?當用戶請求一個頁面時，服務器需要用大約200到500毫秒來組裝HTML頁面，在這期間，瀏覽器閑等著數(shù)據(jù)到達。PHP中有一個flush()函數(shù)，允許給瀏覽器發(fā)送一部分已經(jīng)準備完畢的HTML響應，以便瀏覽器可以在后臺準備剩余部分的同時開始獲取組件，好處主要體現(xiàn)在很忙的后臺或者很“輕”的前端頁面上（P.S. 也就是說，響應時耗主要在后臺方面時最能體現(xiàn)優(yōu)勢）。
??較理想的清空緩沖區(qū)的位置是HEAD后面，因為HTML的HEAD部分通常更容易生成，并且允許引入任何CSS和JavaScript文件，這樣就可以讓瀏覽器在后臺還在處理的時候就開始并行獲取組件。
例如：
?<br />... <br /> </head><br /> <?php flush(); ?><br /> <body><br /> ... <br />
復制代碼
?
7.6 使用CDN（內(nèi)容分發(fā)網(wǎng)絡）
??用戶與服務器的物理距離對響應時間也有影響。把內(nèi)容部署在多個地理位置分散的服務器上能讓用戶更快地載入頁面。但具體要怎么做呢？
??實現(xiàn)內(nèi)容在地理位置上分散的第一步是：不要嘗試去重新設計你的web應用程序來適應分布式結構。這取決于應用程序，改變結構可能包括一些讓人望而生畏的任務，比如同步會話狀態(tài)和跨服務器復制數(shù)據(jù)庫事務（翻譯可能不準確）?？s短用戶和內(nèi)容之間距離的提議可能被推遲，或者根本不可能通過，就是因為這個難題。
??記住終端用戶80%到90%的響應時間都花在下載頁面組件上了：圖片，樣式，腳本，F(xiàn)lash等等，這是業(yè)績黃金法則。最好先分散靜態(tài)內(nèi)容，而不是一開始就重新設計應用程序結構。這不僅能夠大大減少響應時間，還更容易表現(xiàn)出CDN的功勞。
??內(nèi)容分發(fā)網(wǎng)絡（CDN）是一組分散在不同地理位置的web服務器，用來給用戶更高效地發(fā)送內(nèi)容。典型地，選擇用來發(fā)送內(nèi)容的服務器是基于網(wǎng)絡距離的衡量標準的。例如：選跳數(shù)（hop）最少的或者響應時間最快的服務器。
7.7 添上Expires或者Cache-Control HTTP頭
這條規(guī)則有兩個方面：
對于靜態(tài)組件：通過設置一個遙遠的將來時間作為Expires來實現(xiàn)永不失效
多余動態(tài)組件：用合適的Cache-ControlHTTP頭來讓瀏覽器進行條件性的請求
??網(wǎng)頁設計越來越豐富，這意味著頁面里有更多的腳本，圖片和Flash。站點的新訪客可能還是不得不提交幾個HTTP請求，但通過使用有效期能讓組件變得可緩存，這避免了在接下來的瀏覽過程中不必要的HTTP請求。有效期HTTP頭通常被用在圖片上，但它們應該用在所有組件上，包括腳本、樣式和Flash組件。
??瀏覽器（和代理）用緩存來減少HTTP請求的數(shù)目和大小，讓頁面能夠更快加載。web服務器通過有效期HTTP響應頭來告訴客戶端，頁面的各個組件應該被緩存多久。用一個遙遠的將來時間做有效期，告訴瀏覽器這個響應在2010年4月15日前不會改變。
如果你用的是Apache服務器，用ExpiresDefault指令來設置相對于當前日期的有效期。下面的例子設置了從請求時間起10年的有效期：
ExpiresDefault "access plus 10 years"
7.8 減少dns查詢
域名系統(tǒng)建立了主機名和IP地址間的映射，就像電話簿上人名和號碼的映射一樣。當你在瀏覽器輸入www.shanghai70.com的時候，瀏覽器就會聯(lián)系DNS解析器返回服務器的IP地址。DNS是有成本的，它需要20到120毫秒去查找給定主機名的IP地址。在DNS查找完成之前，瀏覽器無法從主機名下載任何東西。
??DNS查找被緩存起來更高效，由用戶的ISP（網(wǎng)絡服務提供商）或者本地網(wǎng)絡存在一個特殊的緩存服務器上，但還可以緩存在個人用戶的計算機上。DNS信息被保存在操作系統(tǒng)的DNS cache(微軟Windows上的”DNS客戶端服務”)里。大多數(shù)瀏覽器有獨立于操作系統(tǒng)的自己的cache。只要瀏覽器在自己的cache里還保留著這條記錄，它就不會向操作系統(tǒng)查詢DNS。
??IE默認緩存DNS查找30分鐘，寫在DnsCacheTimeout注冊表設置中。Firefox緩存1分鐘，可以用network.dnsCacheExpiration配置項設置。(Fasterfox把緩存時間改成了1小時 P.S. Fasterfox是FF的一個提速插件)
??如果客戶端的DNS cache是空的（包括瀏覽器的和操作系統(tǒng)的），DNS查找數(shù)等于頁面上不同的主機名數(shù)，包括頁面URL，圖片，腳本文件，樣式表，F(xiàn)lash對象等等組件中的主機名，減少不同的主機名就可以減少DNS查找。
??減少不同主機名的數(shù)量同時也減少了頁面能夠并行下載的組件數(shù)量，避免DNS查找削減了響應時間，而減少并行下載數(shù)量卻增加了響應時間。我的原則是把組件分散在2到4個主機名下，這是同時減少DNS查找和允許高并發(fā)下載的折中方案。
7.9 避免重定向
重定向用301和302狀態(tài)碼，下面是一個有301狀態(tài)碼的HTTP頭
HTTP/1.1 301 Moved Permanently Location: example.com/newuri Content-Type: text/html
瀏覽器會自動跳轉到Location域指明的URL。重定向需要的所有信息都在HTTP頭部，而響應體一般是空的。其實額外的HTTP頭，比如Expires和Cache-Control也表示重定向。除此之外還有別的跳轉方式：refresh元標簽和JavaScript，但如果你必須得做重定向，最好用標準的3xxHTTP狀態(tài)碼，主要是為了讓返回按鈕能正常使用。
??牢記重定向會拖慢用戶體驗，在用戶和HTML文檔之間插入重定向會延遲頁面上的所有東西，頁面無法渲染，組件也無法開始下載，直到HTML文檔被送達瀏覽器。
??有一種常見的極其浪費資源的重定向，而且web開發(fā)人員一般都意識不到這一點，就是URL尾部缺少一個斜線的時候。例如，跳轉到www.shanghai70.com/a會返回一個重定向到www.shanghai70.com/b的301響應（注意添在尾部的斜線）。在Apache中可以用Alias，mod_rewrite或者DirectorySlash指令來取消不必要的重定向。
??重定向最常見的用途是把舊站點連接到新的站點，還可以連接同一站點的不同部分，針對用戶的不同情況（瀏覽器類型，用戶帳號類型等等）做一些處理。用重定向來連接兩個網(wǎng)站是最簡單的，只需要少量的額外代碼。雖然在這些時候使用重定向減少了開發(fā)人員的開發(fā)復雜度，但降低了用戶體驗。一種替代方案是用Alias和mod_rewrite，前提是兩個代碼路徑都在相同的服務器上。如果是因為域名變化而使用了重定向，就可以創(chuàng)建一條CNAME（創(chuàng)建一個指向另一個域名的DNS記錄作為別名）結合Alias或者mod_rewrite指令。
7.10 Json格式傳輸
在客戶端和服務器端進行數(shù)據(jù)通信的時候，我們盡量采用json格式進行數(shù)據(jù)傳輸
json格式的數(shù)據(jù)，能夠清晰明了的展示出數(shù)據(jù)結構，而且也方便我們獲取的操作
相對于很早以前的xml格式傳輸，json格式的數(shù)據(jù)更加輕量級
客戶端和服務器端都支持json格式數(shù)據(jù)的處理，處理起來非常的方便
https://juejin.im/post/5cf61ed3e51d4555fd20a2f3 如何快速提升 JSON.stringify() 的性能？
https://juejin.im/post/5e8b094a6fb9a03c300f8b25 微前端在企業(yè)級應用中的實踐
https://juejin.im/post/5e0fef935188253a624a6a72 《CSS揭秘》實用技巧總結
https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/JS-SDK.html， 登錄分享是調(diào)用了微信公眾號js-sdk
