?1：如何檢測(cè)一個(gè)變量是字符串？如何檢測(cè)為對(duì)象類型呢？

1:使用typeOF檢測(cè)字符串
var str;alert(typeOf str) 2：給測(cè)試變量加上一個(gè)空白字符，然后與測(cè)試變量做全等判斷，就可以得出這個(gè)變量是否是字符串。
<script type="text/javascript">
? var str='ss';
? var stt=str+'';
? alert(str==stt); //輸出為真
</script

??? 2：對(duì)于頁(yè)面加載緩慢，如何進(jìn)行優(yōu)化，解決途徑是什么？

??? 我是先講頁(yè)面加載緩慢是那些原因造成的，比如：

??? A：后端的問題。

??????? 一般網(wǎng)頁(yè)第一個(gè)請(qǐng)求是動(dòng)態(tài)請(qǐng)求的概率比較大，如果這個(gè)請(qǐng)求特別耗時(shí)，那肯定不是前端的責(zé)任。

???B：請(qǐng)求過多

?????? 數(shù)一下瀑布圖總共有多少行，onload之前如果有幾百行，那么請(qǐng)求就太多了。一下子加載那么多資源造成擁擠。css，

?? js該合并的合并，圖標(biāo)該精靈的精靈，使用字體圖標(biāo)也很好。還有，有些不重要的東西不用放到onload之前加載，

?? 放到后面也一樣。? 網(wǎng)頁(yè)發(fā)請(qǐng)求數(shù)越少越好。

????? 比如：HTML的話可以從script標(biāo)簽這里說，比如動(dòng)態(tài)加載script標(biāo)簽,異步加載script標(biāo)簽（IE：defer、標(biāo)準(zhǔn)：async）

還有就是css阻塞和js阻塞問題，將script標(biāo)簽放置于</body>之前就可以，行為層與變現(xiàn)層進(jìn)行分開。

? C:某一個(gè)部分請(qǐng)求的時(shí)間花費(fèi)過長(zhǎng)。

???? 請(qǐng)求比其他請(qǐng)求的時(shí)間大出一個(gè)數(shù)量級(jí),這種情況一般是因?yàn)槟骋粋€(gè)資源太慢了,導(dǎo)致網(wǎng)頁(yè)整體變慢,資源慢的原因可能是：

? ?? a)資源在第三方站點(diǎn)上，他們很慢；

? ?? b)這個(gè)資源太大了；

???? c)這個(gè) 資源使用的域名有問題。

? D：網(wǎng)絡(luò)問題

??

仔細(xì)看一下一個(gè)單獨(dú)的http請(qǐng)求，他們會(huì)分為好幾段，分別是域名解析、建立連接、發(fā)送請(qǐng)求、等待響應(yīng)和接收數(shù)據(jù)幾個(gè)階段。
理論上域名解析和建立連接應(yīng)該占用的時(shí)間很小才對(duì)，主要的時(shí)間應(yīng)該用在后面幾個(gè)階段上。上圖中，淺灰色和灰色分別代表域名解析和建立連接。
可以看出這兩個(gè)請(qǐng)求中花費(fèi)在網(wǎng)絡(luò)層上的時(shí)間太長(zhǎng)了，超過總時(shí)間的一半還要多。網(wǎng)絡(luò)層時(shí)間過長(zhǎng)除了可能和底層網(wǎng)絡(luò)有關(guān)之外，還可能和站點(diǎn)的服務(wù)端性能有關(guān)（后端RD的事情哦）。
當(dāng)然，如果這種情況發(fā)生在向第三方站點(diǎn)發(fā)送的請(qǐng)求上（實(shí)際上也經(jīng)常發(fā)生），建議取消或者更換某些站點(diǎn)功能從而避免這樣的請(qǐng)求了。

?E：接收數(shù)據(jù)時(shí)間過長(zhǎng)

???? 上面說了，http請(qǐng)求的大部分時(shí)間應(yīng)該花在后面幾個(gè)階段，比如等待響應(yīng)和接收數(shù)據(jù)。但是，如果接收數(shù)據(jù)的時(shí)間太長(zhǎng)了

?長(zhǎng)到數(shù)百毫秒甚至以秒計(jì)算的時(shí)候。那也是有問題的。這種情況一般是因?yàn)橄螺d的內(nèi)容太重了，例如大圖片、大腳本等。?

