كيفية استخدام واجهة برمجة تطبيقات قواعد المضاربة لتحميل صفحات الويب على الفور

يبدو أن عام 2024 هو الوقت الذي يصبح فيه التحميل الفوري هو المعيار الجديد في أداء الويب، ويكون أصحاب الأعمال التجارية عبر الإنترنت آذانًا صاغية.

ومع ذلك، فإن الانتقال من السريع إلى الفوري كان قيد التنفيذ منذ فترة.

في وقت مبكر من عام 2009، أدى السعي لتحميل الصفحات بشكل أسرع وأكثر كفاءة إلى قيام فريق Chromium بإنشاء أول تلميحات للموارد، والتي تمت إضافة الرابط rel=”prerender” إليها لاحقًا.

وكان من المتوقع أن يكون له تأثير كبير على الأداء لأنه يتضمن تحميل الصفحات اللاحقة في الخلفية قبل أن ينتقل المستخدم إليها، مما يضمن عرضًا أسرع عند حدوث الانتقال.

ومع ذلك، لم يثبت هذا الإصدار من العرض المسبق فعاليته بدرجة كافية وتم إهماله في عام 2017.

وبالتقدم سريعًا إلى اليوم، أطلقت Google تطورات واعدة لواجهة برمجة التطبيقات لقواعد التخمين الخاصة بها، مما يسمح باتباع نهج أكثر تطورًا للعرض المسبق الكامل وفتح تصفح الويب السلس حقًا.

ما هي واجهة برمجة تطبيقات قواعد المضاربة من Google؟

واجهة برمجة تطبيقات قواعد التخمين هي واجهة برمجة تطبيقات محددة بواسطة JSON تم تطويرها بواسطة Google لتحسين أداء تحميل صفحة الويب من خلال إستراتيجيات التحميل التخمينية.

يتضمن التحميل التخميني التنبؤ بالموارد وتحميلها مسبقًا للتنقلات اللاحقة في الصفحة، مما يؤدي إلى أوقات عرض أسرع وتحسين تجارب المستخدم. قدمت Google واجهة برمجة التطبيقات هذه لتزويد المطورين بطريقة أكثر مرونة وتعبيرًا لتحديد المستندات التي يجب جلبها مسبقًا أو عرضها مسبقًا.

التفاصيل الأساسية حول واجهة برمجة التطبيقات لقواعد المضاربة:

• استهداف عناوين URL للمستندات: على عكس آليات الجلب المسبق التقليدية التي تستهدف ملفات موارد محددة، تركز واجهة برمجة التطبيقات لقواعد المضاربة على عناوين URL للمستندات. وهذا يجعلها مناسبة بشكل خاص للتطبيقات متعددة الصفحات (MPAs) بدلاً من التطبيقات ذات الصفحة الواحدة (SPA).

• العرض المسبق والجلب المسبق: تدعم واجهة برمجة التطبيقات (API) استراتيجيات العرض المسبق والجلب المسبق. يتضمن العرض المسبق جلب المحتوى وعرضه وتحميله في علامة تبويب غير مرئية، وتكون جاهزة للتنشيط شبه الفوري عندما ينتقل المستخدم إلى الصفحة. ومن ناحية أخرى، يؤدي الجلب المسبق إلى تنزيل موارد الصفحة المحددة وحفظها (مثل المستند والصورة والبرنامج النصي وما إلى ذلك)، مما يؤدي إلى تحسين أوقات التحميل عندما ينتقل المستخدم لاحقًا إلى تلك الصفحات.

• دعم المتصفح: تتوافق واجهة برمجة التطبيقات (API) حاليًا مع جميع المتصفحات المستندة إلى Chromium، بما في ذلك Chrome وEdge وOpera وChrome Android وOpera Android وWebView Android. للحصول على تفاصيل التوافق الكاملة، راجع وثائق Mozilla:

يمكنك أيضًا التحقق مما إذا كانت المتصفحات تدعم واجهة برمجة التطبيقات (API) باستخدام الكود التالي:

