原文出處：https://dev.to/nikl/json-is-slower-here-are-its-4-faster-alternatives-2g30

介紹

在快節奏的 Web 開發世界中，速度和反應能力是不容妥協的。您的用戶希望即時存取資訊、快速互動和無縫體驗。 JSON 是 JavaScript 物件表示法的縮寫，一直是 Web 開發中資料交換的忠實夥伴，但它會減慢您的應用程式速度嗎？讓我們深入探討 JSON 的世界，探索其潛在瓶頸，並發現更快的替代方案和優化技術，讓您的應用程式像獵豹一樣衝刺。

您可能還想查看本教學：[使用 Golang 建立即時通知系統 - 逐步通知系統設計指南](https://dev.to/nikl/using-golang-to-build -即時通知系統逐步通知系統設計指南-50l7)

什麼是 JSON 以及為什麼您應該關心？

在開始 JSON 優化之旅之前，讓我們先了解 JSON 是什麼以及它為何重要。

JSON 是將應用程式中的資料黏合在一起的黏合劑。它是伺服器和客戶端之間通訊資料的語言，也是資料儲存在資料庫和設定檔中的格式。從本質上講，JSON 在現代 Web 開發中發揮關鍵作用。

了解 JSON 及其細微差別不僅是任何 Web 開發人員的基本技能，而且對於優化應用程式也至關重要。隨著我們深入研究此博客，您將發現為什麼 JSON 在性能方面可以成為一把雙刃劍，以及這些知識如何對您的開發之旅產生重大影響。

JSON 的受歡迎程度以及人們使用它的原因

JSON 在 Web 開發領域的受歡迎程度怎麼強調都不為過。由於以下幾個令人信服的原因，它已成為資料交換的事實上的標準：

1. 人類可讀格式：JSON 使用簡單的、基於文字的結構，開發人員和非開發人員都可以輕鬆閱讀和理解。這種人類可讀的格式增強了協作並簡化了調試。

   // Inefficient
   {
    "customer_name_with_spaces": "John Doe"
   }
   
   // Efficient
   {
    "customerName": "John Doe"
   }

2. 與語言無關：JSON 不依賴任何特定的程式語言。它是一種通用資料格式，幾乎可以由所有現代程式語言解析和生成，因此具有高度通用性。

3. 資料結構一致性：JSON 使用鍵值對、陣列和巢狀物件強制資料結構一致。這種一致性使其在各種程式設計場景中都可預測且易於使用。

   // Inefficient
   {
    "order": {
      "items": {
        "item1": "Product A",
        "item2": "Product B"
      }
    }
   }
   
   // Efficient
   {
    "orderItems": ["Product A", "Product B"]
   }

4. 瀏覽器支援：Web 瀏覽器原生支援 JSON，允許 Web 應用程式與伺服器無縫通訊。這種原生支援對其在 Web 開發中的採用做出了重大貢獻。

5. JSON API：許多Web服務和API預設提供JSON格式的資料。這進一步鞏固了 JSON 作為 Web 開發中資料交換首選的角色。

6. JSON Schema：開發人員可以使用 JSON Schema 來定義和驗證 JSON 資料的結構，為其應用程式添加額外的清晰度和可靠性。

有鑑於這些優勢，全球開發人員依賴 JSON 來滿足資料交換需求也就不足為奇了。然而，當我們更深入地探索部落格時，我們將發現與 JSON 相關的潛在性能挑戰以及如何有效解決這些挑戰。

對速度的極品

在當今快節奏的數位環境中，應用程式速度和回應能力是不容談判的。用戶期望跨網路和行動應用程式即時存取資訊、快速互動以及無縫體驗。這種對速度的需求是由以下幾個因素所驅動的：

用戶期望

使用者已經習慣了數位互動中閃電般的快速回應。他們不想等待網頁加載或應用程式回應。即使是幾秒鐘的延遲也會導致沮喪和放棄。

競爭優勢

速度可以成為顯著的競爭優勢。快速回應的應用程式往往比反應遲緩的應用程式更有效地吸引和留住用戶。

搜尋引擎排名

像 Google 這樣的搜尋引擎將頁面速度視為排名因素。載入速度更快的網站往往在搜尋結果中排名更高，從而提高可見度和流量。

轉換率

尤其是電子商務網站，他們敏銳地意識到速度對轉換率的影響。更快的網站可以帶來更高的轉換率，從而增加收入。

移動效能

隨著行動裝置的普及，對速度的需求變得更加重要。行動用戶的頻寬和處理能力通常有限，因此需要快速的應用程式效能。

JSON 會減慢我們的應用程式速度嗎？

現在，讓我們解決核心問題：JSON 是否會減慢我們的應用程式速度？

如同前面提到的，JSON 是一種非常流行的資料交換格式。它靈活、易於使用且廣受支援。然而，這種廣泛的採用並不能使其免受性能挑戰。

在某些情況下，JSON 可能是降低應用程式速度的罪魁禍首。解析 JSON 資料的過程，尤其是在處理大型或複雜結構時，可能會消耗寶貴的毫秒時間。此外，低效率的序列化和反序列化可能會影響應用程式的整體效能。

解析開銷

當 JSON 資料到達您的應用程式時，它必須經過解析過程才能將其轉換為可用的資料結構。解析可能相對較慢，尤其是在處理大量或深層巢狀的 JSON 資料時。

// JavaScript example using JSON.parse for parsing
const jsonData = '{"key": "value"}';
const parsedData = JSON.parse(jsonData);

序列化與反序列化

JSON 要求資料從用戶端傳送到伺服器時進行序列化（將物件編碼為字串），並在接收時進行反序列化（將字串轉換回可用物件）。這些步驟可能會帶來開銷並影響應用程式的整體速度。

// Node.js example using JSON.stringify for serialization
const data = { key: 'value' };
const jsonString = JSON.stringify(data);

字串操作

JSON 是基於文字的，嚴重依賴字串操作來進行連接和解析等操作。與處理二進位資料相比，字串處理可能會慢一些。

缺乏資料類型

JSON 具有一組有限的資料類型（例如字串、數字、布林值）。複雜的資料結構可能需要效率較低的表示，導致記憶體使用量增加和處理速度變慢。

{
  "quantity": 1.0
}

冗長

JSON 的人類可讀設計可能會導致冗長。冗餘金鑰和重複結構會增加有效負載大小，導致資料傳輸時間更長。

// Inefficient
{
  "product1": {
    "name": "Product A",
    "price": 10
  },
  "product2": {
    "name": "Product A",
    "price": 10
  }
}

沒有二進位支持

JSON 缺乏對二進位資料的本機支援。在處理二進位資料時，開發人員通常需要將其編碼和解碼為文本，這可能會降低效率。

深度嵌套

在某些場景下，JSON資料可能會深度嵌套，需要遞歸解析和遍歷。這種計算複雜性可能會減慢您的應用程式的速度，尤其是在沒有最佳化的情況下。

*與此類似，我與其他熱愛開源的開發人員一起在 Slack 上運行一個以開發人員為中心的社群。我們討論這些類型的主題、實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議、為開源做出貢獻以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。 *

我邀請您加入我們的免費社區（沒有廣告，我保證，並且我打算保持這種方式），參與討論，並分享您的經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們有來自一些偉大公司（Atlassian、Gong、Scaler）的優秀人員，您一定不想錯過與他們的互動。 邀請表

讓我們繼續...

JSON 的替代方案

雖然 JSON 是一種通用的資料交換格式，但其在某些場景下的效能限制導致人們探索更快的替代方案。讓我們深入研究其中一些替代方案，並了解您何時以及為何選擇它們：

協定緩衝區

Protocol Buffers，也稱為 protobuf，是 Google 開發的二元序列化格式。它在速度和效率方面表現出色。這就是您可能考慮使用 Protocol Buffer 的原因：

1. 二進位編碼：Protocol Buffers 使用二進位編碼，與 JSON 基於文字的編碼相比，它更緊湊，編碼和解碼速度更快。

2. 高效的資料結構：Protocol Buffers 可讓您透過精確的類型定義高效的資料結構，從而實現更快的序列化和反序列化。

3. 架構演化：Protocol Buffers 支援架構演化，這表示您可以在不破壞向後相容性的情況下更新資料結構。

syntax = "proto3";

message Person {
  string name = 1;
  int32 age = 2;
}

訊息包

MessagePack 是另一種專為提高效率和速度而設計的二元序列化格式。以下是您可能考慮使用 MessagePack 的原因：

1. 緊湊性：MessagePack 產生高度緊湊的資料表示形式，從而減少資料傳輸大小。

2. 二進位資料：MessagePack 提供了對二進位資料的原生支持，非常適合涉及二進位資訊的場景。

3. 速度：MessagePack 的二進位性質允許快速編碼和解碼。

   // JavaScript example using MessagePack for serialization
   const msgpack = require('msgpack-lite');
   const data = { key: 'value' };
   const packedData = msgpack.encode(data);

BSON（二進位 JSON）

BSON，通常發音為“bee-son”或“bi-son”，是一種二進位序列化格式，主要用於 MongoDB 等資料庫。以下是您可能考慮使用 BSON 的原因：

1. 類似 JSON 的結構：BSON 維護了類似 JSON 的結構，並添加了二進位資料類型，在效率和可讀性之間提供了平衡。

2. 二進位資料支援：BSON 提供對二進位資料類型的原生支持，這有利於處理映像或多媒體等資料。

3. 資料庫集成：BSON 與 MongoDB 等資料庫無縫集成，使其成為此類環境的自然選擇。

   {
   "_id": ObjectId("60c06fe9479e1a1280e6bfa7"),
   "name": "John Doe",
   "age": 30
   }

歐元

Avro 是在 Apache Hadoop 專案中開發的資料序列化框架。它強調模式相容性和效能。以下是您可能考慮使用 Avro 的原因：

1. 架構相容性：Avro 優先考慮架構相容性，讓您在不破壞相容性的情況下發展資料結構。

2. 二進位資料：Avro 使用緊湊的二進位編碼格式進行資料傳輸，從而產生更小的有效負載。

3. 語言中立：Avro 支援多種程式語言，使其適合不同的應用程式生態系統。

   {
   "type": "record",
   "name": "Person",
   "fields": [
   { "name": "name", "type": "string" },
   { "name": "age", "type": "int" }
   ]
   }

JSON 及其替代方案之間的選擇取決於您的特定用例和要求。如果架構相容性至關重要，Avro 可能是最佳選擇。如果您需要緊湊性和效率，MessagePack 和 Protocol Buffers 是強有力的競爭者。在處理二進位資料時，MessagePack 和 BSON 可以滿足您的需求。每種格式都有其優點和缺點，因此請選擇適合您專案需求的格式。

最佳化 JSON 效能

但是，如果您決心使用 JSON，儘管它有潛在的速度障礙，該怎麼辦？如何讓 JSON 運作得更快、更有效率？好消息是，有一些實用的策略和最佳化可以幫助您實現這一目標。讓我們透過程式碼範例和最佳實踐來探索這些策略。

1.最小化資料大小

A。 使用簡短的描述性鍵：選擇簡潔但有意義的鍵名稱以減少 JSON 物件的大小。

   // Inefficient
   {
     "customer_name_with_spaces": "John Doe"
   }

   // Efficient
   {
     "customerName": "John Doe"
   }

b. 盡可能縮寫：在不犧牲清晰度的情況下，考慮使用鍵或值的縮寫。

   // Inefficient
   {
     "transaction_type": "purchase"
   }

   // Efficient
   {
     "txnType": "purchase"
   }

2.明智地使用數組

A。 最小化巢狀：避免深度巢狀數組，因為它們會增加解析和遍歷 JSON 的複雜度。

   // Inefficient
   {
     "order": {
       "items": {
         "item1": "Product A",
         "item2": "Product B"
       }
     }
   }

   // Efficient
   {
     "orderItems": ["Product A", "Product B"]
   }

3.優化數位表示

A。 盡可能使用整數：如果一個值可以表示為整數，請使用它而不是浮點數。

   // Inefficient
   {
     "quantity": 1.0
   }

   // Efficient
   {
     "quantity": 1
   }

4.刪除冗餘

A。 避免重複資料：透過引用共享值來消除冗餘資料。

   // Inefficient
   {
     "product1": {
       "name": "Product A",
       "price": 10
     },
     "product2": {
       "name": "Product A",
       "price": 10
     }
   }

   // Efficient
   {
     "products": [
       {
         "name": "Product A",
         "price": 10
       },
       {
         "name": "Product B",
         "price": 15
       }
     ]
   }

5.使用壓縮

A。 套用壓縮演算法：如果適用，請使用 Gzip 或 Brotli 等壓縮演算法來減少傳輸過程中 JSON 有效負載的大小。

   // Node.js example using zlib for Gzip compression
   const zlib = require('zlib');

   const jsonData = {
     // Your JSON data here
   };

   zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => {
     if (!err) {
       // Send compressedData over the network
     }
   });