?這類問題可以使用GZIP壓縮、圖片壓縮或者JS/CSS的minify等 手段來解決。

? 還有像CSS Sprites，合并CSS文件等方案。

F:js阻塞請(qǐng)求 ????? ????? ??????圖中兩個(gè)連續(xù)的請(qǐng)求之間出現(xiàn)了一個(gè)很大的空隙，為啥會(huì)出現(xiàn)這個(gè)空隙呢？是因?yàn)閷懙膉s性能有問題，解析執(zhí)行js花了很 長(zhǎng)時(shí)間，導(dǎo)致這段時(shí)間的資源加載都被阻塞住了。 G:如果以上都沒有 ??? ????翻看每個(gè)http請(qǐng)求，仔細(xì)研究每個(gè)請(qǐng)求頭響應(yīng)頭，看看是不是沒有設(shè)置緩存啦，圖片優(yōu)化的不夠好之類的。可以先找個(gè)工具 分析一下，比如：http://speed.mmtrix.com/,問題一目了然。 ? H:采用CDN托管 ????CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。CDN的通俗理解就是網(wǎng)站加速，CPU均衡負(fù)載，可以解決 跨運(yùn)營(yíng)商，?跨地區(qū)，服務(wù)器負(fù)載能力過低，帶寬過少等帶來的網(wǎng)站打開速度慢等問題。 CDN的基本思路是盡可能避開互聯(lián)網(wǎng)上有可能影響 數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母?/strong> 快、更穩(wěn)定。通過在網(wǎng)絡(luò)各處放置節(jié)點(diǎn)服務(wù)器所構(gòu)成的在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)之上的一層智能虛擬網(wǎng)絡(luò)。 ????CDN 系統(tǒng)能夠?qū)崟r(shí)地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時(shí)間等綜合 信息將用戶的請(qǐng)求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上。?其目的是使用戶?可就近取得所需內(nèi)容，解決 ?Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。 M：利用緩存方案 ???服務(wù)端緩存是通過將相同數(shù)據(jù)保存下來，當(dāng)訪問用戶請(qǐng)求相同內(nèi)容時(shí)，不再重新去數(shù)據(jù)庫(kù)查詢數(shù)據(jù)，而是將之前保存在 服務(wù)器的數(shù)據(jù)響應(yīng)給用戶這樣就加快了網(wǎng)站頁(yè)面加載速度，但是臨時(shí)保存會(huì)占用部分服務(wù)器資源。其本質(zhì)是通過空間換取 時(shí)間，提高網(wǎng)頁(yè)加載速度。頁(yè)面緩存指的是將用戶請(qǐng)求過的頁(yè)面完整保存下來，有相同請(qǐng)求時(shí)直接響應(yīng)給用戶，此方式數(shù) 據(jù)量是最大的；頁(yè)面部分緩存是指輸出緩存頁(yè)面的某些部分，而不是緩存整個(gè)頁(yè)面內(nèi)容。

? 實(shí)現(xiàn)頁(yè)面部分緩存有 兩種機(jī)制：

? 第一種：對(duì)用戶控件進(jìn)行緩存配置

???? 此種是將頁(yè)面中需要緩存的部分置于用戶控件（.ascx文件）中，并且為用戶控件設(shè)置緩存功能

（包含用戶控件的ASP.NET頁(yè)面可設(shè)置也可不 設(shè)置緩存）。

???? 這就是通常所說的“控件緩存”。

???? 主要包括以下3種方法：

???? 一：使用@ OutputCache指令以聲明方式為用戶控件設(shè)置緩存功能，

???? 二：在代碼隱藏文件中使用PartialCachingAttribute類設(shè)置用戶控件 緩存；

? ?? 三：使用ControlCachePolicy類以編程方式指定用戶控件緩存設(shè)置。

? 第二種：“緩存后替換”的方法。

?該方法與控件緩存正好 相反，將頁(yè)面中的某一部分設(shè)置為不緩存，因此，盡管緩存了整個(gè)頁(yè)面，

但是當(dāng)再次請(qǐng)求該頁(yè)時(shí)，將重新處理那些沒有設(shè)置為緩存的內(nèi)容。

轉(zhuǎn)載于:https://www.cnblogs.com/canning-gao/p/5653701.html

總結(jié)

以上是生活随笔為你收集整理的细节总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。