摘要:但是還是會(huì)阻塞事件,所以會(huì)可能在觸發(fā)前或后執(zhí)行,但是一定會(huì)在事件前觸發(fā)。當(dāng)監(jiān)聽(tīng)到該圖片元素進(jìn)入可視窗口時(shí),即將自定義屬性中的地址存儲(chǔ)到屬性中,達(dá)到懶加載的效果。當(dāng)代碼執(zhí)行,線程被凍結(jié)。所以的性能讓變慢。
概括 涉及到的分類
網(wǎng)絡(luò)層面
構(gòu)建層面
瀏覽器渲染層面
服務(wù)端層面
涉及到的功能點(diǎn)資源的合并與壓縮
圖片編解碼原理和類型選擇
瀏覽器渲染機(jī)制
懶加載預(yù)加載
瀏覽器存儲(chǔ)
緩存機(jī)制
PWA
Vue-SSR
資源合并與壓縮 http請(qǐng)求的過(guò)程及潛在的性能優(yōu)化點(diǎn)理解減少http請(qǐng)求數(shù)量和減少請(qǐng)求資源大小兩個(gè)優(yōu)化要點(diǎn)
掌握壓縮與合并的原理
掌握通過(guò)在線網(wǎng)站和fis3兩種實(shí)現(xiàn)壓縮與合并的方法
瀏覽器的一個(gè)請(qǐng)求從發(fā)送到返回都經(jīng)歷了什么動(dòng)態(tài)的加載靜態(tài)的資源
dns是否可以通過(guò)緩存減少dns查詢時(shí)間
網(wǎng)絡(luò)請(qǐng)求的過(guò)程走最近的網(wǎng)絡(luò)環(huán)境
相同的靜態(tài)資源是否可以緩存
能否減少http請(qǐng)求大小
能否減少http請(qǐng)求數(shù)量
服務(wù)端渲染
資源的合并與壓縮設(shè)計(jì)到的性能點(diǎn)減少http請(qǐng)求的數(shù)量
減少請(qǐng)求的大小
html壓縮HTML代碼壓縮就是壓縮這些在文本文件中有意義,但是在HTML中不顯示的字符,包括空格,制表符,換行符等,還有一些其他意義的字符,如HTML注釋也可以被壓縮
意義
大型網(wǎng)站意義比較大
如何進(jìn)行html的壓縮使用在線網(wǎng)站進(jìn)行壓縮(走構(gòu)建工具多,公司級(jí)在線網(wǎng)站手動(dòng)壓縮小)
node.js提供了html-minifier工具
后端模板引擎渲染壓縮
css及js壓縮 css的壓縮
無(wú)效代碼刪除
注釋、無(wú)效字符
css語(yǔ)義合并
css壓縮的方式使用在線網(wǎng)站進(jìn)行壓縮
使用html-minifier對(duì)html中的css進(jìn)行壓縮
使用clean-css對(duì)css進(jìn)行壓縮
js的壓縮語(yǔ)混亂
無(wú)效字符的刪除
空格、注釋、回車等
剔除注釋
代碼語(yǔ)意的縮減和優(yōu)化
變量名縮短(a,b)等
代碼保護(hù)
前端代碼是透明的,客戶端代碼用戶是可以直接看到的,可以輕易被窺探到邏輯和漏洞
js壓縮的方式使用在線網(wǎng)站進(jìn)行壓縮
使用html-minifier對(duì)html中的js進(jìn)行壓縮
使用uglifyjs2對(duì)js進(jìn)行壓縮
不合并文件可能存在的問(wèn)題文件與文件有插入之間的上行請(qǐng)求,又增加了N-1個(gè)網(wǎng)絡(luò)延遲
受丟包問(wèn)題影響更嚴(yán)重
經(jīng)過(guò)代理服務(wù)器時(shí)可能會(huì)被斷開(kāi)
文件合并缺點(diǎn)
首屏渲染問(wèn)題
文件合并之后的js變大,如果首頁(yè)的渲染依賴這個(gè)js的話,整個(gè)頁(yè)面的渲染要等js請(qǐng)求完才能執(zhí)行
如果首屏只依賴a.js,只要等a.js完成后就可執(zhí)行
沒(méi)有通過(guò)服務(wù)器端渲染,現(xiàn)在框架都需要等合并完的文件請(qǐng)求完才能執(zhí)行,基本都需要等文件合并后的js
緩存失效問(wèn)題
標(biāo)記 js`md5`戳
合并之后的js,任何一個(gè)改動(dòng)都會(huì)導(dǎo)致大面積的緩存失效
文件合并對(duì)應(yīng)缺點(diǎn)的處理公共庫(kù)合并
不同頁(yè)面的合并
不同頁(yè)面js多帶帶打包
見(jiàn)機(jī)行事,隨機(jī)應(yīng)變
文件合并對(duì)應(yīng)方法使用在線網(wǎng)站進(jìn)行合并
構(gòu)建階段,使用nodejs進(jìn)行文件合并
圖片相關(guān)優(yōu)化 一張JPG的解析過(guò)程
jpg有損壓縮:雖然損失一些信息,但是肉眼可見(jiàn)影響并不大
png8???----256色 + 支持透明
png24 ----2^24 + 不支持透明
png32??---2^24 +支持透明
文件大小 + 色彩豐富程度
png32是在png24上支持了透明,針對(duì)不同的業(yè)務(wù)場(chǎng)景選擇不同的圖片格式很重要
不同的格式圖片常用的業(yè)務(wù)場(chǎng)景 不同格式圖片的特點(diǎn)jpg有損壓縮,壓縮率高,不支持透明
png支持透明,瀏覽器兼容性好
webp壓縮程度更好,在ios webview中有兼容性問(wèn)題
svg矢量圖,代碼內(nèi)嵌,相對(duì)較小,圖片樣式相對(duì)簡(jiǎn)單的場(chǎng)景(盡量使用,繪制能力有限,圖片簡(jiǎn)單用的比較多)
不同格式圖片的使用場(chǎng)景jpg:大部分不需要透明圖片的業(yè)務(wù)場(chǎng)景
png:大部分需要透明圖片的業(yè)務(wù)場(chǎng)景
webp:android全部(解碼速度和壓縮率高于jpg和png,但是ios safari還沒(méi)支持)
svg:圖片樣式相對(duì)簡(jiǎn)單的業(yè)務(wù)場(chǎng)景
圖片壓縮的幾種情況針對(duì)真實(shí)圖片情況,舍棄一些相對(duì)無(wú)關(guān)緊要的色彩信息
CSS雪碧圖:把你的網(wǎng)站用到的一些圖片整合到一張多帶帶的圖片中
優(yōu)點(diǎn):減少HTTP請(qǐng)求的數(shù)量(通過(guò)backgroundPosition定位所需圖片)
缺點(diǎn):整合圖片比較大時(shí),加載比較慢(如果這張圖片沒(méi)有加載成功,整個(gè)頁(yè)面會(huì)失去圖片信息)facebook官網(wǎng)任然在用,主要pc用的比較多,相對(duì)性能比較強(qiáng)
Image-inline:將圖片的內(nèi)容嵌到html中(減少網(wǎng)站的HTTP請(qǐng)求)
base64信息,減少網(wǎng)站的HTTP請(qǐng)求,如果圖片比較小比較多,時(shí)間損耗主要在請(qǐng)求的骨干網(wǎng)絡(luò)
使用矢量圖
使用SVG進(jìn)行矢量圖的繪制
使用icon-font解決icon問(wèn)題
在android下使用webp
webp的優(yōu)勢(shì)主要體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法,能帶來(lái)更小的圖片體積,而且擁有肉眼識(shí)別無(wú)差異的圖像質(zhì)量;
同時(shí)具備了無(wú)損和有損的壓縮模式、Alpha透明以及動(dòng)畫(huà)的特性,在JPEG和PNG上的轉(zhuǎn)化效果都非常優(yōu)秀、穩(wěn)定和統(tǒng)一
css和js的裝載與執(zhí)行 HTML頁(yè)面加載渲染的過(guò)程 一個(gè)網(wǎng)站在瀏覽器端是如何進(jìn)行渲染的 HTML渲染過(guò)程中的一些特點(diǎn)
順序執(zhí)行,并發(fā)加載
詞法分析:從上到下依次解析
通過(guò)HTML生成Token對(duì)象(當(dāng)前節(jié)點(diǎn)的所有子節(jié)點(diǎn)生成后,才會(huì)通過(guò)next token獲取到當(dāng)前節(jié)點(diǎn)的兄弟節(jié)點(diǎn)),最終生成Dom Tree
并發(fā)加載:資源請(qǐng)求是并發(fā)請(qǐng)求的
并發(fā)上限
瀏覽器中可以支持并發(fā)請(qǐng)求,不同瀏覽器所支持的并發(fā)數(shù)量不同(以域名劃分),以Chrome為例,并發(fā)上限為6個(gè)
優(yōu)化點(diǎn): 把CDN資源分布在多個(gè)域名下
是否阻塞
css阻塞
css 在head中通過(guò)link引入會(huì)阻塞頁(yè)面的渲染
如果我們把css代碼放在head中去引入的話,那么我們整個(gè)頁(yè)面的渲染實(shí)際上就會(huì)等待head中css加載并生成css樹(shù),最終和DOM整合生成RanderTree之后才會(huì)進(jìn)行渲染
為了瀏覽器的渲染,能讓頁(yè)面顯示的時(shí)候視覺(jué)上更好。
避免某些情況,如:假設(shè)你放在頁(yè)面最底部,用戶打開(kāi)頁(yè)面時(shí),有可能出現(xiàn),頁(yè)面先是顯示一大堆文字或圖片,自上而下,絲毫沒(méi)有排版和樣式可言。最后,頁(yè)面又恢復(fù)所要的效果
- `css`不阻塞`js`的加載,但阻塞`js`的執(zhí)行 - `css`不阻塞外部腳步的加載(`webkit preloader 預(yù)資源加載器`) - `js`阻塞 - 直接通過(guò)``)
(這是延遲執(zhí)行引入的js腳本(即腳本加載是不會(huì)導(dǎo)致解析停止,等到document全部解析完畢后,defer-script也加載完畢后,在執(zhí)行所有的defer-script加載的js代碼,再觸發(fā)Domcontentloaded)
- `async`屬性(``) - 這是異步執(zhí)行引入的`js`腳本文件 - 與`defer`的區(qū)別是`async`會(huì)在加載完成后就執(zhí)行,但是不會(huì)影響阻塞到解析和渲染。但是還是會(huì)阻塞`load`事件,所以`async-script`會(huì)可能在`DOMcontentloaded`觸發(fā)前或后執(zhí)行,但是一定會(huì)在`load`事件前觸發(fā)。懶加載與預(yù)加載 懶加載
圖片進(jìn)入可視區(qū)域之后請(qǐng)求圖片資源
對(duì)于電商等圖片很多,頁(yè)面很長(zhǎng)的業(yè)務(wù)場(chǎng)景適用
減少無(wú)效資源的加載
并發(fā)加載的資源過(guò)多會(huì)會(huì)阻塞js的加載,影響網(wǎng)站的正常使用
img src被設(shè)置之后,webkit解析到之后才去請(qǐng)求這個(gè)資源。所以我們希望圖片到達(dá)可視區(qū)域之后,img src才會(huì)被設(shè)置進(jìn)來(lái),沒(méi)有到達(dá)可視區(qū)域前并不現(xiàn)實(shí)真正的src,而是類似一個(gè)1px的占位符。
場(chǎng)景:電商圖片
預(yù)加載圖片等靜態(tài)資源在使用之前的提前請(qǐng)求
資源使用到時(shí)能從緩存中加載,提升用戶體驗(yàn)
頁(yè)面展示的依賴關(guān)系維護(hù)
場(chǎng)景:抽獎(jiǎng)
懶加載原生js和zepto.lazyload原理
先將img標(biāo)簽中的src鏈接設(shè)為同一張圖片(空白圖片),將其真正的圖片地址存儲(chǔ)再img標(biāo)簽的自定義屬性中(比如data-src)。當(dāng)js監(jiān)聽(tīng)到該圖片元素進(jìn)入可視窗口時(shí),即將自定義屬性中的地址存儲(chǔ)到src屬性中,達(dá)到懶加載的效果。
注意問(wèn)題:
關(guān)注首屏處理,因?yàn)檫€沒(méi)滑動(dòng)
占位,圖片大小首先需要預(yù)設(shè)高度,如果沒(méi)有設(shè)置的話,會(huì)全部顯示出來(lái)
var viewheight = document.documentElement.clientHeight //可視區(qū)域高度 function lazyload(){ var eles = document.querySelectorAll("img[data-original][lazyload]") Array.prototype.forEach.call(eles,function(item,index){ var rect; if(item.dataset.original === "") return; rect = item.getBoundingClientRect(); //返回元素的大小及其相對(duì)于視口的 if(rect.bottom >= 0 && rect.top < viewheight){ !function(){ var img = new Image(); img.src = item.dataset.url; img.onload = function(){ item.src = img.src } item.removeAttribute("data-original"); item.removeAttribute("lazyload"); }() } }) } lazyload() document.addEventListener("scroll",lazyload)預(yù)加載原生js和preloadJS實(shí)現(xiàn) 預(yù)加載實(shí)現(xiàn)的幾種方式
第一種方式:直接請(qǐng)求下來(lái)
第二種方式:image對(duì)象
var image = new Image(); image.src = "www.pic26.com/dafdafd/safdas.jpg";
第三種方式:xmlhttprequest
缺點(diǎn):存在跨域問(wèn)題
優(yōu)點(diǎn):好控制
var xmlhttprequest = new XMLHttpRequest(); xmlhttprequest.onreadystatechange = callback; xmlhttprequest.onprogress = progressCallback; xmlhttprequest.open("GET","http:www.xxx.com",true); xmlhttprequest.send(); function callback(){ if(xmlhttprequest.readyState == 4 && xmlhttprequest.status == 200){ var responseText = xmlhttprequest.responseText; }else{ console.log("Request was unsuccessful:" + xmlhttprequest.status); } } function progressCallback(){ e = e || event; if(e.lengthComputable){ console.log("Received"+e.loaded+"of"+e.total+"bytes") } }
?
PreloadJS模塊
本質(zhì):權(quán)衡瀏覽器加載能力,讓它盡可能飽和利用起來(lái)
重繪與回流 css性能讓javascript變慢要把css相關(guān)的外部文件引入放進(jìn)head中,加載css時(shí),整個(gè)頁(yè)面的渲染是阻塞的,同樣的執(zhí)行javascript代碼的時(shí)候也是阻塞的,例如javascript死循環(huán)。
一個(gè)線程 => javascript解析 一個(gè)線程 => UI渲染
這兩個(gè)線程是互斥的,當(dāng)UI渲染的時(shí)候,javascript的代碼被終止。當(dāng)javascript代碼執(zhí)行,UI線程被凍結(jié)。所以css的性能讓javascript變慢。
頻繁觸發(fā)重繪與回流,會(huì)導(dǎo)致UI頻繁渲染,最終導(dǎo)致js變慢
什么是重繪和回流 回流當(dāng)render tree中的一部分(或全部)因?yàn)樵氐?b>規(guī)模尺寸,布局,隱藏等改變而需要重新構(gòu)建。這就成為回流(reflow)
當(dāng)頁(yè)面布局和幾何屬性改變時(shí),就需要回流
重繪當(dāng)render tree中的一些元素需要更新屬性,而這些屬性只是影響元素的外觀,風(fēng)格,而不影響布局,比如background-color。就稱重繪
關(guān)系用到chrome 分析 performance
回流必將引起重繪,但是重繪不一定會(huì)引起回流
避免重繪、回流的兩種方法 觸發(fā)頁(yè)面重布局的一些css屬性
盒子模型相關(guān)屬性會(huì)觸發(fā)重布局
width
height
padding
margin
display
border-width
border
min-height
定位屬性及浮動(dòng)也會(huì)觸發(fā)重布局
top
bottom
left
right
position
float
clear
改變節(jié)點(diǎn)內(nèi)部文字結(jié)構(gòu)也會(huì)觸發(fā)重布局
text-align
overflow-y
font-weight
overflow
font-family
line-height
vertical-align
white-space
font-size
優(yōu)化點(diǎn):使用不觸發(fā)回流的方案替代觸發(fā)回流的方案
只觸發(fā)重繪不觸發(fā)回流color
border-style、border-radius
visibility
text-decoration
background、background-image、background-position、background-repeat、background-size
outline、outline-color、outline-style、outline-width
box-shadow
新建DOM的過(guò)程獲取DOM后分割為多個(gè)圖層
對(duì)每個(gè)圖層的節(jié)點(diǎn)計(jì)算樣式結(jié)果(Recalculate style 樣式重計(jì)算)
為每個(gè)節(jié)點(diǎn)生成圖形和位置(Layout 回流和重布局)
將每個(gè)節(jié)點(diǎn)繪制填充到圖層位圖中(Paint Setup和Paint 重繪)
圖層作為紋理上傳至gpu
符合多個(gè)圖層到頁(yè)面上生成最終屏幕圖像(Composite Layers 圖層重組)
瀏覽器繪制DOM的過(guò)程是這樣子的:獲取 DOM 并將其分割為多個(gè)層(layer),將每個(gè)層獨(dú)立地繪制進(jìn)位圖(bitmap)中
將層作為紋理(texture)上傳至 GPU,復(fù)合(composite)多個(gè)層來(lái)生成最終的屏幕圖像
left/top/margin之類的屬性會(huì)影響到元素在文檔中的布局,當(dāng)對(duì)布局(layout)進(jìn)行動(dòng)畫(huà)時(shí),該元素的布局改變可能會(huì)影響到其他元素在文檔中的位置,就導(dǎo)致了所有被影響到的元素都要進(jìn)行重新布局,瀏覽器需要為整個(gè)層進(jìn)行重繪并重新上傳到 GPU,造成了極大的性能開(kāi)銷。
transform 屬于合成屬性(composite property),對(duì)合成屬性進(jìn)行 transition/animation 動(dòng)畫(huà)將會(huì)創(chuàng)建一個(gè)合成層(composite layer),這使得被動(dòng)畫(huà)元素在一個(gè)獨(dú)立的層中進(jìn)行動(dòng)畫(huà)。
通常情況下,瀏覽器會(huì)將一個(gè)層的內(nèi)容先繪制進(jìn)一個(gè)位圖中,然后再作為紋理(texture)上傳到 GPU,只要該層的內(nèi)容不發(fā)生改變,就沒(méi)必要進(jìn)行重繪(repaint),瀏覽器會(huì)通過(guò)重新復(fù)合(recomposite)來(lái)形成一個(gè)新的幀。
chrome創(chuàng)建圖層的條件將頻繁重繪回流的DOM元素多帶帶作為一個(gè)獨(dú)立圖層,那么這個(gè)DOM元素的重繪和回流的影響只會(huì)在這個(gè)圖層中
3D或透視變換
CSS 屬性使用加速視頻解碼的 元素
擁有 3D (WebGL) 上下文或加速的
2D 上下文的 元素
復(fù)合插件(如 Flash)
進(jìn)行 opacity/transform 動(dòng)畫(huà)的元素?fù)碛屑铀?/p>
CSS filters 的元素元素有一個(gè)包含復(fù)合層的后代節(jié)點(diǎn)(換句話說(shuō),就是一個(gè)元素?fù)碛幸粋€(gè)子元素,該子元素在自己的層里)
元素有一個(gè) z-index 較低且包含一個(gè)復(fù)合層的兄弟元素(換句話說(shuō)就是該元素在復(fù)合層上面渲染)
總結(jié):對(duì)布局屬性進(jìn)行動(dòng)畫(huà),瀏覽器需要為每一幀進(jìn)行重繪并上傳到 GPU 中對(duì)合成屬性進(jìn)行動(dòng)畫(huà),瀏覽器會(huì)為元素創(chuàng)建一個(gè)獨(dú)立的復(fù)合層,當(dāng)元素內(nèi)容沒(méi)有發(fā)生改變,該層就不會(huì)被重繪,瀏覽器會(huì)通過(guò)重新復(fù)合來(lái)創(chuàng)建動(dòng)畫(huà)幀
gif圖
總結(jié)盡量避免使用觸發(fā)回流、重繪的CSS屬性
將重繪、回流的影響范圍限制在多帶帶的圖層(layers)之內(nèi)
圖層合成過(guò)程中消耗很大頁(yè)面性能,這時(shí)候需要平衡考慮重繪回流的性能消耗
實(shí)戰(zhàn)優(yōu)化點(diǎn)總結(jié)
用translate替代top屬性
top會(huì)觸發(fā)layout,但translate不會(huì)
用opacity代替visibility
opacity不會(huì)觸發(fā)重繪也不會(huì)觸發(fā)回流,只是改變圖層alpha值,但是必須要將這個(gè)圖片獨(dú)立出一個(gè)圖層
visibility會(huì)觸發(fā)重繪
不要一條一條的修改DOM的樣式,預(yù)先定義好class,然后修改DOM的className
把DOM離線后修改,比如:先把DOM給display:none(有一次reflow),然后你修改100次,然后再把它顯示出來(lái)
不要把DOM節(jié)點(diǎn)的屬性值放在一個(gè)循環(huán)里當(dāng)成循環(huán)的變量
offsetHeight、offsetWidth每次都要刷新緩沖區(qū),緩沖機(jī)制被破壞
先用變量存儲(chǔ)下來(lái)
不要使用table布局,可能很小的一個(gè)小改動(dòng)會(huì)造成整個(gè)table的重新布局
div只會(huì)影響后續(xù)樣式的布局
動(dòng)畫(huà)實(shí)現(xiàn)的速度的選擇
選擇合適的動(dòng)畫(huà)速度
根據(jù)performance量化性能優(yōu)化
對(duì)于動(dòng)畫(huà)新建圖層
啟用gpu硬件加速(并行運(yùn)算),gpu加速意味著數(shù)據(jù)需要從cpu走總線到gpu傳輸,需要考慮傳輸損耗.
transform:translateZ(0)
transform:translate3D(0)
瀏覽器存儲(chǔ) cookies 多種瀏覽器存儲(chǔ)方式并存,如何選擇?因?yàn)?b>http請(qǐng)求無(wú)狀態(tài),所以需要cookie去維持客戶端狀態(tài)
cookie的生成方式:
http-->response header-->set-cookie
js中可以通過(guò)document.cookie可以讀寫(xiě)cookie
cookie的使用用處:
用于瀏覽器端和服務(wù)器端的交互(用戶狀態(tài))
客戶端自身數(shù)據(jù)的存儲(chǔ)
expire:過(guò)期時(shí)間
cookie的限制:
作為瀏覽器存儲(chǔ),大小4kb左右
需要設(shè)置過(guò)期時(shí)間 expire
重要屬性:httponly 不支持js讀寫(xiě)(防止收到模擬請(qǐng)求攻擊)
不太作為存儲(chǔ)方案而是用于維護(hù)客戶關(guān)系
優(yōu)化點(diǎn):cookie中在相關(guān)域名下面
cdn的流量損耗
解決方案:cdn的域名和主站域名要分開(kāi)
localStorage localstorageHTML5設(shè)計(jì)出來(lái)專門用于瀏覽器存儲(chǔ)的
大小為5M左右
僅在客戶端使用,不和服務(wù)端進(jìn)行通信
接口封裝較好
瀏覽器本地緩存方案
sessionstorage會(huì)話級(jí)別的瀏覽器存儲(chǔ)
大小為5M左右
僅在客戶端使用,不和服務(wù)器端進(jìn)行通信
接口封裝較好
對(duì)于表單信息的維護(hù)
indexedDBIndexedDB是一種低級(jí)API,用于客戶端存儲(chǔ)大量結(jié)構(gòu)化數(shù)據(jù)。該API使用索引來(lái)實(shí)現(xiàn)對(duì)該數(shù)據(jù)的高性能搜索。雖然Web
Storage對(duì)于存儲(chǔ)叫少量的數(shù)據(jù)很管用,但對(duì)于存儲(chǔ)更大量的結(jié)構(gòu)化數(shù)據(jù)來(lái)說(shuō),這種方法不太有用。IndexedDB提供了一個(gè)解決方案。
為應(yīng)用創(chuàng)建離線版本
cdn域名不要帶cookie
localstorage存庫(kù)、圖片
cookie種在主站下,二級(jí)域名也會(huì)攜帶這個(gè)域名,造成流量的浪費(fèi)
Service Worker產(chǎn)生的意義 PWA與Service WorkerPWA(Progressive Web Apps)是一種Web App新模型,并不是具體指某一種前言的技術(shù)或者某一個(gè)單一的知識(shí)點(diǎn),我們從英文縮寫(xiě)來(lái)看就能看出來(lái),這是一個(gè)漸進(jìn)式的Web App,是通過(guò)一系列新的Web特性,配合優(yōu)秀的UI交互設(shè)計(jì),逐步增強(qiáng)Web App的用戶體驗(yàn)
PWA與Service worker chrome 插件 lighthouse檢測(cè)是不是一個(gè)漸進(jìn)式web app
當(dāng)前手機(jī)在弱網(wǎng)環(huán)境下能不能加載出來(lái)
離線環(huán)境下能不能加載出來(lái)
特點(diǎn)
可靠:沒(méi)有網(wǎng)絡(luò)的環(huán)境中也能提供基本的頁(yè)面訪問(wèn),而不會(huì)出現(xiàn)“未連接到互聯(lián)網(wǎng)”的頁(yè)面
快速:針對(duì)網(wǎng)頁(yè)渲染及網(wǎng)絡(luò)數(shù)據(jù)訪問(wèn)有較好的優(yōu)化
融入(Engaging):應(yīng)用可以被增加到手機(jī)桌面,并且和普通應(yīng)用一樣有全屏、推送等特性
service workerservice worker是一個(gè)腳本,瀏覽器獨(dú)立于當(dāng)前頁(yè)面,將其在后臺(tái)運(yùn)行,為實(shí)現(xiàn)一些不依賴頁(yè)面的或者用戶交互的特性打開(kāi)了一扇大門。在未來(lái)這些特性將包括消息推送,背景后臺(tái)同步,geofencing(地理圍欄定位),但他將推出的第一個(gè)首要的特性,就是攔截和處理網(wǎng)絡(luò)請(qǐng)求的能力,包括以編程方式來(lái)管理被緩存的響應(yīng)。案例分析
Service Worker學(xué)習(xí)與實(shí)踐
了解servie worker
chrome://serviceworker-internals/
chrome://inspect/#service-worker/
service worker網(wǎng)絡(luò)攔截能力,存儲(chǔ)Cache Storage,實(shí)現(xiàn)離線應(yīng)用
indexedDBcallback && callback()寫(xiě)法 相當(dāng)于 if(callback){ callback(); }cookie、session、localStorage、sessionStorage基本操作 indexedDB基本操作
object store:對(duì)象存儲(chǔ) 本身就是結(jié)構(gòu)化存儲(chǔ)
function openDB(name, callback) { //建立打開(kāi)indexdb indexedDB.open var request = window.indexedDB.open(name) request.onerror = function(e) { console.log("on indexedDB error") } request.onsuccess = function(e) { myDB.db = e.target.result callback && callback() } //from no database to first version,first version to second version... request.onupgradeneeded = function() { console.log("created") var store = request.result.createObjectStore("books", { keyPath: "isbn" }) console.log(store) var titleIndex = store.createIndex("by_title", "title", { unique: true }) var authorIndex = store.createIndex("by_author", "author") store.put({ title: "quarry memories", author: "fred", isbn: 123456 }) store.put({ title: "dafd memories", author: "frdfaded", isbn: 12345 }) store.put({ title: "dafd medafdadmories", author: "frdfdsafdafded", isbn: 12345434 }) } } var myDB = { name: "tesDB", version: "2.0.1", db: null } function addData(db, storeName) { } openDB(myDB.name, function() { // myDB.db = e.target.result // window.indexedDB.deleteDatabase(myDB.name) }); //刪除indexedDBindexDB事務(wù)
transcation 與 object store建立關(guān)聯(lián)關(guān)系來(lái)操作object store
建立之初可以配置
var transcation = db.transcation("books", "readwrite") var store = transcation.objectStore("books") var data =store.get(34314) store.delete(2334) store.add({ title: "dafd medafdadmories", author: "frdfdsafdafded", isbn: 12345434 })Service Worker離線應(yīng)用
serviceworker需要https協(xié)議
如何實(shí)現(xiàn)ServiceWorker與主頁(yè)面之間的通信lavas
緩存httpheader 可緩存性期望大規(guī)模數(shù)據(jù)能自動(dòng)化緩存,而不是手動(dòng)進(jìn)行緩存,需要瀏覽器端和服務(wù)器端協(xié)商一種緩存機(jī)制
Cache-Control所控制的緩存策略
last-modified 和 etage以及整個(gè)服務(wù)端瀏覽器端的緩存流程
基于node實(shí)踐以上緩存方式
public:表明響應(yīng)可以被任何對(duì)象(包括:發(fā)送請(qǐng)求的客戶端,代理服務(wù)器,等等)緩存。
private:表明響應(yīng)只能被單個(gè)用戶緩存,不能作為共享緩存(即代理服務(wù)器不能緩存它)。
no-cache:強(qiáng)制所有緩存了該響應(yīng)的緩存用戶,在使用已存儲(chǔ)的緩存數(shù)據(jù)前,發(fā)送帶驗(yàn)證器的請(qǐng)求到原始服務(wù)器
only-if-cached:表明如果緩存存在,只使用緩存,無(wú)論原始服務(wù)器數(shù)據(jù)是否有更新
到期
max-age=
s-maxage=
max-stale[=
表明客戶端愿意接收一個(gè)已經(jīng)過(guò)期的資源。 可選的設(shè)置一個(gè)時(shí)間(單位秒),表示響應(yīng)不能超過(guò)的過(guò)時(shí)時(shí)間。
min-fresh=
表示客戶端希望在指定的時(shí)間內(nèi)獲取最新的響應(yīng)。
重新驗(yàn)證和重新加載重新驗(yàn)證
must-revalidate:緩存必須在使用之前驗(yàn)證舊資源的狀態(tài),并且不可使用過(guò)期資源。
proxy-revalidate:與must-revalidate作用相同,但它僅適用于共享緩存(例如代理),并被私有緩存忽略。
immutable :表示響應(yīng)正文不會(huì)隨時(shí)間而改變。資源(如果未過(guò)期)在服務(wù)器上不發(fā)生改變,因此客戶端不應(yīng)發(fā)送重新驗(yàn)證請(qǐng)求頭(例如If-None-Match或If-Modified-Since)來(lái)檢查更新,即使用戶顯式地刷新頁(yè)面。在Firefox中,immutable只能被用在 https:// transactions.
重新加載
no-store:緩存不應(yīng)存儲(chǔ)有關(guān)客戶端請(qǐng)求或服務(wù)器響應(yīng)的任何內(nèi)容。
no-transform:不得對(duì)資源進(jìn)行轉(zhuǎn)換或轉(zhuǎn)變。Content-Encoding, Content-Range, Content-Type等HTTP頭不能由代理修改。例如,非透明代理可以對(duì)圖像格式進(jìn)行轉(zhuǎn)換,以便節(jié)省緩存空間或者減少緩慢鏈路上的流量。 no-transform指令不允許這樣做。
Expires緩存過(guò)期時(shí)間,用來(lái)指定資源到期的時(shí)間,是服務(wù)器端的時(shí)間點(diǎn)
告訴瀏覽器在過(guò)期時(shí)間前瀏覽器可以直接從瀏覽器緩存中存取數(shù)據(jù),而無(wú)需再次請(qǐng)求
expires是http1.0的時(shí)候的
http1.1時(shí)候,我們希望cache的管理統(tǒng)一進(jìn)行,max-age優(yōu)先級(jí)高于expires,當(dāng)有max-age在的時(shí)候expires可能就會(huì)被忽略。
如果沒(méi)有設(shè)置cache-control時(shí)候會(huì)使用expires
Last-modified和If-Modified-since基于客戶端和服務(wù)器端協(xié)商的緩存機(jī)制
last-modified --> response header
if-modified-since --> request header
需要與cache-control共同使用
last-modified有什么缺點(diǎn)?
某些服務(wù)端不能獲取精確的修改時(shí)間
文件修改時(shí)間改了,但文件的內(nèi)容卻沒(méi)有變
Etag 和 If-none-match文件內(nèi)容的hash值
etag -->reponse header
if-none-match -->request header
需要與cache-control共同使用
好處:
比if-modified-since更加準(zhǔn)確
優(yōu)先級(jí)比etage更高
流程圖服務(wù)端用的node.js因?yàn)楹颓岸擞玫耐环N語(yǔ)言,可以利用服務(wù)端運(yùn)算能力來(lái)進(jìn)行相關(guān)的運(yùn)算而減少前端的運(yùn)算
vue渲染遇到的問(wèn)題
vue-ssr和原理和引用
vue渲染面臨的問(wèn)題先加載vue.js => 執(zhí)行vue.js代碼 => 生成html
以前沒(méi)有前端框架時(shí),
用jsp/php在服務(wù)端進(jìn)行數(shù)據(jù)的填充,發(fā)送給客戶端就是已經(jīng)填充好數(shù)據(jù)`的html
使用jQuery異步加載數(shù)據(jù)
使用React和Vue前端框架
代價(jià):需要框架全部加載完,才能把頁(yè)面渲染出來(lái),頁(yè)面的首屏性能不好
多層次的優(yōu)化方案構(gòu)建層的模板編譯。runtime,compile拆開(kāi),構(gòu)建層做模板編譯工作。webpack構(gòu)建時(shí)候,統(tǒng)一,直接編譯成runtime可以執(zhí)行的代碼
數(shù)據(jù)無(wú)關(guān)的prerender的方式
服務(wù)端渲染
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/102036.html
摘要:前端每周清單年度總結(jié)與盤(pán)點(diǎn)在過(guò)去的八個(gè)月中,我?guī)缀踔蛔隽藘杉拢ぷ髋c整理前端每周清單。本文末尾我會(huì)附上清單線索來(lái)源與目前共期清單的地址,感謝每一位閱讀鼓勵(lì)過(guò)的朋友,希望你們能夠繼續(xù)支持未來(lái)的每周清單。 showImg(https://segmentfault.com/img/remote/1460000010890043); 前端每周清單年度總結(jié)與盤(pán)點(diǎn) 在過(guò)去的八個(gè)月中,我?guī)缀踔蛔隽?..
摘要:是具有此屬性的域名不需要用戶點(diǎn)擊鏈接就在后臺(tái)解析,而域名解析和內(nèi)容載入是串行的網(wǎng)絡(luò)操作,所以這個(gè)方式能減少用戶的等待時(shí)間,提升用戶體驗(yàn)。 web前端性能優(yōu)化主要分為以下幾個(gè)板塊: 加載優(yōu)化 DNS預(yù)解析 合并img、css、javascript文件,減少http請(qǐng)求 緩存一切可緩存資源 使用長(zhǎng)Cache 使用外聯(lián)式引用css、javascript文件 壓縮HTML、css、jav...
摘要:是具有此屬性的域名不需要用戶點(diǎn)擊鏈接就在后臺(tái)解析,而域名解析和內(nèi)容載入是串行的網(wǎng)絡(luò)操作,所以這個(gè)方式能減少用戶的等待時(shí)間,提升用戶體驗(yàn)。 web前端性能優(yōu)化主要分為以下幾個(gè)板塊: 加載優(yōu)化 DNS預(yù)解析 合并img、css、javascript文件,減少http請(qǐng)求 緩存一切可緩存資源 使用長(zhǎng)Cache 使用外聯(lián)式引用css、javascript文件 壓縮HTML、css、jav...
摘要:端優(yōu)談?wù)勱P(guān)于前端的緩存的問(wèn)題我們都知道對(duì)頁(yè)面進(jìn)行緩存能夠有利于減少請(qǐng)求發(fā)送,從而達(dá)到對(duì)頁(yè)面的優(yōu)化。而作為一名有追求的前端,勢(shì)必要力所能及地優(yōu)化我們前端頁(yè)面的性能。這種方式主要解決了淺談前端中的過(guò)早優(yōu)化問(wèn)題過(guò)早優(yōu)化是萬(wàn)惡之源。 優(yōu)化向:?jiǎn)雾?yè)應(yīng)用多路由預(yù)渲染指南 Ajax 技術(shù)的出現(xiàn),讓我們的 Web 應(yīng)用能夠在不刷新的狀態(tài)下顯示不同頁(yè)面的內(nèi)容,這就是單頁(yè)應(yīng)用。在一個(gè)單頁(yè)應(yīng)用中,往往只有一...
摘要:歡迎來(lái)我的個(gè)人站點(diǎn)性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開(kāi)啟性能優(yōu)化之旅高性能滾動(dòng)及頁(yè)面渲染優(yōu)化理論寫(xiě)法對(duì)壓縮率的影響唯快不破應(yīng)用的個(gè)優(yōu)化步驟進(jìn)階鵝廠大神用直出實(shí)現(xiàn)網(wǎng)頁(yè)瞬開(kāi)緩存網(wǎng)頁(yè)性能管理詳解寫(xiě)給后端程序員的緩存原理介紹年底補(bǔ)課緩存機(jī)制優(yōu)化動(dòng) 歡迎來(lái)我的個(gè)人站點(diǎn) 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開(kāi)啟性能優(yōu)化之旅 高性能滾動(dòng) scroll 及頁(yè)面渲染優(yōu)化 理論 | HTML寫(xiě)法...
閱讀 465·2023-04-25 23:00
閱讀 3496·2021-11-22 13:54
閱讀 1899·2021-10-27 14:14
閱讀 1487·2019-08-30 13:59
閱讀 3512·2019-08-23 16:15
閱讀 1959·2019-08-23 16:06
閱讀 3328·2019-08-23 15:26
閱讀 1258·2019-08-23 13:48