根據塞繆爾的評論，我添加了一個編輯。

{% devcomment 2adn4 %}

As Samuel rightly observes, the adoption of HTTP/2 has brought significant advancements, particularly in optimizing data interchange formats like JSON. HTTP/2's multiplexing capabilities efficiently manage multiple requests over a single connection, enhancing responsiveness and reducing overhead.

In practical terms, a comprehensive optimization strategy may involve both embracing HTTP/2 and utilizing compression techniques per your use-case, recognizing that each approach addresses specific aspects of network efficiency and performance. HTTP/2 excels in network-level optimization, while compression strategies enhance application-level efficiency, and the synergy between them can lead to substantial gains in data handling speed and resource utilization.

6。使用伺服器端快取

A。 快取 JSON 回應：實作伺服器端快取以有效儲存和提供 JSON 回應，減少重複資料處理的需要。

7.設定檔和優化

A。 分析效能：使用分析工具來識別 JSON 處理程式碼中的瓶頸，然後最佳化這些部分。

請記住，您實施的具體優化應符合應用程式的要求和約束。

實際最佳化：在實作中加速 JSON

現在您已經探索了優化 JSON 的理論方面，現在是時候深入研究遇到 JSON 效能瓶頸並巧妙克服它們的實際應用程式和專案了。這些範例提供了有關用於提高速度和回應能力的策略的寶貴見解，同時仍利用 JSON 的多功能性。

