我想死你們啦~
今天給大家帶來前端面試必會問到的前端性能優化問題,暫定分三期給大家帶來,第一期講述基本的代碼優化,后續還有網絡傳輸層優化和頁面加載速度優化,敬請期待,也歡迎點擊查看原文了解更多前端小知識。
點關注,不迷路,我們一起咸魚翻個身兒。
為什么要進行性能優化?
1.1、HTML/CSS優化
1、能用html/css解決的問題就不要用js,更快的開發速度,更小的維護成本。
適用場景:
//導航高亮 nav li { opacity: 0.5; } nav li:hover { opacity: 1; } //鼠標懸停顯示模塊 .menu { display: none; } .nav:hover + .menu { display: inline-block; } .menu:before { content: ''; position: absolute; top: -20px; left: 0px; width: 100%; height: 20px; }
2、自定義radio/checkbox樣式
input[type=checkbox]{} input[type=checkbox]:checked{}
3、巧用css偽類,合理使用原生選擇器,如::focus、@media、input[type=email]:invalid
4、使用全局樣式sass、scss
5、優化HTML標簽
//一個語義化的網頁布局 <nav></nav> <header></header> <main> <section></section> <section></section> </main> <footer></footer>
6、不濫用高消耗的樣式
7、選擇器合并
8、 0值去單位
1.2、JS優化
1、減少前端代碼耦合
2、JS書寫優化
//bad let num, str, obj; //good let num = 0; str = '', obj = null; //bad getPrice:function(price){ if (price < 0) { return false; }else { return price * 10 } } //good getPrice:function(price){ if (price < 0) { return -1; }else { return price * 10 } } //類型確定,解析器不會去做一些額外的的工作,類型不確定的情況下回發生優化回滾 //優化回滾:編譯器已經編譯完成函數,類型變化導致回滾到通用狀態,重新生成函數
3、減少作用域查找
//bad <script> var map = document.querySelector('#imap'); map.style.height = '10px'; </script> //good <script> !function() { var map = document.querySelector('#imap'); map.style.height = '10px'; } </script>
4、對象嵌套的越深,讀取速度就越慢
5、避免 == 的使用
6、合并表達式
//bad function getPrice(count){ if(count < 0){ return -1; }else { return count * 100; } } //good function getPrice(count){ return count <0 ? return -1 : count * 100; } //在進行代碼壓縮的時候,即時書寫的是if-else,壓縮工具也會幫你把它改成三目運算符的形式
1.3、使用ES6簡化代碼
1、使用箭頭函數取代小函數
var num = [4,6,8,3,1,0] //bad num.sort(function (a,b){ return a-b; }) //good num.sort(a,b => a-b); ``` * 使用ES6的class ``` class Person { constructor(name, age) { this.name = name; this.age = age; } addAge() { this.age++; } setName(name) { this.name = name; } }
2、字符串拼接
let url = `/list.html?page=${page}&type=${type}`;
3、塊級作用域變量,使用let代替var
總結的內容到這里差不多就結束了,大多數來自工作中的一些總結和整理。文中若有不當之處,歡迎指出共同交流~~
orm表單復雜demo制作與涉及到的方法講解,深入理解form基本屬性與使用方法
天給大家帶來的是新浪微博PC端的模擬登陸。
工具
這次使用的工具是Charles和chrome瀏覽器,看過我之前文章的同學應該知道我使用的Mac電腦,Fiddler不能用,之前用虛擬機很麻煩。很早的時候有裝過Charles,但是不太會用,后來發現一篇比較詳細的文章,忘了記錄了。發現Charles還是非常好用的,而且有個很好的功能,就是可以開啟多個Session進行抓取對比,這個功能非常,如果經常做爬蟲調試的人一定能知道。我們抓取一個網站的登錄過程,然后在模擬的過程中,可以再另一個session中抓取自己模擬登錄的過程,然后對比一下自己的請求發送的數據和瀏覽器請求發送的數據是否一致。之前我調試一直都是通過打印查看,這樣一方面很不方便,另外一方面打印也不完整。所以非常推薦大家使用Charles,網上破解也有很多。
Charles
打開Charles,要開啟SSL代理抓取,這樣才能抓取到HTTPS請求,畢竟現在很多網站都已經使用HTTPS請求了
HTTPS抓取設置
Host填*表示匹配所有網址,HTTP請求端口是80端口,HTTPS請求端口是443端口,設置好就可以開始抓取了。
抓取請求
打開chrome瀏覽器,最好清理緩存,然后使用隱身模式訪問https://weibo.com/
打開隱身窗口
無痕模式
在網頁上執行一遍登錄操作
微博登錄過程
抓取到登錄過程后,我們就可以開始分析了,記住一定要清理緩存。我有好幾次抓取都不一樣,后來換了Safari瀏覽器(因為我很少用這個),其實這一步用什么瀏覽器都無所謂,chrome瀏覽器主要是用來調試JS用的。
過程分析
查找登錄請求
登錄一般url里面應該都會有login,而且是post請求,當然不排除其他方式。
https://login.sina.com.cn/sso/login.php?client=ssologin.js(v1.4.19)
登錄請求url
找到登錄請求后,這里主要關注Form表單信息,參數很多,我們需要先大概區分一下哪些可能是固定參數,哪些是變化的參數。
參數確定
一目了然可以看到那些是固定的了吧,這些所有的參數其實我們都是可以追根溯源的,但是沒那個必要,在這種參數比較多的情況下,太費事了,可以采用多次抓取登錄過程,對比請求參數的方式確定部分固定的或者不重要的參數,那么需要我們通過其他方式獲取的參數有pcid、door、su、servertime、nonce、rsakv、sp、prelt,這里servertime比較有爭議,一般看到這種time或者151開頭的10位或者13位數字,都是時間戳,用time.time()獲取就可以,但是這里是servertime,我們應該引起注意。
參數分析
下面我們一一來看這幾個參數怎么獲取
Base64是一種基于64個可打印字符來表示二進制數據的方法,哪64個字符呢? A-Z、a-z、0-9和"+"、"/",很多時候base64加密的字符串尾部為 1個或2個 "=", 因為它是把3個字節的二進制拼接,如果最后剩下一個,那么尾部就會添加2個=, 如果剩下兩個,尾部就添加1個=,如果剛合適那當然就沒有=了
推薦一個工具網站https://tool.lu/encdec/
image.png
使用編解碼試試看,最終我發現是賬號,而且是采用了url encode和base64編碼,所有最終我們的su就是
image.png
執行登錄請求
登錄請求的所有參數都已經分析完了,登錄后查看response數據
image.png
然后再看一下登錄請求的下一個請求,發現是通過登錄請求的返回值中的url,然后發送此請求
image.png
返回值中又出現了另外一個url,我們在下面也找到了,提取url發送請求
image.png
看到返回狀態了嗎?302重定向。發送請求以后查看一下response的url,發現是在它下面的請求地址
返回值和下面的請求好像有點關聯,有下一個請求的參數。別急,先等等,我們就這樣一直請求、提取請求、再請求,得有個終點吧,到哪里算一站呢。我們想想登錄以后,顯示一個頁面有用戶名。我們只要能得到這個用戶名那就說明登錄成功了。
image.png
這里看到了這個home請求中出現了我的用戶昵稱,然后上面那個請求的返回狀態302,又是重定向。使用上面的方式確認一下。提取userdomain,然后拼接https://weibo.com/
image.png
成功了
*請認真填寫需求信息,我們會在24小時內與您取得聯系。