• بديل للميزات المهملة: إنه بمثابة بديل للتقنيات القديمة مثل ميزة Chrome فقط المهملة ، مما يوفر أداءً أفضل وبناء جملة أكثر تعبيراً.
• الاعتبارات المتعلقة بالأمان: عمليات الجلب المسبق عبر المواقع لها قيود لحماية خصوصية المستخدم. يعمل الجلب المسبق عبر المواقع فقط إذا لم يكن لدى المستخدم ملفات تعريف ارتباط تم تعيينها للموقع الوجهة، مما يمنع التتبع المحتمل لنشاط المستخدم.
  

لماذا تستخدم واجهة برمجة تطبيقات قواعد المضاربة على موقع الويب الخاص بك؟

تعمل واجهة برمجة التطبيقات لقواعد المضاربة على تمكينعمليات تحميل الصفحات بشكل فوري تقريبًا للحصول على تجارب تصفح سلسة.

يعد تحسين أوقات تحميل الصفحةوتعزيز رضا المستخدم ومزايا تحسين محركات البحث المحتملةمن الأسباب المقنعة للمطورين لتبني هذه التكنولوجيا.

ومن خلال تقليل زمن الوصول بين عمليات التنقل في الصفحة، يرى المستخدمون أن موقع الويب أكثر مرونة واستجابة. يصبح هذا مرئيًا بوضوح فيمؤشرات الويب الأساسية لموقعك، حيث ينخفض ​​​​أكبر رسم محتوى (LCP) وإزاحة التخطيط التراكمي (CLS) والتفاعل مع الرسم التالي (INP) بشكل كبير.

مع تجارب التصفح الفورية، تأتي معدلات الارتداد أقل وزيادة الاحتفاظ بالمستخدمين- وهي مقاييس حيوية لنجاح النظام الأساسي الخاص بك على الإنترنت. وبالتالي التأكيد على القيمة الإستراتيجية لدمج واجهة برمجة التطبيقات لقواعد المضاربة.

كيف تعمل واجهة برمجة تطبيقات قواعد المضاربة؟

تم تصميم واجهة برمجة تطبيقات قواعد المضاربة من Google لاستهداف عناوين URL للمستندات بدلاً من ملفات موارد محددة. تقدم واجهة برمجة التطبيقات لقواعد المضاربة صيغة أكثر تعبيرًا وقابلية للتكوين لتحديد المستندات التي يجب جلبها مسبقًا أو عرضها مسبقًا.

من خلال بنية محددة بتنسيق JSON ضمن نوع البرنامج النصي = "speculationrules"، يمكن للمطورين توضيح القواعد لكل من العرض المسبق والجلب المسبق. تسمح هذه المرونة المحسنة بضبط التحميل التخميني.

أعلنت Google مؤخرًا عن تحسين جديد لواجهة برمجة التطبيقات لقواعد المضاربة في Chrome 121، والذي يوفر الآن خيار البحث التلقائي عن الارتباط.

يتم ذلك عن طريق:

• تحديد مصدر الوثيقة
• تحديد الروابط الموجودة على الصفحة بناءً على عناوين URL أو محددات CSS
• تحديد مستوى "الحرص" - حريص (على الفور)، معتدل (عند تمرير 200 مللي ثانية)، ومحافظ (عند الماوس أو اللمس)

ومع ذلك، إذا كنت مستخدمًا جديدًا لـ Speculation Rules API، فنوصيك أولاً باختبار الإعدادات المختلفة أدناه.

كيفية استخدام واجهة برمجة تطبيقات قواعد المضاربة من Google

تسمح واجهة برمجة التطبيقات لقواعد المضاربة للمطورين باتباع نهج منظم لتحسين عمليات العرض المسبق والجلب المسبق.

يثبت

يبدأ الأمر أولاً بإنشاء عنصر script type = "speculationrules" وتحديد قواعد المضاربة في بنية JSON بداخله.