1. LinkedIn 的協定緩衝區整合

挑戰：LinkedIn 與 JSON 冗長和網路頻寬使用的鬥爭

全球最大的職業社交平台LinkedIn面臨嚴峻的挑戰。他們對 JSON 進行微服務通訊的依賴導致了冗長和網路頻寬使用量的增加，最終導致更高的延遲。在每一毫秒都至關重要的數位世界中，這是一個需要解決方案的挑戰。

解決方案：協定緩衝區的力量

LinkedIn 轉向了 Protocol Buffers，通常稱為 protobuf，由Google開發的二進位序列化格式。 Protocol Buffers 的主要優勢在於其效率、緊湊性和速度，使其在序列化和反序列化方面比 JSON 快得多。

影響：延遲減少高達 60%

Protocol Buffers 的採用顯著降低了延遲，報告顯示延遲可提高高達 60%。此次優化顯著提高了 LinkedIn 服務的速度和回應能力，為全球數百萬用戶提供了更流暢的體驗。

2. Uber 的 H3 地理索引

挑戰：Uber 在地理空間資料方面的 JSON 困境

叫車巨頭優步的營運嚴重依賴地理空間數據。 JSON 是表示地理空間資料的預設選擇，但解析大型資料集的 JSON 被證明是一個瓶頸，減慢了演算法的速度。

