أحد القرارات الأساسية التي يجب أن يتخذها المطوّرون على الويب هو مكان تنفيذ المنطق والعرض في تطبيقاتهم. قد يكون هذا صعبًا لأن هناك العديد من الطرق لإنشاء موقع ويب.
استندنا إلى فهمنا لهذه المساحة من خلال عملنا في Chrome خلال تحدّثنا إلى المواقع الإلكترونية الكبيرة على مدار السنوات القليلة الماضية. وبصفة عامة، نشجّع المطوّرين على النظر في العرض من جهة الخادم أو العرض الثابت على نهج كامل لمعالجة الجفاف.
لفهم الهياكل التي نختار منها عندما نتخذ هذا القرار بشكل أفضل، نحتاج إلى فهم قوي لكل نهج ومصطلحات متسقة لاستخدامها عند التحدث عنها. تساعد الاختلافات بين أساليب العرض في توضيح المفاضلات بين العرض على الويب من منظور أداء الصفحة.
المصطلحات
العرض
- العرض من جهة الخادم (SSR)
- عرض تطبيق من جهة العميل أو تطبيق عام بتنسيق HTML على الخادم
- العرض من جهة العميل (CSR)
- عرض تطبيق في متصفّح باستخدام JavaScript لتعديل نموذج العناصر في المستند (DOM)
- الجفاف
- "تحسين" طرق عرض JavaScript على العميل لكي يعيد استخدام شجرة بيانات DOM وشجرة HTML التي يعرضها الخادم
- العرض المُسبَق
- تشغيل تطبيق من جهة العميل في وقت الإصدار لتسجيل حالته الأولية كمحتوى HTML ثابت
عروض أداء
- مدة تحميل أول بايت (TTFB)
- الوقت الفاصل بين النقر على رابط وتحميل البايت الأول من المحتوى على الصفحة الجديدة.
- سرعة عرض أول محتوى مرئي (FCP)
- الوقت الذي يصبح فيه المحتوى المطلوب (نص المقالة، وما إلى ذلك) مرئيًا.
- مدى استجابة الصفحة لتفاعلات المستخدم (INP)
- مقياس تمثيلي يقيّم ما إذا كانت الصفحة تستجيب بسرعة كبيرة لإدخالات المستخدمين أم لا.
- إجمالي وقت الحظر (TBT)
- مقياس وكيل لـ INP يحسب المدة التي تم خلالها حظر سلسلة التعليمات الرئيسية أثناء تحميل الصفحة.
العرض على جهة الخادم
يؤدي العرض من جهة الخادم إلى إنشاء رمز HTML الكامل لصفحة على الخادم استجابةً للتنقُّل. يؤدي ذلك إلى تجنُّب عمليات الذهاب والعودة الإضافية لجلب البيانات ووضع نماذج لها على العميل، لأنّ العارض يتعامل مع هذه البيانات قبل أن يتلقّى المتصفّح استجابة.
بشكل عام، يؤدي العرض من جهة الخادم إلى إنشاء سرعة عرض أكبر محتوى مرئي (FCP) بسرعة. يتيح لك تشغيل منطق الصفحة وعرضها على الخادم تجنب إرسال الكثير من ملفات JavaScript إلى العميل. يساعد ذلك في تقليل عدد النتائج التي يتم تحديدها لاحقًا (TBT) في الصفحة، ما قد يؤدي أيضًا إلى انخفاض INP، لأنّ سلسلة التعليمات الرئيسية لا يتم حظرها بالقدر نفسه أثناء تحميل الصفحة. عندما يتم حظر سلسلة التعليمات الرئيسية بمعدل أقل، يكون لدى تفاعلات المستخدمين فرص أكبر للتشغيل بشكل أسرع. وهذا أمر منطقي، لأنّه من خلال العرض من جهة الخادم، يتم إرسال النصوص والروابط إلى متصفّح المستخدم فقط. ويمكن أن يعمل هذا النهج بشكل جيد مع مجموعة متنوعة من ظروف الجهاز والشبكات، ويفتح تحسينات مثيرة للاهتمام في المتصفح مثل تحليل المستندات بشكل مباشر.
عند استخدام العرض من جهة الخادم، يقل احتمال أن ينتظر المستخدمون تشغيل JavaScript المرتبط بوحدة المعالجة المركزية (CPU) قبل أن يتمكّنوا من استخدام موقعك الإلكتروني. حتى إذا تعذّر عليك تجنُّب محتوى JavaScript من جهة خارجية، إنّ استخدام العرض من جهة الخادم لتقليل تكاليف JavaScript الخاصة بالطرف الأول يمكن أن يمنحك المزيد من الميزانية للبقية. ومع ذلك، هناك مفاضلة واحدة محتملة مع هذا المنهج: يستغرق إنشاء صفحات على الخادم بعض الوقت، ما قد يؤدي إلى زيادة عدد الصفحات المُقترَحة لصفحة في موقعك الإلكتروني.
إنّ ما إذا كان العرض من جهة الخادم كافيًا لتطبيقك يعتمد بشكل كبير على نوع التجربة التي تنشئها. هناك جدل طويل الأمد حول التطبيقات الصحيحة للعرض من جهة الخادم مقابل العرض من جهة العميل، لكن يمكنك دائمًا اختيار استخدام العرض من جهة الخادم لبعض الصفحات دون غيرها. وقد اعتمدت بعض المواقع الإلكترونية أساليب العرض المختلط بنجاح. على سبيل المثال، يعرض خادم Netflix صفحاته المقصودة الثابتة نسبيًا، بينما يجلب JS للصفحات ذات التفاعل الكثيف، ما يمنح هذه الصفحات الثقيلة التي يعرضها العميل فرصة أفضل للتحميل بسرعة.
تتيح لك العديد من أطر العمل والمكتبات والبُنى الأساسية الحديثة عرض التطبيق نفسه على كلٍ من العميل والخادم. يمكنك استخدام هذه الأساليب للعرض من جهة الخادم ومع ذلك، فإنّ البنى التي يتم فيها العرض على الخادم وعلى العميل هي فئتها الخاصة من الحلول ذات خصائص الأداء المختلفة والمفاضلات. يمكن لمستخدمي React استخدام واجهات برمجة تطبيقات DOM API أو الحلول المصمَّمة عليها، مثل Next.js للعرض من جهة الخادم. ويمكن لمستخدمي Vue استخدام دليل العرض من جهة الخادم في Vue أو Nuxt. لدى Angular Universal. تستخدم معظم الحلول الشائعة شكلاً من أشكال ترطيب الماء، لكن كن على دراية بالأساليب التي تستخدمها أداتك.
العرض الثابت
يحدث العرض الثابت في وقت الإنشاء. يوفّر هذا الأسلوب سرعة في FCP وأقل من TBT وINP، طالما أنك تحد من مقدار JavaScript من جهة العميل على صفحاتك. وعلى عكس العرض من جهة الخادم، تحقق أيضًا سرعة ثابتة باستمرار في TTFB، نظرًا لأن HTML للصفحة لا يلزم إنشاؤه ديناميكيًا على الخادم. بشكل عام، يعني العرض الثابت إنتاج ملف HTML منفصل لكل عنوان URL في وقت أبكر من السابق. باستخدام ردود HTML التي يتم إنشاؤها مسبقًا، يمكنك نشر عروض ثابتة على العديد من شبكات توصيل المحتوى (CDN) للاستفادة من التخزين المؤقت على الحافة.
تتوفّر حلول العرض الثابت بجميع الأشكال والأحجام. تم تصميم أدوات مثل Gatsby لجعل تطبيقاتهم يشعرون وكأنّ تطبيقاتهم يتم عرضها بشكل ديناميكي، وليس خطوة تصميم. إنّ أدوات إنشاء المواقع الإلكترونية الثابتة، مثل 11ty وJekyll وMetalsmith، هي التي تتميّز بطبيعتها الثابتة، ما يوفّر نهجًا يستند إلى النماذج بشكل أكبر.
من عيوب العرض الثابت أنّه يجب إنشاء ملفات HTML فردية لكل عنوان URL ممكن. وقد يكون ذلك تحديًا أو حتى غير قابل للتنفيذ عندما لا يكون بإمكانك توقّع ما ستكون عليه عناوين URL هذه في وقت مبكر أو المواقع التي تحتوي على عدد كبير من الصفحات الفريدة.
قد يكون المستخدمون المتفاعلون على دراية بـ Gatsby أو Next.js static Export أو Navi، وكل ذلك يجعل من السهل إنشاء صفحات من المكونات. ومع ذلك، يعمل العرض الثابت والعرض المُسبَق بشكل مختلف: فالصفحات المعروضة بشكل ثابت تفاعلية بدون الحاجة إلى تنفيذ الكثير من محتوى JavaScript من جهة العميل، في حين يعمل العرض المُسبَق على تحسين "سرعة عرض المحتوى على الصفحة" لتطبيق "صفحة واحدة" الذي يجب تشغيله على جهاز العميل لجعل الصفحات تفاعلية حقًا.
إذا لم تكن متأكدًا ممّا إذا كان الحل المحدّد هو العرض الثابت أو العرض المُسبَق، جرِّب إيقاف JavaScript وتحميل الصفحة التي تريد اختبارها. بالنسبة إلى الصفحات التي يتم عرضها بشكل ثابت، ستظل معظم الميزات التفاعلية متوفّرة بدون JavaScript. قد لا تزال الصفحات المعروضة مُسبقًا تحتوي على بعض الميزات الأساسية، مثل الروابط التي تم إيقاف JavaScript فيها، ولكن معظم الصفحة غير نشِطة.
يمكنك أيضًا استخدام تقييد الشبكة في "أدوات مطوري البرامج في Chrome" والاطّلاع على مقدار عمليات تنزيل JavaScript قبل أن تصبح الصفحة تفاعلية. يحتاج العرض المُسبَق بشكل عام إلى مزيد من JavaScript ليصبح تفاعليًا، كما أنّ JavaScript غالبًا ما يكون أكثر تعقيدًا من نهج التحسين التدريجي المستخدَم في العرض الثابت.
العرض من جهة الخادم مقابل العرض الثابت
ليس العرض من جهة الخادم هو الحلّ الأفضل لكل شيء، لأنّ طبيعته الديناميكية قد يكون لها تكاليف حاسوبية كبيرة. إنّ العديد من حلول العرض من جهة الخادم لا تعمل على مسح البيانات بشكل مبكر أو تأخير تحويل النص إلى كلام أو مضاعفة البيانات التي يتم إرسالها (على سبيل المثال، الحالات المضمّنة التي تستخدمها لغة JavaScript في البرنامج). في التفاعل،
قد يكون renderToString() بطيئًا لأنه متزامن ومترابط.
تتيح واجهات برمجة التطبيقات الجديدة لـ DOM API لـ React
الوصول المباشر إلى الجزء الأول من استجابة HTML للمتصفح في وقت أقرب بينما يتم إنشاء الباقي على الخادم.
يمكن أن يؤدي اختيار العرض من جهة الخادم إلى العثور على حلّ أو إنشاؤه للتخزين المؤقت للمكوّنات وإدارة استهلاك الذاكرة واستخدام أساليب التذكير وغيرها من المشاكل. غالبًا ما تتم معالجة أو إعادة إنشاء نفس التطبيق مرتين، مرة على العميل ومرة على الخادم. إنّ عرض المحتوى من جهة الخادم لا يمنحك بالضرورة جهدًا أقل. فإذا كان لديك الكثير من العمل على البرنامج بعد وصول استجابة HTML أنشأها الخادم إلى العميل، قد يؤدي ذلك أيضًا إلى زيادة TBT وINP على موقعك الإلكتروني.
ينتج عن العرض من جهة الخادم محتوى HTML عند الطلب لكل عنوان URL، ولكن يمكن أن يكون أبطأ من مجرد عرض المحتوى الثابت المعروض. وإذا كان بإمكانك بذل مجهود إضافي، يمكن أن يؤدي العرض من جهة الخادم والتخزين المؤقت لمحتوى HTML إلى تقليل وقت عرض الخادم بشكل كبير. ويتمثل جانب العرض من جهة الخادم في القدرة على سحب المزيد من البيانات "المباشرة" والاستجابة لمجموعة أكثر اكتمالاً من الطلبات مقارنةً بالعرض الثابت. الصفحات التي تحتاج إلى تخصيص هي مثال ملموس على نوع الطلب الذي لا يعمل بشكل جيد مع العرض الثابت.
قد يقدّم العرض من جهة الخادم أيضًا قرارات شيقة عند إنشاء تطبيق PWA: هل من الأفضل استخدام ذاكرة تخزين مؤقت لعامل الخدمة بملء الصفحة أم عرض أجزاء فردية من المحتوى من خلال الخادم؟
العرض من جهة العميل
ويعني العرض من جهة العميل عرض الصفحات مباشرةً في المتصفّح باستخدام JavaScript. يتم التعامل مع كل العمليات المنطقية وجلب البيانات والنماذج والتوجيه على العميل بدلاً من الخادم. تتمثل النتيجة الفعالة في أن المزيد من البيانات يتم تمريرها إلى جهاز المستخدم من الخادم، والتي تأتي مع مجموعة خاصة من المقايضات.
قد يكون من الصعب إنشاء العرض من جهة العميل والحفاظ على سرعة أدائه على الأجهزة الجوّالة.
من خلال بذل مجهود بسيط للحفاظ على ميزانية محدودة على JavaScript وتقديم قيمة في أقل عدد ممكن من الجولات ذهابًا وإيابًا، يمكنك الحصول على العرض من جهة العميل لمحاكاة أداء العرض الخالص من جهة الخادم تقريبًا. يمكنك تشغيل المحلل اللغوي بشكل أسرع من خلال إرسال نصوص برمجية وبيانات مهمة باستخدام <link rel=preload>
ننصحك أيضًا باستخدام أنماط مثل PRPL
لضمان أن تكون عمليات التنقل الأولية واللاحقة فورية.
والجانب السلبي الأساسي للعرض من جهة العميل هو أنّ مقدار لغة JavaScript المطلوبة يميل إلى الزيادة مع زيادة حجم التطبيق، ما قد يؤثر في مقياس INP للصفحة. ويصبح ذلك صعبًا على وجه التحديد مع إضافة مكتبات JavaScript ورموز polyfill الجديدة والرموز التابعة لجهات خارجية والتي تتنافس للحصول على قوة المعالجة ويجب معالجتها غالبًا قبل أن يتمكّن عرض محتوى الصفحة.
وفي التجارب التي تستخدم العرض من جهة العميل والتي تعتمد على حِزم JavaScript الكبيرة، يجب أن تراعي التقسيم الصارم للرموز لتقليل TBT وINP أثناء تحميل الصفحة، بالإضافة إلى التحميل الكسول لمحتوى JavaScript لعرض ما يحتاجه المستخدم فقط عند الحاجة. بالنسبة إلى التجارب التي يتميّز بها القليل من التفاعل أو ينعدم، يمكن أن يمثّل العرض من جهة الخادم حلاً أكثر قابلية للتطوّر لهذه المشاكل.
بالنسبة إلى الأشخاص الذين ينشئون تطبيقات من صفحة واحدة، يتيح لك تحديد الأجزاء الأساسية لواجهة المستخدم التي تشاركها معظم الصفحات تطبيق أسلوب التخزين المؤقت هيكل التطبيق. بالإضافة إلى عاملي الخدمة، يمكن أن يؤدي ذلك إلى تحسين الأداء الملحوظ بشكل كبير في الزيارات المتكرّرة، لأنّ الصفحة يمكنها تحميل HTML لهيكل التطبيق والتبعيات من CacheStorage بسرعة كبيرة.
تجمع ميزة "إعادة الماء" بين العرض من جهة الخادم والعرض من جهة العميل.
الإمارة هي منهج يحاول تسهيل المفاضلات بين العرض من جهة العميل والعرض من جهة الخادم من خلال تنفيذ الإجراءين معًا. يتم التعامل مع طلبات التنقل مثل عمليات تحميل الصفحة الكاملة أو عمليات إعادة التحميل بواسطة خادم يعرض التطبيق بتنسيق HTML، ثم يتم تضمين JavaScript والبيانات المستخدمة للعرض في المستند الناتج. وعند إجراء ذلك بعناية، يؤدّي ذلك إلى تحقيق سرعة في عرض المحتوى على الصفحة (FCP) مثل العرض من جهة الخادم، ثم "ارتفاع" العرض مرة أخرى على الجهاز العميل. هذا حل فعال، ولكن قد يكون له عيوب كبيرة في الأداء.
والجانب السلبي الأساسي للعرض من جهة الخادم مع الإماهة أنه يمكن أن يكون له تأثير سلبي كبير على TBT وINP، حتى إذا كان يحسن FCP. يمكن أن تبدو الصفحات المعروضة من جهة الخادم محمَّلة وتفاعلية، ولكن لا يمكنها الاستجابة فعليًا للإدخالات إلى أن يتم تنفيذ النصوص البرمجية من جهة العميل للمكوّنات وإرفاق معالِجات الأحداث. على الهاتف المحمول، قد يستغرق ذلك دقائق، مما يتسبب في إرباك المستخدم وإزعاجه.
مشكلة في الجفاف: تطبيق واحد بسعر اثنين
لكي "يستأنف" برنامج JavaScript من جهة العميل بدقة من حيث توقف الخادم، بدون طلب جميع البيانات التي عرض الخادم رمز HTML بها، تعمل معظم حلول العرض من جهة الخادم على إنشاء تسلسل للاستجابة من تبعيات بيانات واجهة المستخدم كعلامات نص برمجي في المستند. ونظرًا لتكرار الكثير من تنسيق HTML، يمكن أن تسبب الجفاف مشاكل أكثر من مجرد التفاعل المتأخر.
يعرض الخادم وصفًا لواجهة المستخدم للتطبيق استجابةً لطلب التنقل، إلا أنه يعرض أيضًا بيانات المصدر المستخدمة لإنشاء واجهة المستخدم هذه، ونسخة كاملة من تنفيذ واجهة المستخدم التي تم تشغيلها بعد ذلك لدى العميل. لا تصبح واجهة المستخدم تفاعلية إلا بعد انتهاء bundle.js من التحميل والتنفيذ.
تشير مقاييس الأداء التي تم جمعها من مواقع الويب الحقيقية باستخدام العرض من جهة الخادم ومعالجة الجفاف إلى أنه نادرًا ما يكون الخيار الأفضل. السبب الأهم هو تأثيرها على تجربة المستخدم، عندما تبدو الصفحة جاهزة ولكن لا تعمل أي من ميزاتها التفاعلية.
ومع ذلك، ما زال هناك أمل في العرض من جهة الخادم باستخدام ميزة الإماهة. على المدى القصير، يمكن أن يؤدي استخدام العرض من جهة الخادم فقط للمحتوى القابل للتخزين المؤقت بشكل كبير إلى تقليل حجم TTFB، ما يؤدي إلى الحصول على نتائج مماثلة للعرض المُسبَق. قد تكون إعادة شرب الماء بشكل تدريجي أو تدريجيًا أو جزئيًا العامل الأساسي لجعل هذه التقنية أكثر قابلية للتطبيق في المستقبل.
بث العرض من جهة الخادم وإعادة المزج تدريجيًا
شهدت العرض من جهة الخادم عددًا من التطورات خلال السنوات القليلة الماضية.
يتيح لك بث العرض من جهة الخادم
إرسال HTML في أجزاء يمكن أن يعرضها المتصفح تدريجيًا أثناء
استلامها. ويمكن أن يساعد ذلك في إتاحة الترميز للمستخدمين بشكل أسرع، ما يؤدي إلى تسريع سرعة عرض المحتوى على الصفحة. في التفاعل، يعني كون عمليات البث غير متزامنة في renderToPipeableStream() مقارنةً
بمزامنة renderToString() المتزامنة، أنه يتم التعامل مع الضغط العكسي على نحو جيد.
ومن المفيد أيضًا استخدام علاج الجفاف التدريجي، وقد تم تنفيذ React عليها. وفقًا لهذا النهج، يتم "تشغيل" الأجزاء الفردية من التطبيق الذي يعرضه الخادم بمرور الوقت، بدلاً من الأسلوب الشائع الحالي لإعداد التطبيق بأكمله دفعة واحدة. ويمكن أن يساعد ذلك في تقليل مقدار رموز JavaScript اللازمة لجعل الصفحات تفاعلية، لأنّه يتيح لك تأجيل ترقية الأجزاء ذات الأولوية المنخفضة من الصفحة من جهة العميل لمنعها من حظر سلسلة التعليمات الرئيسية، ما يتيح حدوث تفاعلات المستخدم في وقت أقرب بعد أن يبدأ المستخدم هذه الأجزاء.
يمكن أن تساعدك عملية تجفيف الماء التدريجي أيضًا في تجنّب أحد أكثر الصعوبات شيوعًا
في العرض من جهة الخادم: يتم تدمير شجرة نموذج العناصر في المستند (DOM) المعروضة من جهة الخادم
وإعادة بنائها على الفور، وغالبًا ما يكون ذلك بسبب الحاجة إلى
العرض المتزامن من جهة العميل لبيانات لم تكن جاهزة تمامًا، وغالبًا ما تكون
Promise التي لم يتم حلّها بعد.
الجفاف الجزئي
لقد ثبت صعوبة تنفيذ الإماهة الجزئية. يشكّل هذا المنهج إضافةً إلى الإماهة التدريجي التدريجية التي تحلل الأجزاء الفردية من الصفحة (المكوّنات أو المشاهدات أو الأشجار) وتحدّد الأجزاء التي لا يتفاعل معها سوى القليل من التفاعل أو لا يتفاعل معها. يتم تحويل رمز JavaScript المقابل إلى كل جزء من هذه الأجزاء الثابتة في الغالب، إلى مراجع غير صالحة وميزات زخرفية، ما يقلّل من أثرها من جهة العميل إلى صفر تقريبًا.
ينطوي أسلوب شرب الماء والسوائل على مشاكل خاصة به وحلول وسط لها. وهي تطرح بعض التحديات المثيرة للاهتمام فيما يتعلق بالتخزين المؤقت، ويعني التنقل من جهة العميل أنه لا يمكننا افتراض أن رمز HTML المعروض من الخادم لأجزاء غير صالحة من التطبيق متاح بدون تحميل الصفحة بالكامل.
عرض ثلاثي الشكل
إذا كان مشغِّلو الخدمات خيارًا مناسبًا لك، ننصحك باستخدام العرض المثلث الشكل. وهي تقنية تتيح لك استخدام العرض من جهة الخادم للبث المباشر لعمليات التنقل الأولية أو التي لا تستخدم JavaScript، ثم الطلب من عامل الخدمة تنفيذ عرض HTML لعمليات التنقّل بعد تثبيته. ويساعد ذلك في الحفاظ على تحديث المكونات والنماذج المخزّنة مؤقتًا، وتفعيل عمليات التنقّل بنمط SPA لعرض طرق عرض جديدة في الجلسة نفسها. يعمل هذا النهج بشكل أفضل عندما يمكنك مشاركة نفس رمز النماذج والتوجيه بين الخادم وصفحة العميل وعامل الخدمة.
اعتبارات تحسين محركات البحث
عند اختيار استراتيجية عرض الويب، غالبًا ما تأخذ الفِرق في الاعتبار تأثير تحسين محركات البحث. يُعد العرض من جهة الخادم خيارًا شائعًا لتقديم تجربة "مظهر كامل" يمكن لبرامج الزحف تفسيرها. يمكن لبرامج الزحف فهم لغة JavaScript، ولكن هناك في كثير من الأحيان قيود مطبَّقة على طريقة العرض. يمكن للعرض من جهة العميل بشكل جيد، ولكنه يحتاج غالبًا إلى اختبار إضافي ونفقات إضافية. في الآونة الأخيرة، أصبح العرض الديناميكي خيارًا يستحق النظر فيه إذا كانت بنيتك الأساسية تعتمد بشكل كبير على JavaScript من جهة العميل.
إذا كانت لديك شكوك، يمكنك الاستعانة بأداة فحص التوافق مع الأجهزة الجوّالة للتأكّد من أنّ المنهج الذي اخترته يحقّق ما تبحث عنه. وهو يعرض معاينة مرئية لكيفية ظهور أي صفحة لزاحف Google، ومحتوى HTML التسلسلي الذي يعثر عليه بعد تنفيذ JavaScript، وأي أخطاء تمت مواجهتها أثناء العرض.
الخلاصة
عند اتخاذ قرار بشأن طريقة العرض، يُرجى قياس الجوانب السلبية وفهمها. فكِّر في ما إذا كان العرض الثابت أو العرض من جهة الخادم يتيح لك تحقيق أقصى استفادة. لا بأس في شحن HTML في الغالب باستخدام الحد الأدنى من JavaScript للحصول على تجربة تفاعلية. إليك مخطط معلومات بياني مفيد يوضح طيف العميل والخادم:
المساهمون
نشكر الجميع على مراجعاتهم وأفكارهم الإبداعية:
"جيفري بوسنيك" و"حسين دجيرده" و"شوبي بانيكر" و"كريس هاريلسون" و"سيباستيان ماركباغ"