# 2022 Web Almanac 報告簡錄

### 這份報告在做什麼
這是一份關於網絡狀態的綜合報告，由真實數據和值得信賴的網絡專家提供支持，所有值得感謝的研究人員都來自這份[列表](https://almanac.httparchive.org/en/2022/contributors)

### 他怎麼收集資料的
Web Almanac 所有 23 個章節中的指標均來自 HTTP 存檔數據集。

HTTP Archive 是一個社區運行的項目，自 2010 年以來一直在跟踪 Web 的構建方式。

使用 WebPageTest 和 Lighthouse 在後台，每月對近 840 萬個網站的元數據進行測試，並將其包含在公共 BigQuery 數據庫中進行分析。

可以透過[這裡](https://almanac.httparchive.org/en/2022/methodology) 更詳細的知道他們是如何搜集資料的。

## Part I. - 網頁內容（ Page Content ）

### CSS

過去幾年間總是可是可以看到新的 css feature 推陳出新，其中有不少都啟發於開發者已經在 javascript 上所做的關於 css 的補強。

但有新的 feature 是一回事，有沒有被廣泛地使用才是我們需要討論的。

#### css 檔案大小

> 這裡有提及一件有趣的事，相比起去年，今年收集的資料中，最大的一筆 css 大小是 mobile 的 78,543 KB，這相比其去年的最大的 mobile css 大小 17,823 KB 顯然大上不少

#### stylesheets 每頁數量

#### 最常使用的 class name

1. activate
2. fa : font-awesome 相關（ icon）
3. fa-* : font-awesome 相關（ icon）
4. wp-* : wordpress 相關 style
5. button

除了命名常用的 activate、button、btn、emoji、tittle、hidden 等語意化命名以外，font-awesome 的 icon 統治力在 frontend 依然不減。

除此之外 wordpress 也是獲得廣泛使用，除了 wp-* 以外，還有 `has-large-font-size` 等相關 wordpress 語意化 style 逐漸展露頭角

#### 最常見 ID

1. content
2. footer
3. header
4. fb-root : Facebook widgets( [導流相關的設計](https://elfsight.com/facebook-feed-widget/) )
5. fb-*… : Facebook widgets

### JavaScript

#### 每頁 JavaScript 大小
90% 的人每頁讀取最多 1367 byte 的 js

而這其中 90% 的人沒有被用到最多將近一半大小（645）的 js

#### 每頁會請求多少 request
90% 的人每頁最多會有 63 個 request

#### 如何處理 JavaScript

**Bundles**

雖然說現代有很多 bundler 不斷出現，也有不少譬如 [Vite](https://vitejs.dev/) 和 [TurboPack](https://turbo.build/) 等有力競爭者，但大多數人聽到 Bundler 通常還是會想到 `Webpack` ，畢竟這是最被廣泛使用的 bundler。

- using Webpack
在前 1000 個最受歡迎的網站中 有 17 % 使用 webpack，總體來說，使用 webpack bundler 網站的數量佔比是 5%。

- using Parcel
在最受歡迎的 1000 個網站中，有 1.3％ 的網站使用 Parcel，以總體來說，這個數字也是 1.3%。

**transpilers**

在最受歡迎的 1000 個網站中，其中有 40% 使用 babel，這個數字在總體來說佔 26%

#### Libraries and frameworks

在 **所有的** 套件和框架中就算是在今年，還是有高達 %81 的網站在使用 `jquery` 或是 `core-js`、`lodash` 等耳熟能詳的古早味套件。

報告中說明，之所以 `jquery` 還能佔據如此之高的使用率，其原因是 35%的網站使用 WordPress，但即便如此，大部分 jQuery 的使用還是發生在 WordPress 平台之外。
> 雖然如此，[但大部分的 jquery 功能，還是能靠原生的 web api 達成](https://youmightnotneedjquery.com/)

`cort-js` 是因為許多網站還是在使用 Babel，而其通常使用 core-js 來填補跨瀏覽器 API 中缺失的空白
> 隨著瀏覽器的成熟，這個數字應該會下降，這是一件好事，可以大大降低 JavaScript 檔案的大小

就算是獨佔 JS Framework 鰲頭好幾年的 React，以整體網站的佔比來說，也只有 8% 的網站在使用他，這也可算是近期框架大爆發的影響。

> 套件常見組合

#### 安全隱憂

在這個極度依賴套件開發的現代，根據統計至少有 57% 的網站可能會因為套件有安全隱憂
> 臨場加映： [faker.js / color.js 作者發瘋事件](https://zhuanlan.zhihu.com/p/457019632)

### WebAssembly
WebAssembly（或 Wasm）是 Web 技術（JavaScript、HTML、CSS）近期加入的新成員，於 2019 年 12 月成為官方認可的 W3C 標準。

WebAssembly 可以使用各種語言編寫（C++、Rust、Go 等），為網頁運算加速，更可以讓開發人員可以使用更廣泛的工具鏈 / 或是移植舊有的程式碼來撰寫網頁。

其中最知名的例子就是 [Google earth](https://www.google.com/intl/zh-TW/earth/)、[Figma](https://www.figma.com/)、[PhotoShop](https://web.dev/ps-on-the-web/) 等等

#### wasm 使用量

> WASM 作為二進位編碼的 code，跟 JavaScript 不是跑在同一個 thread，也就是說 -- 他們彼此之間會使用像是 call api 的方式溝通彼此。

WebAssembly 通常用於非常特定的功能，大部分較小的 wasm 都作用為填充瀏覽器功能或簡單的加密任務。

這些在後面的 library 項會看到相對應的統計


很大一部分 wasm 請求是跨域的，進一步強化了它們被重用的概念。值得注意的是，這比去年顯著增加（67.2% vs 55.2% (2021) ）。

#### [WASM 都使用在?](https://almanac.httparchive.org/en/2022/webassembly)
- Amazon IVS (Amazon Interactive Video Service) - 影片編輯解碼
- Hyphenopoly - 提供算法核心演算
- Blazor - Microsoft Blazor 是一個平台（運行時和 UI 庫），支持使用 .NET 平台和 C# 開發 Web 應用程序。

### Media

根據 2021 / 06 的統計資料顯示，一個 mobile 網站的平均大小為 2,019 KB，其中有 881 KB 是影音相關，這比 HTML(30KB) CSS(72KB) JavaScript(461KB) 和 字型 (97KB) 加起來都還要大。


基本上可以說，全部的網站都有圖片，而其中的格式佔比為：

而這部分格式的成長率個別為：

可以很明顯的看到 `avif` 這個格式正以誇張的速度成長中，相信不久後就會有一代新的格式換代。

## Part II. 使用者體驗 （ User Experience ）

### Security
想到資安，最一開始想到的一定是網站的資料傳輸方式，但萬幸的是：

有 94% 的 request 使用 HTTPS 加密

除了有無加密以外，更重要的部分是他使用什麼版本的[加密協定](https://zh.m.wikipedia.org/zh-tw/%E5%82%B3%E8%BC%B8%E5%B1%A4%E5%AE%89%E5%85%A8%E6%80%A7%E5%8D%94%E5%AE%9A)，但令人放心的是，絕大多數的人都使用目前最新的 TSL 1.3

### PWA
PWA 是近期廣泛被討論與使用的技術鏈。

他能夠透過諸如 service-worker 或其他技術的結合，**讓網頁能夠像 APP 一樣運作**
> 有興趣的人可以參考我之前做的[筆記](https://superficial-trumpet-b43.notion.site/PWA-Progressive-Web-Apps-13bfc409157b4aa089a5cff023513163)來初淺了解一下。

可以看到在前 1000 名最受歡迎的網頁當中，有 8.7% 開始採用 service worker


## Part III. 架設與發佈網站（ Content Publishing ）

### JAMstack
要討論 JAM stack 之前，就需要先定義什麼是 JAM stack ，這是一件複雜又有趣的事情，我們可以先從 [jamstack.org](https://jamstack.org/) 分別在 2020、2021、2022 所提出的定義開始討論

- 2020 - 透過預先渲染和 CDN 提供快速且安全的服務，無需管理或運行 server
- 2021 - 在開發者喜歡的工具和工具鏈上創建更快、更安全、更容易擴展的架構
- 2022 - 是一種架構方法，將畫面（UX 的部分）和數據、商業邏輯完全拆分，提高靈活性、可擴展性、性能和可維護性。

我們可以從 “官方” 的話中找出一些特點：JAM stack 應該使網站快速，它們應該是pre render，並且是一種架構方法

所以雖說他很難謹慎的定義，但在 JAM stack 開發者眼中，還是可以快速明白這是不是一個 JAM stack 網站的 XD

#### 所以每個 static web 都是 JAM stack 嗎
No，JAM Stack 雖然強調可緩存，任何一個使用 CDN 服務的網站都可以達到這點，但這只是 JAM Stack 的一部分
#### JAM 的 J 是指 javaScript 嗎
Yes，在最初的定義是，但不代表建構 JAM stack 的網站都需要使用 JavaScript，在 wasm 成為新的 w3c 成員的現在，任何一個可以驅動網站的語言都可以用來建構 JAM Stack
#### Jam Stack 網站是否必須具有高性能？
快是個很模糊的定義，但身為一個 JAM Stack 網站，你會需要預先存取某部分資料，所以更可以說 **JAM Stack 必須非常快速地呈現其初始內容**

#### JAM stack 成長率

#### JAM Stack 都在使用什麼框架

下圖是 javascript (FrontEnd) 框架的使用率。

而這是 web frameworl (Full Stack) 的框架佔比：

### sustainability
另一個很酷的觀點是關於 **環保**，看看區塊鏈運算被罵那麼兇，那麼網站相比起來如何呢，Web Almanac 根據傳輸量來計算碳排放，實際上是如何呢，就一起來看看吧！

可以看到 90% 的網站所產生的碳排放都在 2.76 g 以下，這應該不算太多XD

而這是根據 CMS 排名出來的 code 組成的碳排放佔比，可以發現最大宗是 JavaScript 和 Images，

- Image 主要是因為大，所以傳輸會消耗更多
- JavaScript 是因為要處理的運算多，所以也會是消耗能源的

#### Request Rank

我們可以得知，要降低碳排放最簡單的方法就是減少 request 傳輸，所以如果將 request 降低至 25 百分位就會是很好的解決辦法

#### Green Host
更快的處理辦法是直接採用使用綠電的主機託管服務，諸如 microsoft、saleforce 等等大型服務商也都逐漸採用相關措施來保護環境

在前 1000 位主要服務商中，有 52% 的佔比已經採用綠電主機來託管他們的服務。

## 結語

以上就是這次 almanac 2022 小弟我的粗淺筆記，我只記錄我有興趣的部分，還有很多更深入的內容在報告中是我沒有讀到/紀錄的，有興趣的大家一定要親自更深入的閱讀，說不定會在數據中看到另外一部分更亮眼的表現XD。

# Reference
https://almanac.httparchive.org/