解決方案：引入 H3 地理索引

Uber 推出了 H3 Geo-Index，這是一種用於地理空間資料的高效能六邊形網格系統。透過從 JSON 轉向這種創新解決方案，他們成功地大幅減少了 JSON 解析開銷。

影響：加速地理空間操作

這種優化大大加速了地理空間操作，提高了 Uber 乘車服務和地圖系統的效率。使用者體驗到更快的回應時間和更可靠的服務。

3. Slack 的訊息格式最佳化

挑戰：Slack 與即時訊息渲染的戰鬥

Slack 是團隊的訊息平台，需要在即時聊天中傳輸和呈現大量 JSON 格式的訊息。然而，這導致了效能瓶頸和訊息渲染緩慢。

解決方案：簡化 JSON 結構

Slack 優化了 JSON 結構以減少不必要的資料。他們開始在每個訊息中只包含基本訊息，從而減少有效負載的大小。

影響：更快的訊息渲染和增強的聊天效能

此優化顯著提高了訊息渲染速度。 Slack 用戶享受到更靈敏、更有效率的聊天體驗，尤其是在繁忙的群組聊天中。

4. Auth0 的協定緩衝區實作

挑戰：Auth0的身份驗證和授權資料效能

Auth0 是一個著名的身份和存取管理平台，在處理身份驗證和授權資料時面臨 JSON 的效能挑戰。這些數據需要在不影響安全性的情況下有效處理。

