لماذا يهم تحليل حجم الحمولة
لحمولات JSON تأثير مباشر على أداء API. كل بايت يجب أن ينتقل عبر الشبكة ويُحلَّل من قِبَل العميل المستلم ويُخصَّص في الذاكرة. استجابة API حجمها 200 كيلوبايت يمكن أن تكون 20 كيلوبايت باختيار حقول أفضل تُكلّفك 10 أضعاف في النطاق الترددي ووقت التحليل واستنزاف بطارية الجوال.
تحليل الحجم مفيد بشكل خاص عند تصميم أو مراجعة APIs REST ومخططات GraphQL. إن كان حقل ما يُسهم بـ 40 % من وزن الحمولة الكلي، تعرف فوراً أنه يجب تحميله كسولاً أو تقسيمه أو نقله إلى نقطة نهاية منفصلة.
يُبلّغ المحلل أيضاً عن مقاييس بنيوية: أقصى عمق تداخل، وإجمالي عدد المفاتيح والقيم، وعدد أسماء المفاتيح المميزة، ونسبة بايتات المفاتيح إلى بايتات القيم.
قراءة تقرير الحجم
الحجم الكلي: طول سلسلة JSON بالبايتات في شكلها الحالي. يُظهر المحلل أيضاً الحجم المقدَّر بعد ضغط gzip، وهو ما تدفعه فعلاً في نقل HTTP.
أكبر المُسهِمين حسب المفتاح: قائمة مُرتَّبة لأعلى المفاتيح من حيث إجمالي مساهمة البايتات. هذه القائمة هي الأكثر قابلية للتنفيذ — تُخبرك بالضبط أي الحقول تُستهدف للتحسين.
العمق والعرض: أقصى عمق تداخل يُخبرك بمدى تعقيد البنية. العمق العالي (>5 مستويات) غالباً يدل على تصميم هرمي مُفرط.
تقليل حجم حمولة JSON
اختيار الحقول: إن دعمت API ذلك، اطلب فقط الحقول التي تحتاجها. يدعم GraphQL هذا بشكل أصلي. يمكن لـ REST APIs تنفيذه بمعامل استعلام ?fields=.
تقصير المفاتيح: أسماء المفاتيح الطويلة كـ "organizationIdentifier" تُكلف بايتات أكثر من "orgId". في APIs عالية التردد، يمكن لتقصير المفاتيح أن يُقلّل حجم الحمولة بشكل ملموس.
التسطيح البنيوي: الكائنات العميقة التداخل غالباً تُكرّر أسماء المفاتيح ذاتها في كل مستوى. تسطيح الهرمية يُزيل أسماء المفاتيح المتكررة.