代碼運(yùn)行速度
不要類型轉(zhuǎn)換
即開始是什么類型的變量乖仇，就讓他是什么類型，字符串轉(zhuǎn)數(shù)字最好用parseInt.
不要重新構(gòu)造對(duì)象
不要在以后再添加屬性，最好從一開始定義對(duì)象時(shí)就確定好屬性餐茵。
字符串鏈接
+=運(yùn)算符似乎比+快很多
限制聲明/傳遞變量的范圍（作用域）
假如你調(diào)用一個(gè)函數(shù)，瀏覽器必須做一些所謂的范圍查找递递，它的昂貴程度取決于它要查找多少范圍。盡量不要依賴全局/高范圍的變量谅将，盡量使局部范圍變量漾狼，并將它們傳遞給函數(shù)重慢。更少的范圍查找饥臂，更少的犧牲速度。
頁(yè)面加載速度
延遲請(qǐng)求首屏外的文件
頁(yè)面初步加載這張圖片的時(shí)候是直接以base64的方式（當(dāng)然你也可以統(tǒng)一使用一張占位圖loading.gif來(lái)替代）來(lái)快速顯示一張極小的圖片的似踱，而圖片本身的真實(shí)路徑是存在data-src屬性內(nèi)的
優(yōu)化頁(yè)面模塊排放順序
比如有一個(gè)頁(yè)面是這樣的——左邊是側(cè)邊欄隅熙，用于存放用戶的頭像啊稽煤、資料啊，以及網(wǎng)站投放的廣告啊囚戚，而右側(cè)是文章內(nèi)容區(qū)域：
<body>
<sidebar>
<!-- 側(cè)邊欄內(nèi)容 -->
</sidebar>
<content>
<!-- 文章內(nèi)容 -->
</content>
</body>
于是乎酵熙，瀏覽器按照它的UI單線程準(zhǔn)則從上到下先加載了側(cè)邊欄，再加載我們的文章驰坊。匾二。。
很明顯拳芙，這樣不是一個(gè)人性化的加載順序察藐，我們得弄清楚，頁(yè)面上各個(gè)區(qū)域模塊舟扎，對(duì)于用戶而言分飞，哪個(gè)才是最重要、最應(yīng)當(dāng)首先展示的睹限。