解決方案：採用協定緩衝區進行資料序列化

Auth0 也轉向Protocol Buffers，利用其高效的資料序列化和反序列化功能。此交換器顯著提高了資料處理速度，使身份驗證過程更快並增強了整體效能。

影響：加速身份驗證和授權

Protocol Buffers 的採用增強了身分驗證和授權流程，確保 Auth0 的服務提供一流的效能，同時保持最高的安全標準。

這些現實世界的例子強調了優化在克服 JSON 相關的速度下降方面的力量。這些案例中採用的策略證明了 JSON 和替代格式在滿足現代數位環境的需求方面的適應性和多功能性。

請繼續關注結論部分，我們總結了關鍵要點，並為您提供了在您自己的專案中優化 JSON 效能的路線圖。

＃＃ 結束語

在開發領域，JSON 是一種多功能且不可或缺的資料交換工具。其人類可讀的結構和跨語言適應性使其成為當代應用程式的基石。然而，正如我們在本指南中的探索所揭示的那樣，JSON 的普遍使用並不能使其免受性能挑戰。

我們在增強 JSON 效能的過程中獲得的重要收穫是顯而易見的：

• 1. 效能至關重要： 速度和反應能力在當今的數位環境中至關重要。用戶要求應用程式以閃電般的速度運行，即使是輕微的延遲也會導致不滿意並錯失機會。
• 2. 大小很重要： 資料有效負載的大小直接影響網路頻寬使用和回應時間。減少資料大小通常是優化 JSON 效能的第一步。
• 3. 探索替代格式： 當效率和速度至關重要時，探索替代資料序列化格式（如 Protocol Buffers、MessagePack、BSON 或 Avro）是有益的。
• 4. 真實世界範例： 從組織有效解決 JSON 相關減速問題的真實實例中學習，表明最佳化工作可以顯著提高應用程式效能。

當您繼續開發和增強 Web 應用程式時，請務必牢記 JSON 對效能的影響。精心設計資料結構，選擇有意義的鍵名稱，並在情況需要時開放探索替代序列化格式。透過這樣做，您可以確保您的應用程式在速度和效率方面不僅滿足而且超越用戶的期望。

在不斷發展的 Web 開發環境中，優化 JSON 效能成為一項寶貴的資產，使您的專案與眾不同，並確保您的應用程式在即時數位體驗時代蓬勃發展。

*與此類似，我與其他熱愛開源的開發人員一起在 Slack 上運行一個以開發人員為中心的社群。我們討論這些類型的主題、實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議、為開源做出貢獻以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。 *

我邀請您加入我們的免費社區（沒有廣告，我保證，並且我打算保持這種方式），參與討論，並分享您的經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們有來自一些偉大公司（Atlassian、Gong、Scaler）的優秀人員，您一定不想錯過與他們的互動。 邀請表

如果您能與您的開發朋友（他們是奉獻者）分享該表格，我將不勝感激。