يمكن إضافة قواعد المضاربة إما في رأس الإطار الرئيسي أو جسمه.

هام: لا يتم التعامل مع قواعد التخمين في الإطارات الفرعية، ولا يتم التعامل مع قواعد التخمين في الصفحات المعروضة مسبقًا إلا بمجرد انتقال المستخدم إلى الصفحة نفسها.

يمكن تضمين قواعد المضاربة بشكل ثابت أو ديناميكي.

• يتم إجراء الإعداد الثابت في HTML الخاص بالصفحة (مثالي لمواقع الويب التي يكون فيها الإجراء التالي على درجة عالية من اليقين، على سبيل المثال، قد يرغب موقع ويب إخباري في العرض المسبق للحدث المميز لهذا اليوم)
• يتم الإعداد الديناميكي عبر JavaScript (مناسب لمواقع الويب التي يتم فيها استخدام تجارب المستخدم المخصصة بكثافة)

هام: عند اختيار الإعداد الديناميكي، قم دائمًا بالرجوع إلى وثائق الدعم لمعرفة التطورات المستقبلية وحالات الاستخدام التي قد تصبح متاحة في المستقبل.

لإعلام المتصفح بعناوين URL التي سيتمعرضها مسبقًا ، يمكنك إدراج تعليمات JSON في صفحاتك:

وبالمثل، أدخل تعليمات JSON التالية للجلب المسبق :

من الممكن إضافة قواعد تخمين متعددة إلى الصفحة، وفي هذه الحالة يمكنك توجيه المتصفح على أي من المستويات التالية:

• قائمة عناوين URL
• قواعد المضاربة متعددة
• قوائم متعددة ضمن مجموعة واحدة من قواعد المضاربة
  

تحديد مسارات العرض المسبق/الجلب المسبق

يتضمن الضبط الدقيق للتحميل التخميني تحديد مسارات العرض المسبق والجلب المسبق. من خلال تصنيف الصفحات بناءً على أهميتها أو احتمالية تنقل المستخدم، يمكن للمطورين تحسين استراتيجية التحميل التخمينية.

ومع ذلك، هناك بعض الطرق التي تعتبر غير آمنة، مثل:

• عناوين URL لتسجيل الخروج؛
• عناوين URL لتبديل اللغة؛
• عناوين URL "إضافة إلى سلة التسوق"؛
• عناوين URL لتدفق تسجيل الدخول حيث يطلب الخادم إرسال رسالة نصية قصيرة، على سبيل المثال، عند الحاجة إلى المصادقة الثنائية (2FA)؛
• عناوين URL التي تبدأ تتبع تحويل الإعلانات من جانب الخادم؛
• عناوين URL التي تؤدي إلى فرض قيود على استخدام المستخدم، على سبيل المثال، باستخدام بدل المقالات المجاني الشهري.

على نحو مشابه لاستبعاد هذه الصفحات من التخزين المؤقت، يرتبط سبب تجنب الجلب المسبق والعرض المسبق لها بالمتغيرات الديناميكية.

هذه صفحات حساسة للمحتوى حيث يتم تحديث القيم بناءً على إجراءات المستخدم، ومن خلال تحميلها مسبقًا في الخلفية، يكون خطر إظهار حالة قديمة للصفحة مرتفعًا جدًا.

الدقة والمقايضات

كما ذكر باري بولارد في ندوتنا عبر الإنترنت حول "تحميل الصفحات على الفور":

على الرغم من أن الجلب المسبق هو الأسلوب الأكثر أمانًا الذي يمكنك تكراره عبر العديد من صفحات الويب الخاصة بك، إلا أنه يقدم أيضًا أقل مكافأة لأنه يتضمن فقط تنزيل موارد محددة.

من ناحية أخرى، تقدم العروض المسبقة للصفحة الكاملة مكافآت أعلى، ولكن يجب استخدامها بشكل مقتصد لأنها تستطيع:

• إرباك المتصفح، لأنه لا يمكنه تشغيل سوى كمية محدودة من المهام في الخلفية.
• استهلاك قدر كبير من النطاق الترددي وموارد وحدة المعالجة المركزية مما قد يؤدي إلى تدهور الأداء للمستخدمين على الشبكات الأبطأ أو الأجهزة ذات الموارد المحدودة.
• يؤدي إلى زيادة إهدار الموارد إذا لم ينتقل الزائر إلى الصفحة.

لإعداد العرض المسبق بشكل صحيح، يجب عليك مراعاة سلوك المستخدمين وتحليل عمليات التنقل الشائعة عبر موقع الويب الخاص بك. باستخدام الخرائط الحرارية ومخططات التدفق في Google Analytics، يمكنك تحديد المسارات الأساسية وبدء تجارب التحميل التنبؤية.

للتحقق مما إذا كانت الصفحة قد تم عرضها مسبقًا، استخدم إدخال activationStart غير صفري لـ PerformanceNavigationTiming . ويمكن بعد ذلك تسجيل ذلك باستخدام البعد المخصص:

بهذه الطريقة، ستتمكن من قياس النسبة بين العرض المسبق وأنواع التنقل الأخرى.

بالإضافة إلى ذلك، من المهم قياس عدد الصفحات المعروضة مسبقًا والتي لم تتم زيارتها لاحقًا لتحسين قواعد المضاربة وتحقيق معدلات دخول أعلى وتقليل إهدار الموارد.

يمكنك إما القيام بذلك عن طريق إطلاق حدث التحليلات عند إدراج قواعد التخمين للإشارة إلى أنه قد تم طلب العرض المسبق. ثم قارن عدد هذه الأحداث بعدد مشاهدات صفحة العرض المسبق الفعلية.

أو يمكنك…

فكر في العرض المسبق التلقائي للصفحة باستخدام الذكاء الاصطناعي للتنقل بواسطة NitroPack

إن نظام Navigation AI هو مُحسِّن تصفح الويب المدعوم بالذكاء الاصطناعي من NitroPack والذي يتنبأ بنشاط ويحلل سلوك المستخدم لعرض الصفحات الكاملة مسبقًا أثناء رحلة العميل.

يعمل نظام Navigation AI على تمكين مالكي المواقع من تقديم تجارب تصفح فورية على سطح المكتب والهاتف المحمولدون كتابة سطر واحد من التعليمات البرمجية ، مما يعزز مشاركة العملاء ومعدلات التحويل.

ملحوظة: يعد Navigation AI منتجًا منفصلاً، ولكنه متوافق بنسبة 100% مع NitroPack ويوسع الفوائد لمالكي المواقع.

انضم إلى قائمة الانتظار الخاصة بـ Navigation AI واحصل على تجارب مستخدم فورية على موقعك →

يعتمد نظام Navigation AI من NitroPack على واجهة برمجة تطبيقات Speculation Rules ويقدم حلاً آليًا لتحقيق نسبة نجاح عالية وكفاءة في استخدام الموارد في سيناريوهات العرض المسبق.

من خلال تطبيق التنبؤات الأولية المعززة بالذكاء الاصطناعي عند تحميل الصفحة بناءً على البيانات وتحليل سلوك المستخدم، يمكن للذكاء الاصطناعي للملاحة ضبط التنبؤات وتوجيه واجهة برمجة تطبيقات قواعد التخمين بدقة لعرض الصفحات التي ستتم زيارتها بالفعل بشكل مسبق.

والنتيجة هي تحميل فوري للصفحة بفضل رسم هذه الصفحة بالفعل في الخلفية. على الأجهزة المحمولة، يعتمد نظام Navigation AI على تحديد مكان تواجد المستخدم على الصفحة، ونظرًا لإطار العرض الصغير، يمكنه التنبؤ بسهولة بالمكان الذي سينقر عليه.

استنادًا إلى 1200 موقع ويب، يُظهر نظام Navigation AI بالفعل نتائج مذهلة.

