整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
譯 ｜ 核子可樂、Tina
技術和軟件開發領域存在一種有趣的現象，就是同樣的模式迭起興衰、周而復始。
過去Web非常簡單。URL 指向服務器，服務器將數據混合成 html，然后在瀏覽器上呈現該響應。圍繞這種簡單范式，誕生了各種Javascript框架，以前可能需要數月時間完成的一個應用程序基本功能，現在借助這些框架創建相對復雜的項目卻只需要數小時，我們節省了很多時間，從而可以將更多精力花在業務邏輯和應用程序設計上。
但隨著 Web 不斷地發展，Javascript 失控了。不知何故，我們決定向用戶拋出大量 App，并在使用時發出不斷增加的網絡請求；不知何故，為了生成 html，我們必須使用 JSON，發出數十個網絡請求，丟棄我們在這些請求中獲得的大部分數據，用一個越來越不透明的 JavaScript 框架黑匣子將 JSON 轉換為 html，然后將新的 html 修補到 DOM 中......
難道大家快忘記了我們可以在服務器上渲染 html 嗎？更快、更一致、更接近應用程序的實際狀態，并且不會向用戶設備發送任何不必要的數據？但是如果沒有 Javascript，我們必須在每次操作時重新加載頁面。
現在，有一個新的庫出現了，摒棄了定制化的方法，這就是 htmx。作為 Web 開發未來理念的一種實現，它的原理很簡單：
htmx 出現在 2020 年，創建者 Carson Gross 說 htmx 來源自他于 2013 年研究的一個項目 intercooler.js。2020 年，他重寫了不依賴 jQuery 的 intercooler.js，并將其重命名為 htmx。然后他驚訝的發現 Django 社區迅速并戲劇性地接受了它！
圖片來源：https://lp.jetbrains.com/django-developer-survey-2021-486/
Carson Gross 認為 htmx 設法抓住了開發者對現有 Javascript 框架不滿的浪潮，“這些框架非常復雜，并且經常將 Django 變成一個愚蠢的 JSON 生產者”，而 htmx 與開箱即用的 Django 配合得更好，因為它通過 html 與服務器交互，而 Django 非常擅長生成 html。
對于 htmx 的迅速走紅，Carson Gross 發出了一聲感嘆：這真是“十年窗下無人問，一舉成名天下知（this is another example of a decade-long overnight success）”。
可以肯定的一點是 htmx 絕對能用，單從理論上講，這個方法確實值得稱道。但軟件問題終究要歸結于實踐效果：效果好嗎，能不能給前端開發帶來改善？
在 DjangoCon 2022 上，Contexte 的 David Guillot 演示了他們在真實 SaaS 產品上實現了從 React 到 htmx 的遷移，而且效果非常好，堪稱“一切 htmx 演示之母”（視頻地址：https://www.youtube.com/watch?v=3GObi93tjZI）。
Contexte 的項目開始于 2017 年，其后端相當復雜，前端 UI 也非常豐富，但團隊非常小。所以他們在一開始的時候跟隨潮流選擇了 React 來“構建 API 綁定 SPA、實現客戶端狀態管理、前后端狀態分離”等。但實際應用中，因為 API 設計不當，DOM 樹太深，又需要加載很多信息，導致 UI“非常非常緩慢”。在敏捷開發的要求下，團隊里唯一的 Javascript 專家對項目的復雜性表現得一無所措，因此他們決定試試 htmx。
于是我們決定大膽嘗試，花幾個月時間用簡單的 Django 模板和 htmx 替換掉了 SaaS 產品中已經使用兩年的 React UI。這里我們分享了一些相關經驗，公布各項具體指標，希望能幫同樣關注 htmx 的朋友們找到說服 CTO 的理由！
6. 將 Web 構建時間縮短了 88%（由 40 秒縮短至 5 秒）
7. 首次加載交互時間縮短了 50% 至 60%（由 2 到 6 秒，縮短至 1 到 2 秒）
8. 使用 htmx 時可以配合更大的數據集，超越 React 的處理極限
9. Web 應用程序的內存使用量減少了 46%（由 75 MB 降低至 40 MB）
這些數字令人頗為意外，也反映出 Contexte 應用程序高度契合超媒體的這一客觀結果：這是一款以內容為中心的應用程序，用于顯示大量文本和圖像。很明顯，其他 Web 應用程序在遷移之后恐怕很難有同樣夸張的提升幅度。
但一些開發者仍然相信，大部分應用程序在采用超媒體 /htmx 方法之后，肯定也迎來顯著的改善，至少在部分系統中大受裨益。
可能很多朋友沒有注意，移植本身對團隊結構也有直接影響。在 Contexte 使用 React 的時候，后端與前端之間存在硬性割裂，其中兩位開發者全職管理后端，一位開發者單純管理前端，另有一名開發者負責“全棧”。（這里的「全棧」，代表這位開發者能夠輕松接手前端和后端工作，因此能夠在整個「棧」上獨立開發功能。）
而在移植至 htmx 之后，整個團隊全都成了“全棧”開發人員。于是每位團隊成員都更高效，能夠貢獻出更多價值。這也讓開發變得更有樂趣，因為開發人員自己就能掌握完整功能。最后，轉向 htmx 也讓軟件優化度上了一個臺階，現在開發人員可以在棧內的任意位置進行優化，無需與其他開發者提前協調。
如今，單頁應用（SPA）可謂風靡一時：配合 React、Redux 或 Angular 等庫的 JS 或 TS 密集型前端，已經成為創建 Web 應用程序的主流方式。以一個需要轉譯成 JS 的 SPA 應用為例：
但 htmx 風潮已經襲來，人們開始強調一種“傻瓜客戶端”方法，即由服務器生成 html 本體并發送至客戶端，意味著 UI 事件會被發送至服務器進行處理。
用這個例子進行前后對比，我們就會看到前者涉及的活動部件更多。從客戶端角度出發，后者其實回避了定制化客戶端技術，采取更簡單的方法將原本只作為數據引擎的服務器變成了視圖引擎。
后一種方法被稱為 AJAX（異步 JavaScript 與 XML）。這種簡單思路能夠讓 Web 應用程序獲得更高的響應性體驗，同時消除了糟糕的“回發”（postback，即網頁完全刷新），由此回避了極其低效的“viewstate”等.NET 技術。
htmx 在很多方面都體現出對 AJAX 思路的回歸，最大的區別就是它僅僅作為新的聲明性 html 屬性出現，負責指示觸發條件是什么、要發布到哪個端點等。
另一個得到簡化的元素是物理應用程序的結構與構建管道。因為不再涉及手工編寫 JS，而且整個應用程序都基于服務器，因此不再對 JS 壓縮器、捆綁器和轉譯器做（即時）要求。就連客戶端項目也能解放出來，一切都由 Web 服務器項目負責完成，所有應用程序代碼都在.NET 之上運行。從這個角度來看，這與高度依賴服務器的 Blazor Server 編程模型倒是頗有異曲同工之妙。
技術和軟件開發領域存在一種有趣的現象，就是同樣的模式迭起興衰、周而復始。隨著 SPA 的興起，人們一度以為 AJAX 已經過氣了，但其基本思路如今正卷土重來。這其中當然會有不同的權衡，例如更高的服務器負載和網絡流量（畢竟現在我們發送的是數據視圖，而不只是數據），但能讓開發者多個選擇肯定不是壞事。
雖然不敢確定這種趨勢是否適用于包含豐富用戶體驗的高復雜度應用程序，但毫無疑問，相當一部分 Web 應用程序并不需要完整的 SPA 結構。對于這類用例，簡單的 htmx 應用程序可能就是最好的解決方案。
參考鏈接：
https://news.ycombinator.com/item?id=33218439
https://www.reddit.com/r/django/comments/rxjlc6/htmx_gaining_popularity_rapidly/
https://mekhami.github.io/2021/03/26/htmx-the-future-of-web/
https://www.compositional-it.com/news-blog/more-on-htmx-back-to-the-future/
聲明：本文為InfoQ編譯，未經許可禁止轉載。
長不看版：Snowpack v3.0 將于 2021 年 1 月 6 日發布（也是該版本最初公布的一周年紀念日）。這是我們最重大的一次版本更新，其中有一些重要的新特性，包括一種按需加載 npm 導入的新方法，可以完全跳過前端的 npm install 步驟。
激動人心的是，大家現在就可以開始試用新版了！
Snowpack v3 的重點是完善和正式發布四項已有特性，這些特性在當前版本的 Snowpack（v2.18.0）中通過 experiments 標志提供：
Snowpack 一直在努力探索前端開發的邊界，這個版本也是如此。Snowpack v3.0 引入了一項令人興奮的新特性，可加快并簡化你的開發工作流程。
一般來說，JavaScript 依賴項是由包管理器 CLI（如 npm、yarn 或 pnpm）在本地安裝和管理的。程序包經常帶有不相關的文件，并且幾乎沒有哪個包能直接在瀏覽器中運行。我們需要額外的步驟來處理、構建和打包這些安裝進來的軟件包，才能讓它們運行在瀏覽器中。
我們可以簡化這一過程嗎？如果 Snowpack 可以完全跳過“npm install”步驟，并通過 ESM 按需獲取我們需要的，預構建的包代碼，這是不是非常令人期待？
// you do this:
import * as React from 'react';
// but get behavior like this:
import * as React from 'https://cdn.skypack.dev/react@17.0.1';
上例中的 URL 指向 Skypack，這是一種流行的 JavaScript CDN，我們通過它將所有 npm 包當作 ESM 處理。Snowpack、Deno 和所有主要瀏覽器都能很好地支持通過 URL 導入依賴項。但是，將這些 URL 直接寫入源代碼的方法并不好用，并且如果沒有網絡連接就無法開發了。
Snowpack v3.0 融合了兩個方面的優勢：在你自己的源代碼中獲得 import 'react'的簡單性，并讓 Snowpack 在后臺獲取這些依賴項，這些依賴項已預構建完畢并可以在瀏覽器中運行。Snowpack 會自動為你緩存所有內容，因此你可以脫機工作，而無需依賴 Skypack。
與傳統的“npm install”方法相比，這種機制有很多優點：
如果這一切聽起來太不可思議了，請放心。想要使用它的話，這是 100％ opt-in 的行為。默認情況下，Snowpack 會像往常一樣繼續將 npm 包依賴項從項目 node_modules 目錄中拉出來。
請查閱我們的流式NPM導入指南，了解如何在已有的項目中啟用這一新行為。在將來的發行版中，我們希望對定制的 ESM 軟件包源和其他 CDN 開放此特性。
esbuild 太令人震驚了：它的性能比大多數流行的打包器快 100 倍，比 Parcel 快 300 倍（根據 esbuild 自己的基準測試）。esbuild 用 Go 編寫，而 Go 是一種編譯語言，可以并行化繁重的打包任務負載，而其他流行的打包程序（用 JavaScript 編寫）是做不到的。
Snowpack 已在內部使用 esbuild，作為我們 JavaScript、TypeScript 和 JSX 文件的默認單文件構建器。Snowpack v3.0 更進一步，加入了新的內置構建優化管道。為生產環境打包、縮小和轉譯你的站點時，它需要的時間只有其他打包器的 1/100。
今天 Snowpack 之所以可以采用采用 esbuild，是因為我們很早就對打包的未來投下了賭注：打包是一種構建后的優化步驟，而不是承載其他一切內容的核心基礎。由于早期的這一設計決策，esbuild 可以像其他打包器一樣輕松地插入和換出你的 Snowpack 構建。
esbuild 仍算是一個年輕的項目，但它的未來看起來很有希望。同時，我們還將在很長的一段時間內繼續投資現有的 Webpack & Rollup 打包插件。
請查看我們最新的《優化Snowpack構建指南》中的 experiments.optimize 選項來開始嘗試。
Snowpack 新加入的 experiments.routes 配置使你可以定義讓開發環境與生產保持一致的路由。這一特性解鎖了一些有趣的新用例，包括：
Snowpack 已經支持 API 代理和 SPA 回退有一段時間了，而這一新特性會將它們組合在一起，成為一個單一的、富有表現力的新 API。
Snowpack 的全新 JavaScriptAPI 可讓你對 Snowpack 的開發服務器和構建管道進行更高級別的控制，從而幫助你在 Snowpack 上構建更強大的集成，以解鎖新的開發工具和服務端渲染（SSR）解決方案。
Svelte 團隊最近發布的 SvelteKit 引發了關注：這是 Svelte 應用的官方 zero-effort SSR 應用框架。SvelteKit 由 Snowpack 提供內部支持，使用了我們全新的 JavaScript API 來管理你的構建管道并按需構建文件。Snowpack 加快了開發速度，并幫助將 SvelteKit 的啟動時間減少到了幾乎可以忽略不計。
請查看我們新的JavaScript API參考，開始在 Snowpack 上構建你自己的自定義集成。或者通讀我們關于服務端渲染的指南，開始使用用于生產的自定義 SSR 集成。
你可以通過以下命令安裝 Snowpack v3.0 RC 版本：
npm install snowpack@next由于所有 v3.0 特性在現在的版本中都包括了，因此我們現有的文檔站點同時適用于 v2 和 v3。目前，只有非常舊的，沒有文檔支持的舊行為在 next 分支中移除了。隨著我們接近正式發布日期，實驗標志下的特性可能會繼續更改。到今年年底，這些特性將從實驗標志后移到下一個 v3.0 分支的頂級配置對象中。
請在 snowpack.dev 上了解更多信息。
原文鏈接：
Snowpack 3 Release
https://www.snowpack.dev/posts/2020-12-03-snowpack-3-release-candidate?utm_source=tinyjs&utm_medium=email
微軟發布.NET 5.0 RC1，未來將只有一個.NET-InfoQ
關注我并轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書，點擊文末「了解更多」，即可移步InfoQ官網，獲取最新資訊～
eb前端技術由html、css和 javascript三大部分構成，是一個龐大而復雜的技術體系，其復雜程度不低于任何一門后端語言。而我們在學習它的時候往往是先從某一個點切入，然后不斷地接觸和學習新的知識點，因此對于初學者很難理清楚整個體系的脈絡結構。本文將對Web前端知識體系進行簡單的梳理，對應的每個知識點點到為止，不作詳細介紹。目的是幫助大家審查自己的知識結構是否完善，如有遺漏或不正確的地方，希望共勉。
HTML 篇
1、BOM
BOM 是 Browser Object Model
的縮寫，即瀏覽器對象模型，當一個瀏覽器頁面初始化時，會在內存創建一個全局的對象，用以描述當前窗口的屬性和狀態，這個全局對象被稱為瀏覽器對象模型，即BOM。BOM的核心對象就是window，window
對象也是BOM的頂級對象，其中包含了瀏覽器的 6個核心模塊：
document -
即文檔對象，渲染引擎在解析HTML代碼時，會為每一個元素生成對應的DOM對象，由于元素之間有層級關系，因此整個HTML代碼解析完以后，會生成一個由不同節點組成的樹形結構，俗稱DOM樹，document
用于描述DOM樹的狀態和屬性，并提供了很多操作DOM的API。
frames - HTML 子框架，即在瀏覽器里嵌入另一個窗口，父框架和子框架擁有獨立的作用域和上下文。
history - 以棧(FIFO)的形式保存著頁面被訪問的歷史記錄，頁面前進即入棧，頁面返回即出棧。
location - 提供了當前窗口中加載的文檔相關信息以及一些導航功能。
navigator - 用來描述瀏覽器本身，包括瀏覽器的名稱、版本、語言、系統平臺、用戶特性字符串等信息。
screen - 提供了瀏覽器顯示屏幕的相關屬性，比如顯示屏幕的寬度和高度，可用寬度和高度。
2、DOM 系統
DOM 是 Document Object Model 的縮寫，即 文檔對象模型，是所有瀏覽器公共遵守的標準，DOM
將HTML和XML文檔映射成一個由不同節點組成的樹型結構，俗稱DOM樹。其核心對象是document，用于描述DOM樹的狀態和屬性，并提供對應的DOM操作API。隨著歷史的發展，DOM
被劃分為1級、2級、3級，共3個級別：
1級DOM - 在1998年10月份成為W3C的提議，由DOM核心與DOM
HTML兩個模塊組成。DOM核心能映射以XML為基礎的文檔結構，允許獲取和操作文檔的任意部分。DOM
HTML通過添加HTML專用的對象與函數對DOM核心進行了擴展。
2級DOM - 鑒于1級DOM僅以映射文檔結構為目標，DOM
2級面向更為寬廣。通過對原有DOM的擴展，2級DOM通過對象接口增加了對鼠標和用戶界面事件（DHTML長期支持鼠標與用戶界面事件）、范圍、遍歷（重復執行DOM文檔）和層疊樣式表（CSS）的支持。同時也對DOM
1的核心進行了擴展，從而可支持XML命名空間。
3級DOM -
通過引入統一方式載入和保存文檔和文檔驗證方法對DOM進行進一步擴展，DOM3包含一個名為“DOM載入與保存”的新模塊，DOM核心擴展后可支持XML1.0的所有內容，包括XML
Infoset、 XPath、和XML Base。
瀏覽器對不同級別DOM的支持情況如下所示：
從圖中可以看出，移動端常用的 webkit 內核瀏覽器目前只支持DOM2，而不支持DOM3 。
新手福利獲取方式：
1.在你手機的右上角有【關注】選項，或點擊我的頭像，點擊關注！（關注我）
2.關注后，手機客戶端點擊我的主頁面，右上角有私信，請私信發我：html
其實作為一個開發者，有一個學習的氛圍跟一個交流圈子特別重要這里請私信我“html”不管你是小白還是大牛歡迎入住大家一起交流成長。小編會在里面不定期分享干貨源碼，包括我精心整理的一份零基礎教程。歡迎各位感興趣的的小伙伴。
學習思路：
3、事件系統
事件是用戶與頁面交互的基礎，到目前為止，DOM事件從PC端的 鼠標事件(mouse) 發展到了 移動端的 觸摸事件(touch) 和
手勢事件(guesture)，touch事件描述了手指在屏幕操作的每一個細節，guesture 則是描述多手指操作時更為復雜的情況，總結如下：
第一根手指放下，觸發 touchstart，除此之外什么都不會發生
手指滑動時，觸發touchmove
第二根手指放下，觸發 gesturestart
觸發第二根手指的 touchstart
立即觸發 gesturechange
任意手指移動，持續觸發 gesturechange
第二根手指彈起時，觸發 gestureend，以后將不會再觸發 gesturechange
觸發第二根手指的 touchend
觸發touchstart (多根手指在屏幕上，提起一根，會刷新一次全局touch) _ ___
彈起第一根手指，觸發 touchend
更多關于手勢事件的介紹請參考：
gesture事件處理復雜手勢
DOM2.0 模型將事件處理流程分為三個階段，即 事件捕獲階段 、 事件處理階段 、 事件冒泡階段， 如圖所示：
事件捕獲 ：當用戶觸發點擊事件后，頂層對象document 就會發出一個事件流，從最外層的DOM節點向目標元素節點傳遞，最終到達目標元素。
事件處理 ：當到達目標元素之后，執行目標元素綁定的處理函數。如果沒有綁定監聽函數，則不做任何處理。
事件冒泡 ：事件流從目標元素開始，向最外層DOM節點傳遞，途中如果有節點綁定了事件處理函數，這些函數就會被執行。
利用事件冒泡原理可以實現 事件委托
，所謂事件委托，就是在父元素上添加事件監聽器，用以監聽和處理子元素的事件，避免重復為子元素綁定相同的事件。當目標元素的事件被觸發以后，這個事件就從目標元素開始，向最外層元素傳遞，最終冒泡到父元素上，父元素再通過event.target
獲取到這個目標元素，這樣做的好處是，父元素只需綁定一個事件監聽，就可以對所有子元素的事件進行處理了，從而減少了不必要的事件綁定，對頁面性能有一定的提升。
4、HTML解析過程
瀏覽器加載 html 文件以后，渲染引擎會從上往下，一步步來解析HTML標簽，大致過程如下：
用戶輸入網址，瀏覽器向服務器發出請求，服務器返回html文件；
渲染引擎開始解析 html 標簽，并將標簽轉化為DOM節點，生成 DOM樹；
如果head 標簽中引用了外部css文件，則發出css文件請求，服務器返回該文件，該過程會阻塞后面的解析；
如果引用了外部 js 文件，則發出 js 文件請求，服務器返回后立即執行該腳本，這個過程也會阻塞html的解析；
引擎開始解析 body 里面的內容，如果標簽里引用了css 樣式，就需要解析剛才下載好的css文件，然后用css來設置標簽的樣式屬性，并生成渲染樹；
如果 body 中的 img 標簽引用了圖片資源，則立即向服務器發出請求，此時引擎不會等待圖片下載完畢，而是繼續解析后面的標簽；
服務器返回圖片文件，由于圖片需要占用一定的空間，會影響到后面元素的排版，因此引擎需要重新渲染這部分內容；
如果此時 js 腳本中運行了 style.display="none"，布局被改變，引擎也需要重新渲染這部分代碼；
直到 html 結束標簽為止，頁面解析完畢。
5、重繪 和 回流
當渲染樹中的一部分(或全部)因為元素的規模尺寸，布局，隱藏等改變而需要重新構建。這就稱為回流。比如上面的img文件加載完成后就會引起回流，每個頁面至少需要一次回流，就是在頁面第一次加載的時候。
當渲染樹中的一些元素需要更新屬性，而這些屬性只是影響元素的外觀，風格，而不會影響布局的，比如 background-color。則就叫稱為重繪。
從上面可以看出，回流必將引起重繪，而重繪不一定會引起回流。會引起重繪和回流的操作如下：
添加、刪除元素(回流+重繪)
隱藏元素，display:none(回流+重繪)，visibility:hidden(只重繪，不回流)
移動元素，比如改變top,left的值，或者移動元素到另外一個父元素中。(重繪+回流)
對style的操作(對不同的屬性操作，影響不一樣)
還有一種是用戶的操作，比如改變瀏覽器大小，改變瀏覽器的字體大小等(回流+重繪)
另外，transform
操作不會引起重繪和回流，是一種高效率的渲染。這是因為transform屬于合成屬性，對合成屬性進行transition/animation
動畫時將會創建一個合成層，這使得動畫元素在一個獨立的層中進行渲染，當元素的內容沒有發生改變，就沒必要進行重繪，瀏覽器會通過重新復合來創建動畫幀。
6、本地存儲
本地存儲最原始的方式就是 cookie,cookie 是存放在本地瀏覽器的一段文本，數據以鍵值對的形式保存，可以設置過期時間。 但是 cookie
不適合大量數據的存儲，因為每請求一次頁面，cookie 都會發送給服務器，這使得 cookie
速度很慢而且效率也不高。因此cookie的大小被限制為4k左右(不同瀏覽器可能不同,分HOST)，如下所示：
Firefox和Safari允許cookie多達4097個字節，包括名(name)、值(value) 和 等號。
Opera允許cookie多達4096個字節，包括：名(name)、值(value) 和 等號。
Internet Explorer允許cookie多達4095個字節，包括：名(name)、值(value) 和 等號。
在所有瀏覽器中，任何cookie大小超過限制都被忽略，且永遠不會被設置。
html5 提供了兩種在客戶端存儲數據的新方法：localStorage 和 sessionStorage, 它們都是以key/value
的形式來存儲數據，前者是永久存儲，后者的存儲期限僅限于瀏覽器會話(session)，即當瀏覽器窗口關閉后，sessionStorage中的數據被清除。
localStorage的存儲空間大約5M左右(不同瀏覽器可能不同，分
HOST)，這個相當于一個5M大小的前端數據庫，相比于cookie，可以節約帶寬，但localStorage在瀏覽器隱私模式下是不可讀取的，當存儲數據超過了localStorage
的存儲空間后會拋出異常。
此外，H5還提供了逆天的websql和
indexedDB，允許前端以關系型數據庫的方式來存儲本地數據，相對來說，這個功能目前應用的場景比較少，此處不作介紹。
7、瀏覽器緩存機制
瀏覽器緩存機制是指通過 HTTP 協議頭里的 Cache-Control (或 Expires) 和 Last-Modified (或 Etag)
等字段來控制文件緩存的機制。
Cache-Control 用于控制文件在本地緩存有效時長。最常見的，比如服務器回包：Cache-Control:max-age=600
表示文件在本地應該緩存，且有效時長是600秒 (從發出請求算起)。在接下來600秒內，如果有請求這個資源，瀏覽器不會發出 HTTP
請求，而是直接使用本地緩存的文件。
Last-Modified 是標識文件在服務器上的最新更新時間。下次請求時，如果文件緩存過期，瀏覽器通過 If-Modified-Since
字段帶上這個時間，發送給服務器，由服務器比較時間戳來判斷文件是否有修改。如果沒有修改，服務器返回304告訴瀏覽器繼續使用緩存；如果有修改，則返回200，同時返回最新的文件。
Cache-Control 通常與 Last-Modified 一起使用。一個用于控制緩存有效時間，一個在緩存失效后，向服務查詢是否有更新。
Cache-Control 還有一個同功能的字段：Expires。Expires 的值一個絕對的時間點，如：Expires: Thu, 10 Nov
2015 08:45:11 GMT，表示在這個時間點之前，緩存都是有效的。
Expires 是 HTTP1.0 標準中的字段，Cache-Control 是 HTTP1.1
標準中新加的字段，功能一樣，都是控制緩存的有效時間。當這兩個字段同時出現時，Cache-Control 是高優化級的。
Etag 也是和 Last-Modified 一樣，對文件進行標識的字段。不同的是，Etag
的取值是一個對文件進行標識的特征字串。在向服務器查詢文件是否有更新時，瀏覽器通過 If-None-Match
字段把特征字串發送給服務器，由服務器和文件最新特征字串進行匹配，來判斷文件是否有更新。沒有更新回包304，有更新回包200。Etag 和
Last-Modified 可根據需求使用一個或兩個同時使用。兩個同時使用時，只要滿足基中一個條件，就認為文件沒有更新。
另外有兩種特殊的情況：
手動刷新頁面(F5)，瀏覽器會直接認為緩存已經過期(可能緩存還沒有過期)，在請求中加上字段：Cache-Control:max-age=0，發包向服務器查詢是否有文件是否有更新。
強制刷新頁面(Ctrl+F5)，瀏覽器會直接忽略本地的緩存(有緩存也會認為本地沒有緩存)，在請求中加上字段：Cache-Control:no-cache
(或 Pragma:no-cache)，發包向服務重新拉取文件。
8、History
用戶訪問網頁的歷史記錄通常會被保存在一個類似于棧的對象中，即history對象，點擊返回就出棧，跳下一頁就入棧。 它提供了以下方法來操作頁面的前進和后退：
window.history.back( ) 返回到上一個頁面
window.history.forward( ) 進入到下一個頁面
window.history.go( [delta] ) 跳轉到指定頁面
HTML5 對History Api 進行了增強，新增了兩個Api 和一個事件，分別是pushState、replaceState 和
onpopstate：
pushState是往history對象里添加一個新的歷史記錄，即壓棧。
replaceState 是替換history對象中的當前歷史記錄。
當點擊瀏覽器后退按鈕或 js調用history.back 都會觸發 onpopstate 事件。
與其類似的還有一個事件：onhashchange，onhashchange是老API，瀏覽器支持度高，本來是用來監聽hash變化的，但可以被利用來做客戶端前進和后退事件的監聽，而onpopstate是專門用來監聽瀏覽器前進后退的，不僅可以支持hash，非hash的同源
url 也支持。
9、HTML5離線緩存
HTML5離線緩存又叫Application
Cache，是從瀏覽器的緩存中分出來的一塊緩存區，如果要在這個緩存中保存數據，可以使用一個描述文件（manifest file），列出要下載和緩存的資源。
manifest 文件是簡單的文本文件，它告知瀏覽器被緩存的內容（以及不緩存的內容）。manifest 文件可分為三個部分：
- CACHE MANIFEST - 在此標題下列出的文件將在首次下載后進行緩存
- NETWORK - 在此標題下列出的文件需要與服務器的連接，且不會被緩存
- FALLBACK - 在此標題下列出的文件規定當頁面無法訪問時的回退頁面（比如 404 頁面）
離線緩存為應用帶來三個優勢：
離線瀏覽 - 用戶可在應用離線時使用它們
速度 - 已緩存資源加載得更快
減少服務器負載 - 瀏覽器將只從服務器下載更新過或更改過的資源。
10、Web語義化 和 SEO
Web語義化是指使用語義恰當的標簽，使頁面有良好的結構，頁面元素有含義，能夠讓人和搜索引擎都容易理解。
SEO是指在了解搜索引擎自然排名機制的基礎之上，對網站進行內部及外部的調整優化，改進網站在搜索引擎中關鍵詞的自然排名，獲得更多的展現量，吸引更多目標客戶點擊訪問網站，從而達到互聯網營銷及品牌建設的目標。
搜索引擎通過爬蟲技術獲取的頁面就是由一堆 html 標簽組成的代碼，人可以通過可視化的方式來判斷頁面上哪些內容是重點，而機器做不到。
但搜索引擎會根據標簽的含義來判斷內容的權重，因此，在合適的位置使用恰當的標簽，使整個頁面的語義明確，結構清晰，搜索引擎才能正確識別頁面中的重要內容，并予以較高的權值。比如h1~h6這幾個標簽在SEO中的權值非常高，用它們作頁面的標題就是一個簡單的SEO優化。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
