整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
站打開速度直接影響著網(wǎng)站用戶的瀏覽體驗(yàn)，試想一下，你打開一個網(wǎng)站卻一直在轉(zhuǎn)打不開，會是什么樣的感受，大多用戶會直接關(guān)閉網(wǎng)站。所以網(wǎng)站打開速度慢會直接影響網(wǎng)站的跳出率。
下面總結(jié)幾個解決網(wǎng)站打開速度很慢有效方法，幫助學(xué)習(xí)建網(wǎng)站的學(xué)員提升網(wǎng)站打開速度。
方法一：盡量使用國內(nèi)主機(jī)
國內(nèi)主機(jī)比國外主機(jī)有著地域上的優(yōu)勢，就是說國內(nèi)機(jī)房離用戶比國外機(jī)房更近，傳輸時間更少。如果網(wǎng)站用戶主要是國內(nèi)用戶的話，最好網(wǎng)站選擇國內(nèi)主機(jī)。這樣國內(nèi)用戶打開速度會高于國外主機(jī)。
IIS7網(wǎng)站監(jiān)控工具可以做到提前預(yù)防各類網(wǎng)站劫持，并且是免費(fèi)在線查詢，通過查詢知道域名是否健康等等。
它可以做到24小時定時監(jiān)控：
1、網(wǎng)站是否被黑
2、網(wǎng)站是否被劫持
3、域名是否被墻
4、DNS是否被污染
5、獨(dú)家檢測網(wǎng)站真實(shí)的完全打開時間
方法二：使用CDN加速
CDN加速的原理簡單地說就是將你網(wǎng)站的內(nèi)容同步到CDN服務(wù)器上，以前用戶訪問網(wǎng)站時，就直接從CDN服務(wù)器上傳輸了。由于CDN服務(wù)器普通速度快，這樣網(wǎng)站打開速度也會變快。國內(nèi)網(wǎng)站普通使用的CDN加速是百度云加速，但要求網(wǎng)站使用的是國內(nèi)備案空間。（相關(guān)知識：什么是CDN CDN加速有什么用？）
方法三：壓縮網(wǎng)站圖片
很多網(wǎng)站打開速度很慢，主要原因就是網(wǎng)頁上的圖片太多，而且都是大圖片，直接拖慢了網(wǎng)站打開速度。解決方法就是使用PS軟件將網(wǎng)站圖片壓縮，減小圖片大小，在不影響清晰度的基礎(chǔ)上降低圖片分辨率。
方法四：JS文件后移
由于瀏覽器打開網(wǎng)頁是按照從上往下的順序展示的，有些網(wǎng)站把JS文件都放在</head>標(biāo)簽上面，這會導(dǎo)致網(wǎng)站打開時先加載JS文件，再加載其它的HTML內(nèi)容。正確做法應(yīng)該是將網(wǎng)站上的所有JS文件后移，放到整個網(wǎng)頁的最底部。
方法五：屏蔽國外文件
對于使用WORDPRESS程序建網(wǎng)站時，WORDPRESS程序會自動調(diào)用國外的谷歌字體，而谷歌在國內(nèi)是無法打開的，這樣就造成網(wǎng)站一直無法加載該文件，影響網(wǎng)站打開速度。解決方法見：解決wordpress網(wǎng)站打開慢，WP程序網(wǎng)站加速方法。
avaScript 既是一個 面向過程的語言 又是一個 面向?qū)ο蟮恼Z言。在 JavaScript 中，通過在運(yùn)行時給空對象附加方法和屬性來創(chuàng)建對象，與編譯語言如 C++ 和 Java 中常見的通過語法來定義類相反。對象構(gòu)造后，它可以用作是創(chuàng)建相似對象的原型。
JavaScript 的動態(tài)特性包括運(yùn)行時構(gòu)造對象、可變參數(shù)列表、函數(shù)變量、動態(tài)腳本執(zhí)行（通過 eval）、對象內(nèi)枚舉（通過 for ... in）和源碼恢復(fù)（JavaScript 程序可以將函數(shù)反編譯回源代碼）。
JavaScript方面，之前寫過《ECMAScript進(jìn)化史(1):話說Web腳本語言王者JavaScript的加冕歷史》
在看 各JavaScript引擎的簡介，及相關(guān)資料/博客收集帖 ，結(jié)合自己的理解，整理一個筆記。現(xiàn)代JavaScript引擎都有哪些特征呢？跟以前的JavaScript引擎有怎樣的差別，為什么變快了那么多？
早期JavaScript引擎的實(shí)現(xiàn)普遍跟同時代的其它腳本語言一樣，比較“偷懶”。反正是“腳本語言”，當(dāng)時的JavaScript腳本通常只包含很簡單的邏輯，只運(yùn)行很短時間就完事。沒啥性能壓力，得不到足夠的重視與開發(fā)資源，性能自然是好不到哪里去，卻也足以滿足當(dāng)時的需求。
非常早期的“Mocha”引擎實(shí)現(xiàn)得確實(shí)非常偷懶。字節(jié)碼解釋器、引用計(jì)數(shù)方式的自動內(nèi)存管理、fat discriminated union形式的值表現(xiàn)形式。犀牛書第4版寫了點(diǎn)JavaScript與引用計(jì)數(shù)的歷史。
1996年，祖師爺Brendan Eich新寫的SpiderMonkey已經(jīng)改為使用mark-and-sweep GC、tagged value。
在V8出現(xiàn)前，SpiderMonkey是native application嵌入JavaScript的最流行選擇。如果大家沒留意過的話，UltraEdit就內(nèi)嵌了SpiderMonkey來讓用戶使用JavaScript寫宏與插件[/url]；Adobe Acrobat也類似。
于是其實(shí)早期的兩個主要的JavaScript引擎實(shí)現(xiàn)，Mozilla SpiderMonkey和Microsoft JScript其實(shí)都一直在用mark-and-sweep GC。也沒啥別的主流JavaScript引擎用過引用計(jì)數(shù)方式來實(shí)現(xiàn)自動內(nèi)存管理的。這點(diǎn)別被忽悠了。
在叫得出名字的JavaScript引擎里只有quad-wheel（沒聽說過么？不奇怪，非主流嘛）是用引用計(jì)數(shù)方式實(shí)現(xiàn)自動內(nèi)存管理的。
老版本IE里JScript雖說是有因?yàn)檠h(huán)引用而導(dǎo)致內(nèi)存泄漏的問題，但那不是因?yàn)镴Script自身用引用計(jì)數(shù)。問題出在JScript與DOM交互的邊界上：IE的DOM節(jié)點(diǎn)（及其它host對象）是COM對象，而COM對象自身是引用計(jì)數(shù)的。在JS一側(cè)GC時DOM節(jié)點(diǎn)被看作根節(jié)點(diǎn)，所以被DOM節(jié)點(diǎn)引用的JS對象不會死；反過來，被JS對象引用的DOM節(jié)點(diǎn)的引用計(jì)數(shù)不為0所以也不會死。這導(dǎo)致JScript與DOM交互時有可能被連累引發(fā)循環(huán)引用->內(nèi)存泄漏的問題。
IE9/Chakra里已經(jīng)通過把DOM對象變成由JavaScript一側(cè)的GC來管理解決了這個問題。
早期JavaScript引擎得到的投入實(shí)在不足，而當(dāng)時的Java虛擬機(jī)（JVM）卻得到了大量資源實(shí)現(xiàn)各種優(yōu)化，包括JIT編譯器之類。這使得用Java寫的Rhino一度能比用C寫的SpiderMonkey跑得還快，因?yàn)?/span>Rhino得益于JVM里優(yōu)秀的JIT編譯器和GC，而SpiderMonkey還在用簡易的解釋器和GC。
這個階段中，JavaScript對象的布局或者說表現(xiàn)方式通常可以叫做“property bag”，本質(zhì)上就跟hashmap一樣。
Rhino是Java版的SpiderMonkey。當(dāng)時Netscape想用純Java來實(shí)現(xiàn)新版瀏覽器，自然需要一個Java版的JavaScript引擎實(shí)現(xiàn)；另外也希望能在服務(wù)器端把JavaScript當(dāng)作Java應(yīng)用里的腳本語言使用。于是Rhino就誕生了。
具體查看《Java集成JavaScript項(xiàng)目工程：基于Rhino的javascript后臺開發(fā)》
Apple把KHTML拿去演化出了WebKit，其中的KJS演化成了JavaScriptCore。KJS影響力遠(yuǎn)不如JavaScriptCore。KJS是為數(shù)不多的沒有JIT編譯器的。
JavaScriptCore源自KJS，但持續(xù)得到蘋果的大力投入，終而青出于藍(lán)勝于藍(lán)，已經(jīng)完全超越了它的前身。
QtScript背后也使用JavaScriptCore。
雖然iOS的Safari和UIWebView控件里跑的都是JavaScriptCore，但只有Apple自己的程序才可以啟用JIT編譯，而第三方的則不行。所以Mobile Chrome for iOS就用不了JavaScriptCore的JIT。
Chakra問世后的JScript已非當(dāng)日吳下阿蒙。
即便Chakra的解釋器也是字節(jié)碼解釋器，它的字節(jié)碼設(shè)計(jì)與老版本JScript的已經(jīng)相當(dāng)不同，解釋器自身的速度都已經(jīng)有所提升。
Chakra里的隱藏類變遷機(jī)制叫做“type evolution”。每個產(chǎn)品都必須發(fā)明些新名詞
E9版Chakra里字段數(shù)量不超過16個的對象可以使用緊湊布局；IE10版Chakra將這限制放寬到30多個字段。
IE9 Chakra的對象布局是對象頭與property數(shù)組分離的。IE10版則將構(gòu)造器函數(shù)里賦值的屬性直接跟對象頭粘在一起分配。
Chakra里的value representation跟V8的比較類似，都是在最低的幾位放tag；不過Chakra的是tagged-value，也就是在小整數(shù)的后面帶上一個0x1的tag，而對象地址是8字節(jié)對齊的于是對象指針的最低3位為0。打tag的取舍正好與V8的tagged-pointer相反，而與更多其它用tagged-value的VM相似，例如說更傳統(tǒng)的Smalltalk實(shí)現(xiàn)，包括現(xiàn)在還可以用到的Squeak，或者是像Ruby等受Smalltalk影響的VM。
注意：IE9在x64上的版本里的Chakra只有解釋器，沒實(shí)現(xiàn)JIT編譯器；到IE10才開始在x64版上提供JIT編譯器。
同樣只有字節(jié)碼解釋器，IE9 64-bit的Chakra仍然可以比IE8 64-bit的JScript 5.8快近10倍
JScript 5.8（IE8里的JScript）之后版本號重新計(jì)算了，下一個大版本就是IE9里的JScript 9.0，代號Chakra，在前面有介紹。
JScript里對象里屬性的存儲基本上是靠Hashtable；數(shù)組性質(zhì)的對象最初也是為稀疏數(shù)組優(yōu)化，背后仍然是用Hashtable來存儲。到IE8/JScript 5.8才加上了對密集數(shù)組的存儲/訪問優(yōu)化。
執(zhí)行引擎是個簡單的解釋器，switch-threading形式的解釋器主循環(huán)，位于CScriptRuntime::Run(VAR*)。在jscript.dll里這個switch被編譯為一個table-based dispatch。
被這兩處調(diào)用：
ScrFncObj::CallWithFrameOnStack(VAR *,int,VAR *,VAR *,ulong)
ScrFncObj::Call(VAR *,int,VAR *,VAR *,ulong)
用于優(yōu)化字符串拼接用的BuildString類。在Chakra里也繼承了下來。
上面的JavaScript引擎都是常見
IronJS原本完全使用F#實(shí)現(xiàn)，后來改為只用F#來實(shí)現(xiàn)parser，而用C#來實(shí)現(xiàn)runtime部分。這是個非常妙的搭配。F#（以及許多函數(shù)式語言）天生就非常適合用來寫需要大量模式匹配的程序，寫parser最適合不過。而runtime部分更多是與.NET的其它部分打交道，這里用C#就會更順手些。
Ironjs是在Microsoft 動態(tài)語言運(yùn)行時之上構(gòu)建的ECMAScript 3.0實(shí)現(xiàn)，它使您可以將JavaScript運(yùn)行時嵌入到.NET應(yīng)用程序中。
使用Ironjs環(huán)境
Ironjs還具有對.NET 2.0和3.0的實(shí)驗(yàn)性支持，可使用CLR2解決方案進(jìn)行編譯并設(shè)置額外的NET2標(biāo)志。
IronJS的parser整體采用top-down operator precedence（TDOP）方式，在JavaScript的引擎實(shí)現(xiàn)中比較少見。不過卻正好與微軟自家的Managed JScript相似。不知道作者在寫IronJS時是否有受Managed JScript的思路影響呢？
如果采用TDOP不是Managed JScript的影響，那或許是受Douglas Crockford大神那篇TDOP教程的影響了。
最初的IronJS其實(shí)用的是基于ANTLR生成的parser。不過后來用F#新寫的parser比老的ANTLR生成的parser快得多。
不過作者決定在下一版IronJS里改為完全使用C#，主要是出于性能方面的考慮。并不是F#本身不夠快，而是F#的各種方便簡潔的功能容易引人寫出不那么快的代碼，而要寫比較高效的代碼樣子會跟C#看起來很像。于是還不如直接用C#好了。
IronJS使用了Nan-boxing，只不過比起那些用C/C++之類的native語言所實(shí)現(xiàn)的NaN-boxing tagged pointer而言，IronJS版的比較“肥”一些——例如說JavaScriptCore的一個tagged pointer在x86-64上就是64位，跟一個double一樣大，指針類型的值跟值類型的值可以重疊在同一個位置上；而在IronJS的則要128位，其中值類型的值與tag在頭64位，而指針類型在后64位。
雖然肥一些，作為Nan-boxing的思路和效果還是類似的。用了tagged pointer之后至少那些值類型的值的內(nèi)存開銷都變小了——不用tagged pointer的話自動裝箱的double在32位CLR上也至少得要16字節(jié)，外加引用它的指針4字節(jié)也得要20字節(jié)了，而IronJS的BoxedValue則總共只要16字節(jié)而且不會有額外指針帶來的間接層，在內(nèi)存局部性上也比不用tagged pointer好。
參考文章：
關(guān)于 JavaScript https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/About_JavaScript
各JavaScript引擎的簡介，及相關(guān)資料/博客收集帖 https://hllvm-group.iteye.com/group/topic/37596
用 JavaScript 解釋 JavaScript 虛擬機(jī)-內(nèi)聯(lián)緩存（inline caches） https://segmentfault.com/a/1190000010819044
GC的三種收集方法：標(biāo)記清除、標(biāo)記整理、復(fù)制算法的原理與特點(diǎn)，分別用在什么地方，優(yōu)化收集方法的思路 https://blog.csdn.net/fateruler/article/details/81158510
轉(zhuǎn)載本站文章《JS引擎(0):JavaScript引擎群雄演義—起底JavaScript引擎》,
請注明出處：https://www.zhoulujun.cn/html/webfront/browser/webkit/2020_0718_8521.html
什么別人打開某一個網(wǎng)頁很快，而我卻很慢？為什么我訪問同一個網(wǎng)站，早上很快，晚上卻很慢？為什么我訪問A網(wǎng)站很快，但是訪問B網(wǎng)站卻很慢？你曾經(jīng)是否有過相同的疑問？
其實(shí)看似簡單的網(wǎng)頁瀏覽，背后其實(shí)是一個很復(fù)雜的過程。今天維度IT管家就來簡單的跟大家聊聊影響網(wǎng)頁打開速度的原因，希望對你有所幫助！
我們先來看個很簡單的圖：
上圖中：用戶在自己電腦上，打開一個網(wǎng)頁，這時候，瀏覽器會對網(wǎng)站所在的服務(wù)器發(fā)起請求，網(wǎng)站服務(wù)器會返回網(wǎng)頁的信息，網(wǎng)頁信息中可能會有：圖片、網(wǎng)頁文件、視頻媒體、文字等內(nèi)容。
在上圖中，有兩臺電腦：用戶電腦、網(wǎng)站所在的服務(wù)器；有兩條寬帶：用戶寬帶、網(wǎng)站所在服務(wù)器的寬帶。
簡單了說完用戶電腦與服務(wù)器的關(guān)系，接下來就直接說原因吧！
一、網(wǎng)絡(luò)帶寬
這是最主要的因素，也就是網(wǎng)友經(jīng)常說的寬帶不夠。同樣的網(wǎng)站，如果寬帶高，訪問速度就會明顯變快。
網(wǎng)絡(luò)的帶寬包含網(wǎng)站地點(diǎn)服務(wù)器帶寬和用戶端帶寬兩個方面，對接點(diǎn)指的是出口端與進(jìn)口端(如電信對網(wǎng)通的對接點(diǎn))。網(wǎng)站地點(diǎn)帶寬及用戶端帶寬對用戶打開網(wǎng)頁的影響，我們可以通過下圖很直觀的看出來：
有一種情況，兩者帶寬都很高，但是打開網(wǎng)頁也會很慢？這就涉及到另外一個因素，那就是：訪問人數(shù)。舉個簡單的例子：你一個人訪問某個網(wǎng)站，網(wǎng)站服務(wù)器的寬帶只為你一個人服務(wù)，那你打開網(wǎng)頁的速度自然也就很快；如果這個時間點(diǎn)，同時有1萬人在訪問這個網(wǎng)站，那么網(wǎng)站服務(wù)器的寬帶需要同時為1萬人服務(wù)，這樣單個人的速率自然就降下來了。所以就會出現(xiàn)即使你的帶寬很高，但是打開網(wǎng)頁依舊很慢的情況。玩游戲的人應(yīng)該深有體會，當(dāng)服務(wù)器人數(shù)爆滿時，自己玩的游戲就會變卡。
二、DNS解析速度
DNS解析是從域名到IP的解析。人們習(xí)慣記憶域名，但機(jī)器間互相只認(rèn)IP地址，域名與IP地址之間是對應(yīng)的，它們之間的轉(zhuǎn)換工作稱為域名解析，域名解析需要由專門的域名解析服務(wù)器來完成。
DNS解析包括往復(fù)解析的次數(shù)及每次解析所花費(fèi)的時間，它們兩者的積即是DNS解析所耗費(fèi)的總時間。許多人無視了DNS解析的因素，其實(shí)它對網(wǎng)站解析速度也是十分重要的。
三、服務(wù)器及用戶端硬件配置
硬件配置決定了電腦對數(shù)據(jù)的處理速度，相同的網(wǎng)絡(luò)環(huán)境下，配置高的服務(wù)器的運(yùn)算能力必定要強(qiáng)一些。同樣在用戶端，相同的網(wǎng)絡(luò)環(huán)境下，你用一臺高配置電腦和低配置的電腦打開相同的頁面，速度也一定不一樣。
四、服務(wù)器軟件
在服務(wù)器端，安裝軟件的數(shù)量以及運(yùn)行是否穩(wěn)定都會影響到服務(wù)器環(huán)境，進(jìn)而影響到網(wǎng)絡(luò)速度。例如服務(wù)器配置軟件防火墻，就會導(dǎo)致網(wǎng)絡(luò)速度受影響。
五、頁面內(nèi)容
如果網(wǎng)頁包含大量未經(jīng)處理的圖片，而這些圖片很大，就會導(dǎo)致打開速度變慢。其他如Flash和影視文件，都會影響訪問速度。
同時冗余代碼也是拖慢網(wǎng)站速度的因素之一。站長需要盡量優(yōu)化代碼，用最少的代碼，實(shí)現(xiàn)最佳的效果。
六、數(shù)據(jù)庫操作
小網(wǎng)站做數(shù)據(jù)庫操作也會影響網(wǎng)站速度，尤其是同時有許多用戶提交評論時，就會發(fā)生操作數(shù)據(jù)庫鎖死，致使網(wǎng)站打不開。
七、使用javascript特效
網(wǎng)站上運(yùn)用javascript特效是大忌，不只是無法被搜索引擎抓取，還會因?yàn)椴粩嘞蚍?wù)器提出請求，導(dǎo)致添加服務(wù)器負(fù)擔(dān)，網(wǎng)站變慢。
具體的例子如鼠標(biāo)特效、節(jié)目的特效、狀態(tài)欄的特效等等。這些特效的原理是先由服務(wù)器下載到用戶端的機(jī)器，然后在本地機(jī)器上運(yùn)轉(zhuǎn)，最終被用戶看到。特效做的多了，用戶本地機(jī)器上就要運(yùn)轉(zhuǎn)大半天才干悉數(shù)完成。
八、過多引用其他網(wǎng)站內(nèi)容
例如引用其他網(wǎng)站的圖像、視頻文件等。如果鏈接到的網(wǎng)站速度慢，甚至那家網(wǎng)站已經(jīng)不存在了，那么用戶打開網(wǎng)頁的速度就會十分慢。
其他還有一些因素，例如我國的寬帶網(wǎng)絡(luò)存在互聯(lián)互通的問題，國內(nèi)南北方服務(wù)器互訪會出現(xiàn)延時現(xiàn)象，直接影響用戶的網(wǎng)頁訪問體驗(yàn)。訪問服務(wù)器在國外的網(wǎng)站，訪問速度也會明顯的下降。
最后總結(jié)
影響網(wǎng)頁打開速率的主要因素有：
服務(wù)器：帶寬、硬件配置、硬件穩(wěn)定性、網(wǎng)絡(luò)穩(wěn)定性
用戶端：帶寬、硬件配置
網(wǎng) 頁：網(wǎng)頁程序的性能、網(wǎng)頁內(nèi)容
其 他：同時訪問人數(shù)、服務(wù)器所在地
再回到開頭的問題，你會發(fā)現(xiàn)，三個問題中，有好幾個因素：不同的用戶電腦、不同的訪問時間（網(wǎng)站訪問人數(shù)有高峰期）、不同的網(wǎng)站（網(wǎng)頁、服務(wù)器不同），就是因?yàn)橛羞@么多不同，所以才造成打開網(wǎng)頁的速度差異！
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