• النتيجة رقم 1: تعرض صفحات الويب التي تستخدم الذكاء الاصطناعي للتنقل باستمرار وقت تحميل يصل إلى 2.86 ثانية تقريبًا مقابل 6.12 ثانية بدون الذكاء الاصطناعي للتنقل

• النتيجة رقم 2: باستخدام Navigation AI، تُظهر الصفحات المعروضة مسبقًا تحسينًا في LCP بنسبة 85% (من 3.1 ثانية إلى 0.4 ثانية) وتحسينًا في CLS بنسبة 80% (من 0.3 ثانية إلى 0.06 ثانية).بالنسبة للصفحات التي يتم جلبها مسبقًا، يعمل نظام Navigation AI على تعزيز LCP بنسبة 52% (من 3.1 ثانية إلى 1.5 ثانية).

• النتيجة رقم 3: باستخدام Navigation AI، تتحسن مقاييس الأداء لموقع الويب بأكمله بشكل ملحوظ: LCP بنسبة 15%، وCLS بنسبة 8%، وTTFB بنسبة 26%

يمكنك الوصول إلى نظام Navigation AI من خلال الانضمام إلى قائمة الانتظار الخاصة بنا →

قواعد المضاربة API وWordPress

في ندوتنا عبر الويب حول "التحميل الفوري للصفحة"، كشف آدم سيلفرشتاين، مهندس علاقات مطوري Google، أن فريق الأداء الأساسي لـ WordPress يعمل على تطبيقات أكثر استقرارًا لواجهة برمجة التطبيقات لقواعد التخمين الجديدة.

في الوقت الحالي، يظل التركيز على إتاحة جزء صغير من وظائف واجهة برمجة التطبيقات (API) لأصحاب المواقع والمطورين في النظام البيئي لاختبار كفاءة ومعدل الاعتماد قبل جعلها جزءًا من النظام الأساسي. إليك ما يمكن لمستخدمي WordPress الاستفادة منه حتى الآن:

• وحدة في البرنامج المساعد Performance Lab
• مكون إضافي مستقل ينفذ الواجهة الأمامية لـ Speculation Rules API فقط (يطبق مستوى "الحرص" المحافظ، ولكن للمطورين الحرية في تعديل السلوك)

يتم استبعاد مسارات WP-admin افتراضيًا، ولكن الأمر متروك لمطوري WP لتحديد المسارات التي يرغبون في تحديد أولوياتها.

يعمل فريق WordPress Core Performance أيضًا على تطبيقات أكثر تعقيدًا ضمن المكونات الإضافية في النظام البيئي. ويهدف هذا إلى التخفيف من بعض العمل الشاق الذي يتعين على المطورين القيام به عند تحديد الطرق التي لها الأولوية القصوى والطرق التي لا ينبغي اتباعها.

ما هي التحسينات القادمة إلى قواعد المضاربة

حاليًا، تقتصر قواعد المضاربة على الصفحات الموجودة ضمن علامة التبويب نفسها، لكن الجهود جارية لتقليل هذه القيود.

يقتصر العرض المسبق افتراضيًا على الصفحات ذات الأصل نفسه. ومع ذلك، يدعم التحديث الأخير في Chrome 119 الآن العرض المسبق للصفحات ذات الأصل المشترك للموقع نفسه، مما يتطلب الاشتراك من خلال رأس HTTP.

قد تعمل الإصدارات المستقبلية على توسيع نطاق العرض المسبق ليشمل الصفحات ذات الأصل المشترك وتسمح به في علامات تبويب جديدة. تم إعداد واجهة برمجة التطبيقات لقواعد المضاربة للتوسع، وتقديم النتائج وبناء الجملة لقواعد المستند وتوفير المزيد من المرونة، مثل العرض المسبق للروابط عند تحريك الماوس لأسفل.

تستكشف التجارب الجارية في Chrome ميزات إضافية، ويمكن للمواقع المشاركة في تجربة أصلية لاختبار الإضافات المستقبلية المحتملة وتقديم التعليقات عليها.