機能アンチシェイク、機能スロットル、ブラウザローカルストレージ、キャッシュメカニズム(インタビューフォーカス!!!)
関数デバウンス(デバウンス)
コンセプト:実行するアクションを遅延させます。遅延期間中に再度トリガーされた場合は、以前に開始したアクションをキャンセルして、タイミングを再開します。
例:コンピュータは1分間操作せずに黒い画面の後でスリープ状態になり、マウスは40代に1回移動して、カウントを再開します。
実装:タイマー
アプリケーション:検索するときは、ユーザーがすべてのコンテンツを入力するのを待ってからクエリを開始してください
<script>
let inputNode = document.getElementById("user_input")
let id
inputNode.addEventListener('keyup',function(){
if(id){
clearTimeout(id);
}
let value = inputNode.value
id = setTimeout(() => {
sendAjax(value)
}, 200); //时间为0.2s~0.3s之间
})
function sendAjax(data){
// console.log('发送了一次ajax请求,内容为'+ data)
console.log(`发送了一次Ajax请求,内容为${
data}`)
}
</script>
機能スロットル(スロットル)
コンセプト:特定の時間を設定して、関数が特定の時間に1回だけ実行され、頻繁に実行されないようにします。
例:銃のゲームでは、マウスを離さずに押したままにすると、弾丸が一列に接続されません。(すぐに自分の周波数を超える)
実装:タイマー、識別
要件:マウスホイールがスクロールしているときは、2秒に1回印刷します
<script>
let canlog = true
document.body.onscroll = function(){
if(canlog){
console.log(1)
canlog = false
setTimeout(() => {
canlog = true
}, 2000)
}
}
</script>
ブラウザのローカルストレージ
Cookie SessionStorage LocalStorageこれら3つは、ブラウザー側でデータを格納するために使用でき、すべて文字列型のキーと値のペアです。
-
セッション
-
sessionStorage:ブラウザがデータを保存するために使用するコンテナ。(フロントエンド)
-
セッションセッションストレージ、サーバー側にデータを保存する方法。(後部)
Webストレージ
SessionStorageとLocalStorageの総称では、コンテンツサイズは通常5〜10MBです。
ブラウザは、Window.SessionStorageプロパティとWindow.LocalStorageプロパティを介してローカルストレージメカニズムを実装します。
関連API:
1。xxxxxStorage.setItem( 'key'、 'value');
このメソッドは、キーの名前と値をパラメーターとして受け入れ、キーと値のペアをストレージに追加します。キー名が存在する場合は、対応する値を更新します。 。
-
var data = xxxxxStorage.getItem( 'person');
このメソッドは、パラメーターとしてキー名を受け入れ、キー名に対応する値を返します。 -
xxxxxStorage.removeItem( 'key');
このメソッドは、パラメーターとしてキー名を受け入れ、ストレージからキー名を削除します。 -
このメソッドを呼び出すxxxxxStorage.clear()は、ストレージ内のすべてのキーをクリアします
注:ブラウザウィンドウを閉じると、SessionStorageに保存されているコンテンツは表示されなくなります。
LocalStorageに保存されているコンテンツは、消える前に手動でクリアする必要があります。
<body>
<button id="btn1">保存数据</button>
<button id="btn2">读取数据</button>
<button id="btn3">删除数据</button>
<button id="btn4">清空数据</button>
<script>
let btn1 = document.getElementById('btn1')
let btn2 = document.getElementById('btn2')
let btn3 = document.getElementById('btn3')
let btn4 = document.getElementById('btn4')
let person = {name:'kebo',age:18}
//保存
btn1.onclick = ()=>{
sessionStorage.setItem('demo',JSON.stringify(person))
}
//读取
btn2.onclick = ()=>{
console.log(JSON.parse(sessionStorage.getItem('demo')))
}
//删除
btn3.onclick = ()=>{
sessionStorage.removeItem('demo')
}
//清空
btn4.onclick = ()=>{
sessionStorage.clear()
}
</script>
</body>
データ同期/ブラウザクロスタブ通信(インタビューフォーカス)
ストレージイベント:
-
Storageオブジェクトが変更されたときにトリガーされます(つまり、データアイテムが作成/更新/削除されたときに、Storage.clear()は1回だけトリガーされます)
-
同じページ内で発生した変更は機能しません
-
同じドメイン名で他のページで発生した変更のみが有効になります。(変更されたページはイベントをトリガーしません。共有されたページはイベントをトリガーします)
key:変更または削除されたキー値
。clear ()が呼び出された場合はnullです。newValue:新しく設定された値(clear()の場合)呼び出されると、nullになります
oldValue:変更前の値を呼び出します。clear()を呼び出すと、nullになります。url:
スクリプトの変更をトリガーしたドキュメントのURL
storageArea:現在のストレージオブジェクト
使用法:
window.addEventListener( ' storage '、function(event){ //特定のビジネスロジックをここに書き込む})数据同步1 <input type="text" id="input"> <script> let input = document.getElementById('input') input.onblur = function(){ localStorage.setItem('data',input.value) } </script> 数据同步2 <input type="text" id="input2"> <script> //得知道它啥时候存进去了 let input2 = document.getElementById('input2') window.addEventListener('storage',function(event){ input2.value = event.newValue // input2.value = localStorage.getItem('data') 也可以写,但是将data写死了 }) </script>
###ブラウザストレージのサポート
http://dev-test.nemikor.com/web-storage/support-test/
ブラウザのキャッシュメカニズム
キャッシュを理解する
-
キャッシュ定義:ブラウザは、ユーザーが以前に要求したデータをローカルディスクに保存します。訪問者がデータを再度変更する必要がある場合、要求を再度送信する必要はなく、データはローカルブラウザから直接取得されます。
-
キャッシュの利点:
- リクエストの数を減らす
- 帯域幅を節約し、不要なネットワークリソースを浪費しないようにします
- サーバーへの圧力を軽減します
- ブラウザのWebページの読み込み速度を改善し、ユーザーエクスペリエンスを改善します
キャッシュ分類
1.強力なキャッシュ
(1)サーバーにリクエストは送信されず、データはローカルストレージから直接取得されます
(2)要求されたリソースのステータスコードは200 ok(メモ/ディスクキャッシュから)キャッシュ(コンピューター高速バッファー)です
2.ネゴシエーションキャッシュ
(1)サーバーにリクエストを送信すると、サーバーはリクエストヘッダーのリソースに応じてネゴシエーションキャッシュにヒットしたかどうかを判断します
(2)ヒットすると、304ステータスコードを返し、キャッシュからリソースを読み取るようにブラウザに通知します。つまり、ネゴシエーションは成功します。
(3)ネゴシエーションに失敗しました:サーバーは必要なホームページなどを返します
3.ストロングキャッシングとネゴシエーションキャッシングの共通点:
ブラウザからリソースを読む
4.違い:
強力なキャッシュはサーバーにリクエストを送信しません
キャッシュをネゴシエートしてサーバーにリクエストを送信し、サーバーから返された情報に従ってキャッシュを使用するかどうかを決定します
強力なキャッシュ
リクエスト:リクエストヘッダー+リクエストで運ばれるデータrequestHeader
応答:応答ヘッダー+ responseHeaderデータをあなたに
強力なキャッシュのヘッダーパラメータ
リクエスト:リクエストヘッダー+リクエストで運ばれるデータrequestHeader
応答:応答ヘッダー+ responseHeaderデータをあなたに
-
有効期限:(応答ヘッダー、強力なキャッシュの有効期限)
-
これはhttp1.0の時点での仕様です。その値は、絶対時間GMT形式の時間文字列です。たとえば
Mon, 10 Jun 2015 21:31:12 GMT
、リクエストの送信時間が期限切れになる前の場合、ローカルキャッシュは常に有効です。それ以外の場合は、サーバーにリクエストして取得するリソース例:たとえば、2020年11月15日に有効期限が切れた場合、ウェブページは2020.11.1に強力にキャッシュされ、2020年11月16日にキャッシュは強力になりません。
-
-
cache-control:max-age = number(強力なキャッシュの作成日)
-
これはhttp1.1に表示されるヘッダー情報です。これは主にこのフィールドのmax-age値によって判断されます。これは相対値であり、リソースの最初の要求時間とCache-Controlによって設定された有効期間が計算されます。 。リソースの有効期限を確認し、この有効期限を現在のリクエスト時間と比較します。リクエスト時間が有効期限より前の場合、キャッシュにヒットする可能性があります。それ以外の場合は機能しません。
ユニットとしての2番目(s)、有効期限が切れてキャッシュ制御が競合する場合は、キャッシュ制御を使用します
-
キャッシュ制御の一般的に使用される値:
1. no-cache: 不使用本地缓存,需要使用协商缓存。先与服务器确认返回的响应是否被更改,如果之前的响应中存在Etag,那么请求的额时候会与服务器端进行验证,如果资源为被更改则使用缓存。 2. no-store: 直接禁止游览器缓存数据,每次用户请求该资源,都会向服务器发送一个请求,每次都会下载完整的资源。 3. public:可以被所有的用户缓存,包括终端用户和CDN等中间代理服务器。 4. private:只能被终端用户的浏览器缓存,不允许CDN等中继缓存服务器对其缓存。 5. <font color=red>注意:当cache-control与Expires共存的时候cache-control的优先级高</font>
-
キャッシュされたヘッダーパラメータをネゴシエートします
重要:サーバーはキャッシュリソースがネゴシエーションに使用できるかどうかを判断するため、クライアントとサーバーは特定の識別子を介して通信する必要があります。これにより、サーバーは要求されたリソースをキャッシュしてアクセスできるかどうかを判断できます。
-
Last-Modified / If-Modified-Since:両方の値はGMT形式の時間文字列です
-
ネゴシエーションキャッシュは最後の変更時刻を返し、次のリクエストは過去のこの時刻を運ぶ必要があります
- ブラウザは、サーバーに初めてリソースを要求します。サーバーがリソースを返すと、レスポンダーのヘッダーにLast-Modifiedヘッダーが追加されます。このヘッダーは、サーバー上のリソースの最終変更時刻を表します。
- ブラウザがサーバーにこのリソースを再度要求するときは、If-Modified-Sinceのヘッダーを要求のヘッダーに追加します。このヘッダーの値は、前の要求で返されたLast-Modifiedの値です。
- サーバーはリソース要求を再度受信すると、ブラウザから渡されたIf-Modified-Sinceとサーバー上のリソースの最終変更時刻に従って、リソースが変更されたかどうかを判断します。変更がない場合は、304を返します。変更されていませんが、リソースの内容は返されません。変更があった場合、リソースの内容は通常どおり返されます。サーバーが304Not Modified応答を返す場合、リソースが変更されていないため、Last-Modifiedヘッダーは応答ヘッダーに追加されません。これは、サーバーが304を返すときの応答ヘッダーです。
- ブラウザは304応答を受信すると、キャッシュからリソースをロードします
- ネゴシエーションキャッシュがヒットしていない場合、ブラウザがサーバーからリソースを直接ロードすると、Last-Modifiedヘッダーはリロード時に更新されます。次のリクエストが行われると、If-Modified-SinceはLast-Modifiedを有効にします。前回返された値
- 伝説:
- Etag / If-None-Match
- これらの2つの値は、この値を変更するリソースがある限り、各リソースのサーバー固有の識別文字列によって生成されます。
- 判断プロセスは、Last-Modified / If-Modified-Sinceに似ています。
- 既存の最後に変更されたHeSheng Etag
- HTTP1.1でのEtagの出現は、主に、Last-Modifiedでは解決が難しいいくつかの問題を解決することです。
- 一部のファイルは定期的に変更される場合がありますが、その内容は変更されません(変更時のみ)。現時点では、ファイルが変更されたとクライアントに認識させて再GETすることは望ましくありません。
- 一部のファイルは非常に頻繁に変更されます。たとえば、1秒未満の変更(たとえば、1秒でN回)、If-Modified-Sinceがチェックできる粒度はsレベルであり、この変更は判断できません(またはUNIXレコードのMTIMEは、秒単位でしか正確にできないと述べました。
- 一部のサーバーは、ファイルの最終変更時刻を正確に取得できません。
- 概要:
-
Etagは、サーバーによって自動的に生成された、または開発者によって生成された対応するリソースのサーバー側の一意の識別子であるため、Etagを使用するとキャッシュをより正確に制御できます。
-
Last-ModifiedとETagは一緒に使用できます。サーバーは最初にETagを検証します。それらが一貫している場合は、Last-Modifiedを比較し続け、最後に304を返すかどうかを決定します。
-
[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします(img-5wmoNlx9-1605323253709)(F:\ WEB \ WEB \ 009-git、 svn、モジュール化、最適化\ 009-git、svn、モジュール化、最適化\パフォーマンスoptimization_stu \ courseware&summary \ 07_cachingdiagram.png)]
[外部リンク画像の転送に失敗しました。元のサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします(img-miEJWrAh-1605323253712)(F:\ WEB \ WEB \ 009-git、svn 、モジュール化、最適化\ 009 -git、svn、モジュール化、最適化\パフォーマンスoptimization_stu \ illustration \ 02_browserレンダリングprocess.png)]
CSSインタビューテストサイト
1.フロートをクリアします
2.要素を非表示にする(メソッド)
3.聖杯、ダブル
4.cssプリコンパイラレススタイラス