تحطيم بودكاست الحلقة 34 مع هاري روبرتس: ما حالة أداء الويب؟

في هذه الحلقة ، نتحدث عن أداء الويب. كيف يبدو مشهد الأداء في عام 2021؟ لقد تحدثت مع الخبير هاري روبرتس لمعرفة ذلك.

وتظهر الملاحظات

يدير Harry ورشة عمل Web Performance Masterclass مع Smashing في مايو 2021. في وقت النشر ، لا تزال هناك خصومات كبيرة على Earlybird.

• هاري على تويتر
• موقع استشارات هاري CSS Wizardry
• دورة بالفيديو كل ما قمت به لجعل CSS Wizardry سريعًا بما في ذلك خصم 15٪
• أسئلة للكتاب الإلكتروني للمستشارين تتضمن خصم 15٪
• دليل Web.dev لأساسيات الويب
• مضرب البيض OXO GoodGrips المفضل لدى Drew

تحديث اسبوعي

• اتجاهات تصميم الويب 2021: التقرير بقلم سوزان سكاكا
• استخدام تطبيقات Grommet In React التي كتبها Fortune Ikechi
• كيفية بناء واجهة برمجة تطبيقات Node.js لـ Ethereum Blockchain التي كتبها جون أغبانوسي
• كيف قمنا بتحسين أداء SmashingMag بقلم فيتالي فريدمان
• عندما نقول لا للمشاريع المستقلة بقلم بيكا كينيدي

نسخة طبق الأصل

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

هاري روبرتس: مرحبًا ، أشكرك كثيرًا. من الواضح أن 14 ذراعا وسبع أرجل ... ما زالت تطرح مشاكلها المعتادة. من المستحيل شراء سراويل.

درو: والدراجات.

هاري: أجل. حسنًا ، لدي ثلاث دراجات ونصف.

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

هاري: هذا ... أنا لا أقول هذا فقط لأكون لطيفًا معك ، هذا سؤال جيد لأنني كنت أفكر في هذا مؤخرًا قليلًا وأود أن أقول أن هناك نصفين منه. شيء واحد أحاول إخبار العملاء به هو أنه في الواقع لا يتحرك بهذه السرعة. في الغالب لأنه ، وهذا هو المقطع الصوتي الذي أستخدمه دائمًا ، يمكنك المراهنة على المتصفح. لا يُسمح للمتصفحات حقًا بتغيير طريقة عملها بشكل جذري ، لأنه ، بالطبع ، هناك عقدين من الإرث الذي يجب أن تدعمه. لذلك ، بشكل عام ، إذا راهنت على المتصفح وكنت تعرف كيف تعمل هذه العناصر الداخلية ، و TCP / IP الذي لا يتغير أبدًا ... لذا فإن بعض الأشياء المحددة إلى حد ما في حجر ، مما يعني أن أفضل الممارسات ، إلى حد كبير ، ستكون دائمًا أفضل الممارسات فيما يتعلق بالأساسيات.

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

درو: لقد ذكرت أن الأساسيات لا تتغير وأن أشياء مثل TCP / IP لا تتغير. أحد الأشياء التي تغيرت في ... أقول "السنوات الأخيرة" ، من المحتمل أن يعود هذا إلى الوراء قليلاً الآن ولكن HTTP من حيث أن لدينا بروتوكول HTTP هذا للتواصل بين العملاء والخوادم ، وقد تغير ذلك بعد ذلك لقد حصلنا على H2 الذي يعد ثنائيًا ومختلفًا. وقد أدى ذلك إلى تغيير الكثير من ... كان لأسباب تتعلق بالأداء ، كان من أجل إزالة بعض القيود الحالية ، ولكن كان هذا تغييرًا وتغيرت الطريقة التي كان علينا تحسينها لهذا البروتوكول. هل هذا مستقر الآن؟ أم أنه سيتغير مرة أخرى ، أم ...

هاري: شيء واحد أود أن أتعلم المزيد عنه هو النصف الأخير من السؤال ، التغيير مرة أخرى. أحتاج إلى مزيد من البحث في QUIC و H3 ، لكن الأمر بعيد جدًا عن الزاوية لأكون مفيدًا لعملائي. عندما يتعلق الأمر بـ H2 ، فقد تغيرت الأمور كثيرًا ولكني أعتقد حقًا أن H2 عبارة عن الكثير من الوعود الكاذبة وأعتقد أنه تم تسريعها عبر الخط ، وهو أمر رائع بالنظر إلى إطلاق H1 ... وأعني 1.1 ، كان 1997 ، لذلك لدينا الكثير من الوقت للعمل على H2.

هاري: أعتقد أن الفائدة الأساسية هي مطوري الويب الذين يفهمونها أو يدركون أنها غير محدودة في طلبات الطيران الآن. لذا بدلاً من إرسال ستة طلبات و / أو ستة طلبات على متن الرحلة في وقت واحد ، يحتمل أن تكون غير محدودة ، ولانهائية. يجلب مشاكل مثيرة للاهتمام حقًا لأنه ... من الصعب وصفه بدون مساعدات بصرية ولكن لا يزال لديك نفس القدر من النطاق الترددي المتاح ، سواء كنت تقوم بتشغيل H1 أو H2 ، فإن البروتوكول لا يجعل اتصالك أسرع. لذلك من المحتمل جدًا أن تغمر الشبكة بطلب 24 ملفًا في وقت واحد ، ولكن ليس لديك نطاق ترددي كافٍ لذلك. لذا فأنت لا تحصل على أي سرعة أسرع لأنه لا يمكنك إدارة ، ربما ، سوى جزء بسيط من ذلك في المرة الواحدة.

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

هاري: حسنًا ، الشيء الآخر هو أنه إذا كنت ستلبي جميع الردود في نفس الوقت ، فستقوم بتشذير الردود. لذلك تحصل ليلاً على أول 10٪ من كل ملف و 20٪ التالية… 20٪ من ملف JavaScript عديم الفائدة. لا يمكن استخدام JavaScript حتى وصول 100٪ منها. إذن ما ستراه هو ، في الواقع ، الطريقة التي يتجلى بها شلال H2 عندما تنظر إلى الاستجابة ... يبدو كثيرًا مثل H1 على أي حال ، إنه أكثر تعقيدًا. لذا ، أعتقد أنه تم بيع H2 بشكل مبالغ فيه ، أو ربما لم يتم توجيه المهندسين للاعتقاد بوجود حدود قصوى لمدى فعاليته. لأنك سترى الأشخاص يقومون بتقسيم أصولهم بشكل مفرط وقد يكون لديهم عشرين… دعنا نحتفظ بالرقم 24. بدلاً من وجود ملفي JS كبيرين ، قد يكون لديك 24 حزمة صغيرة. سوف يستمرون في العودة بالتتابع إلى حد ما. لن يصلوا جميعًا في نفس الوقت لأنك لم تقم بإضفاء المزيد من النطاق الترددي على نفسك.

هاري: والمشكلة الأخرى هي أن لكل طلب مقدار ثابت من الكمون. لذلك لنفترض أنك تطلب ملفين كبيرين وأنه مائة مللي ثانية ذهابًا وإيابًا وتنزيل 250 مللي ثانية ، أي مرتين 250 مللي ثانية. إذا قمت بضرب ما يصل إلى 24 طلبًا ، فلا يزال لديك وقت استجابة ثابت ، وقد قررنا 100 مللي ثانية ، لذلك لديك الآن 2400 مللي ثانية من وقت الاستجابة و 24 مرة ... بدلاً من 250 مللي ثانية للتنزيل ، لنفترض تنزيل 25 مللي ثانية ، لقد استغرق الأمر وقتًا أطول في الواقع لأن وقت الاستجابة يظل ثابتًا وأنت تضاعف وقت الاستجابة هذا في المزيد من الطلبات. لذلك سأرى العملاء الذين قرأوا أن H2 هي هذه الرصاصة السحرية. سوف يكسرون ... أوه! لم يتمكنوا من تبسيط عملية التطوير ، ولسنا بحاجة إلى التجميع أو التسلسل وما إلى ذلك ، وما إلى ذلك. وفي النهاية سينتهي الأمر بشكل أبطأ لأنك تمكنت من نشر طلباتك ، وهذا كان الوعد ، لكن وقت الاستجابة يظل ثابتًا ، لذا أصبح لديك وقت استجابة أكبر بمقدار n مرة في المتصفح. كما قلت ، من الصعب حقًا ، وربما محاولة غير مجدية لشرح ذلك بدون مرئيات ، ولكن من اللافت للنظر كيف يتجلى H2 مقارنة بما يأمل الناس أن يفعله.

درو: هل لا تزال هناك فائدة في عملية التجزئة هذه ، حسنًا ، للحصول على المجموعة الكاملة لا يزال يستغرق نفس القدر من الوقت ولكن بحلول الوقت الذي تحصل فيه على 100٪ من أول 24 مرة ، يمكنك البدء في العمل عليها ويمكنك البدء في تنفيذه قبل 24 من خلال.

هاري: أوه ، يا رجل ، سؤال رائع آخر. لذا ، بالتأكيد ، إذا سارت الأمور بشكل صحيح وتجلت في استجابة أكثر مظهرًا على H1 ، فستكون الفكرة هي ملف واحد يعود أولاً ، اثنان ، ثلاثة ، أربعة ، وبعد ذلك يمكنهم التنفيذ بالترتيب الذي يصلون إليه. لذلك يمكنك في الواقع تقصير الوقت الإجمالي من خلال التأكد من وصول الأشياء في نفس الوقت. إذا ألقينا نظرة على صفحة ويب بدلاً من الشلال ، ولاحظت أن الطلبات متداخلة ، فهذه أخبار سيئة. لأنه كما قلت ، 10٪ من ملف JavaScript عديم الفائدة.

هاري: إذا قام الخادم بعمله بشكل صحيح وقام بالإرسال والإرسال والإرسال والإرسال ، فسيصبح أسرع. وبعد ذلك يكون لديك فوائد إضافية لإستراتيجية التخزين المؤقت الخاصة بك والتي يمكن أن تكون أكثر دقة. سيكون مزعجًا حقًا أن تقوم بتحديث حجم الخط على أداة منتقي التاريخ. في عالم H1 ، يجب عليك تخزين 200 كيلوواط من CSS الواسع لموقعك. بينما الآن ، تقوم فقط بتخزين تمثال نصفي datepicker.css مؤقتًا. لذلك لدينا مزايا فرعية من هذا القبيل ، وهي بالتأكيد ، بالتأكيد ، قيّمة للغاية.

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

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

درو: إذن أنت تبحث أساسًا عن شلال استجابة يبدو أنه يمكنك التزلج عليه.

هاري: أجل ، بالضبط.

درو: لكنك لن تحتاج إلى مظلة.

هاري: أجل. إنه أمر صعب حقًا ... أعتقد أن قول ذلك بصوت عالٍ يبدو تافهًا حقًا ، ولكن بالنظر إلى الطريقة التي تم بها بيع H2 ، أجد ذلك تمامًا ... ليس صعبًا لأن هذا يجعل موكلي يبدو ... غبيًا ... ولكن من الضروري شرح ذلك لهم ... إذا فكرت في كيفية عمل H1 ، فلم يكن الأمر بهذا السوء. وإذا حصلنا على ردود تبدو هكذا و "أوه نعم ، يمكنني رؤيتها الآن". كان علي تعليم مهندسي الأداء هذا من قبل. الناس الذين يفعلون ما أفعله. اضطررت إلى تعليم مهندسي الأداء أننا لا نهتم كثيرًا عند تقديم الطلبات ، فنحن نهتم حقًا عندما تصبح الردود مفيدة.

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

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

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

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

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

هاري: طي في مؤشر واحد.

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

هاري: أجل ، أجل.

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

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

درو: من شأن ذلك أن يدفع رسومك تقريبًا.

هاري: مرحبًا! أجل تقريبًا. لقد قلت لهم "انظروا ، بعد عامين سيؤتي هذا كله ثماره. سوف تتعادل ". وأود. لكن نعم ، هل الجانب المتعلق بمواجهة العميل ... آسف ، الجانب الذي يواجه العميل إذا كان لديك موقع E-Com ، فسوف ينفقون المزيد من الأموال. إذا كنت ناشرًا ، فسيقرأون المزيد من مقال أو سيشاهدون المزيد من الدقائق من المحتوى ، أو أيًا كان ما تفعله فهو مؤشر الأداء الرئيسي الذي تقيسه. يمكن أن يكون على موقع Smashing ، وربما لم يرتدوا ، في الواقع ينقرون على عدد قليل من المقالات لأننا جعلنا الأمر سهلاً وسريعًا حقًا. ومن ثم تكون المواقع الأسرع أرخص في التشغيل. إذا كنت قد أعددت إستراتيجية التخزين المؤقت الخاصة بك ، فسوف تُبعد الناس عن الخوادم الخاصة بك. إذا قمت بتحسين أصولك ، فإن أي شيء يجب أن يأتي من الخادم الخاص بك سيكون وزنه أقل بكثير. أرخص بكثير للتشغيل.

هاري: الشيء ، هناك تكلفة للوصول إلى هناك. أعتقد أن سكوت جيل ربما قال واحدًا من أكثر الأشياء ... وقد سمعته منه أولاً ، لذلك سأفترض أنه توصل إليه ولكن القول المأثور هو "من السهل إنشاء موقع ويب سريع ولكن من الصعب إنشاء موقع ويب بسرعة". وهذا موجز للغاية. نظرًا لأن السبب وراء دفع أداء الويب إلى أسفل قائمة الأشياء التي يجب القيام بها هو أنك قد تكون قادرًا على أن تقول للعميل "إذا جعلت موقعك أسرع ثانية ، فستجني 1.8 مليون إضافية في السنة" أو يمكن أن يكون "إذا أضفت للتو Apple Pay إلى عملية الدفع ، فستجني خمسة ملايين إضافية." لذلك لا يتعلق الأمر بأداء الويب وليس العامل الحاسم ، إنه جزء من استراتيجية أكبر بكثير ، خاصة بالنسبة لـ E-Com عبر الإنترنت. لكن الدليل هو أنني قمت بقياس ذلك بشكل مباشر مع عملائي بالتجزئة ، وعملائي في E-Com. القضية موجودة هناك ، أنت محق تمامًا. إنها ميزة تنافسية ، ستجعلك تحصل على المزيد من المال.

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

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

هاري: ومع ذلك ، هذا يتغير لأن ... حسنًا ، لا أعتقد أنه لا يتغير ، بل إنه يزداد سوءًا. نحن ندفع أكثر نحو العميل. اعتادت أن تكون حالة "الخادم الخاص بك سريع كما هو ولكن بعد ذلك لدينا مجموعة من علامات الاستفهام." لأنني أسمع هذا طوال الوقت "يعمل جميع مستخدمينا على شبكة WiFi. لديهم جميعًا أجهزة سطح مكتب لأنهم جميعًا يعملون من مكتبنا ". حسنًا ، لا ، الآن جميعهم يعملون من المنزل. لا يمكنك الاختيار. لذلك ، هذا هو المكان الذي تظهر فيه جميع علامات الاستفهام ، حيث تحدث التباطؤ ، حيث لا يمكنك التحكم فيه حقًا. بعد ذلك ، حقيقة أننا نميل الآن إلى زيادة اهتمام العميل. أعني بذلك ، أوقات تشغيل كاملة على العميل. لقد نقلت كل منطق التطبيق الخاص بك من الخادم على أي حال ، لذا يجب أن يكون وقتك في البايت الأول ضئيلًا للغاية. يجب أن تكون حالة إرسال بعض الحزم من CDM إلى ... لكنك انتقلت من القدرة على التحديد إلى الخوادم الخاصة بك إلى الأمل في ألا يكون هناك شخص ما لديه Netflix يعمل على نفس الجهاز الذي يحاول عرض موقع الويب الخاص بك عليه .

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

درو: كما قلت ، هناك اتجاه لتحويل المزيد والمزيد من الأشياء إلى المتصفح ، وبالطبع ، إذا كان المتصفح بطيئًا ، فهذا هو المكان الذي يحدث فيه البطء. عليك أن تتساءل "هل هذا اتجاه جيد؟ هل يجب أن نفعل هذا؟ " لدي موقع واحد أفكر فيه بشكل خاص ، لاحظت أنه تم تقديم خادم بنسبة 100 ٪ تقريبًا. هناك القليل جدًا من JavaScript وهو سريع جدًا. في كل مرة أذهب إليها أفكر "أوه ، هذا سريع ، من كتب هذا؟" ثم أدركت "أوه نعم ، لقد كنت أنا".

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

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

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

هاري: وأنا أعلم أنه ... إذا كان جيريمي كيث يستمع إلى هذا ، فمن المحتمل أن يوجه ضربة إليّ ، ولكن هناك ، كما أقول ، فرقًا بين موقع ويب وتطبيق ويب وتعريف ذلك شديد ، غامض جدا. ولكن إذا كان لديك تطبيق للقراءة والكتابة بشكل مكثف ، فهناك شيء تقوم فيه بإدخال البيانات ، ومعالجة البيانات ، وما إلى ذلك. موقعي في الأساس ليس تطبيق ويب ، إنه موقع ويب ، إنه للقراءة فقط ، وأود أن أضعه بحزم في معسكر موقع الويب. شيء مثل برنامج المحاسبة الخاص بي هو تطبيق ويب ، أود أن أقول إنه تطبيق ويب وأنا على استعداد لتحمل القليل من تكلفة وقت التمهيد ، لأنني أعلم أنني سأكون هناك لمدة 20 دقيقة ، أو ساعة ، أو أيًا كان. لذلك أنت بحاجة إلى القليل من السياق ، ومرة ​​أخرى ، ربما تكون النرجسية قاسية بعض الشيء ولكنك تحتاج إلى أن يكون لديك "هل نحتاج إلى جعل هذه الصحيفة تطبيقًا من جانب العميل؟" لا ، لا تفعل. لا ، لا تفعل. استخدم الأشخاص ميزة حظر الإعلانات ، ولا يحب الناس مواقع الصحف الخاصة بالركاب على أي حال. ربما لن يقرؤوا المقال ويتحدثون عنه على فيسبوك. فقط لا تنشئ شيئًا كهذا كتطبيق مقدم من العميل ، فهو غير مناسب.

هاري: أعتقد أن هناك بالتأكيد نقطة يمكن أن يساعدك فيها الانتقال أكثر إلى العميل ، وذلك عندما تكون لديك حساسية أقل للتخبط. لذا فإن أي نوع من أنواع com ، على سبيل المثال ، أقوم بإجراء تدقيق للحظة لموقع… أعتقد أنه موقع E-Com ولكنه 100٪ على العميل. تقوم بتعطيل JavaScript ولا ترى شيئًا ، مجرد معرف div فارغ = "التطبيق". إن E-Com… أنت حساس جدًا لأي مشكلة. حتى أن تدفق الخروج الخاص بك خاطئ تمامًا ، فأنا في مكان آخر. إنه بطيء جدًا ، أنا في مكان آخر. ليس لديك السياق الذي يكون فيه شخص ما على استعداد للنوم في هذا التطبيق لفترة من الوقت.

هاري: فوتوشوب. أقوم بفتح Photoshop ويسعدني جدًا أن أعرف أنه سيستغرق 45 ثانية من شاشة البداية لأنني سأكون هناك لمدة ... بشكل أساسي ، فإن 45 ثانية تساوي 45 دقيقة. ومن الصعب تحديد ذلك ، وهذا هو السبب في أنني أكافح حقًا لإقناع العملاء "من فضلك لا تفعل هذا" لأنني لا أستطيع أن أقول فقط "إلى متى تعتقد أن المستخدم الخاص بك سيكون هناك". ويمكنك وكيله من… إذا كان معدل الارتداد بنسبة 89٪ لا يتم تحسينه لعرض الصفحة الثانية. احصل على معدل الارتداد هذا أولاً. أعتقد أن هناك بالتأكيد انقسامًا ولكن ما يمكنني قوله هو أن معظم الناس يقعون في الجانب الخطأ من هذا الخط. يضع معظم الناس أشياء في العميل لا ينبغي أن تكون موجودة. CNN ، على سبيل المثال ، لا يمكنك قراءة عنوان واحد على موقع CNN الإلكتروني حتى يتم تشغيل تطبيق JavaScript بالكامل. الشيء الوحيد الذي يقدمه الخادم هو الرأس والتذييل وهو الشيء الوحيد الذي لا يهتم به الناس.

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

هاري: وهذا ليس خطأ أحد ، أعتقد أنه بداية هذا النوع من النظام البيئي لجافا سكريبت ، والضجيج المحيط به ، وأيضًا ، سيبدو هذا قاسيًا حقًا ولكن ... إنه في الأساس الكثير من التنفيذ الساذج. بالتأكيد ، اخترع Facebook React وأيًا كان ، فهو يعمل لصالحهم. تسع مرات من أصل 10 لا تعمل بمقياس Facebook ، 95 مرة من 100 ربما لست أذكى مهندسي Facebook ، وهذا حقًا قاسي حقًا ويبدو الأمر مروعًا ، ولكن يمكنك فقط الحصول على ... لا شيء من هذه الأشياء سريعة بشكل افتراضي. أنت بحاجة إلى تنفيذ أنيق للغاية لهذه الأشياء لتصحيحها.

هاري: كنت أجري هذه المناقشة مع عمري ... لقد كان مهندسًا رئيسيًا في الفريق الذي كنت فيه منذ 10 سنوات في Sky. كنت أتحدث معه في اليوم السابق حول هذا الأمر ، وكان عليه أن يعمل بجد لجعل تطبيق العميل سريعًا ، بينما جعل تطبيقًا سريعًا للخادم ، لا تحتاج إلى فعل أي شيء. تحتاج فقط إلى عدم جعلها بطيئة مرة أخرى. وأشعر أن هناك الكثير من النظارات الوردية الملونة ، والسذاجة ، والتسويق ... أبدو كئيبًا للغاية ، نحتاج إلى المضي قدمًا قبل أن أبدأ في فقدان الناس هنا حقًا.

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

هاري: ليس ككل ، لكنني أعتقد أن هذه المشكلة تظهر في مكان تتوقعه. إذا نظرت إلى التباين ... لا أعرف ما إذا كنت قد رأيت هذا ولكنني سأفترض أنه لديك ، يبدو أنك تضع إصبعك على النبض ، والتباين بين بيانات أرشيف HTTP حول أي أطر و تُستخدم مكتبات JavaScript في الحالة البرية مقابل دراسة JavaScript ، إذا اتبعت حالة مسح JavaScript ، فستقول "أوه نعم ، 75٪ من المطورين يستخدمون React" بينما أقل من 5٪ من المواقع تستخدم React. لذلك ، أشعر ، بشكل جماعي ، أنني لا أعتقد أنها مشكلة ، لكنني أعتقد أنه في المجالات التي تتوقعها ، الولاء الشديد لإطار عمل واحد على سبيل المثال ، تجربة المطور ... ربما تكون قبل المستخدم. لا أعتقد أنه يجب التغاضي عن تجربة المطور ، أعني ، كل شيء له تكلفة صيانة. سيارتك. كان هناك قرار عندما تم تصميمه أنه "حسنًا ، إذا أخفينا هذا المفتاح ، تلك الوظيفة ، عن ميكانيكي ، فسوف يستغرق ذلك الميكانيكي وقتًا أطول لإصلاحه ، وبالتالي فإننا لا نقوم بأشياء من هذا القبيل". لذلك هناك حاجة إلى وجود توازن بين بيئة العمل وسهولة الاستخدام ، وأعتقد أن هذا أمر مهم. أعتقد أن التركيز بشكل أساسي على تجربة المطور أمر محير بالنسبة لي. لا تقم بالتحسين من أجلك ، قم بالتحسين لعميلك ، يدفع لك عميلك وليس العكس.

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

هاري: صحيح ، وهذا شيء جيد ، وهذا مطمئن. غرفة الصدى ... ليس من الصحي أن يكون لديك هذا النوع من الزراعة الأحادية ربما ، إذا كنت تريد تسميتها كذلك. ولكن أيضًا ، أشعر ... وقد رأيت ذلك في الكثير من أعمالي الخاصة ، وفي الكثير من المطورين ... بصفتي استشاريًا ، أعمل مع العديد من الشركات المختلفة. يقوم الكثير من الأشخاص بعمل رائع في WordPress. ويشغل WordPress 24٪ من الويب. وأشعر أنه قد يكون من السهل جدًا على مطور مثل هذا الذي يعمل في شيء مثل WordPress أو PHP على الواجهة الخلفية ، أو رمز مخصص ، مهما كان ، أن يشعر قليلاً مثل "أوه ، أعتقد أن الجميع يستخدمون React ونحن لسنا كذلك "ولكن في الواقع ، لا. يتحدث الجميع عن React لكنك ما زلت تسير مع التيار ، ما زلت مع الأغلبية. إنه لأمر مطمئن للغاية أن تجد الأغلبية الصامتة.

درو: الاتجاه نحو مولدات المواقع الثابتة ثم استضافة المواقع بالكامل على CDN ، نوع من نهج JAMstack ، أعتقد أنه عندما نتحدث عن تلك الأنواع من مواقع نوع النشر ، بدلاً من مواقع نوع البرامج ، أعتقد أن هذا اتجاه صحي حقًا هل تعتقد

هاري: أنا أحب ذلك بالتأكيد. تتذكر عندما كنا نسمي SSG "ملف flap" ، أليس كذلك؟

درو: نعم.

هاري: لذلك ، قمت ببناء CSS Wizardry على Jekyll عندما كان يسمى Jekyll موقع ويب ملف رفرف. لكننا الآن نخدم مولدنا ، وهو معجب كبير جدًا بذلك. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

درو: نعم.

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? This is so good. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

هاري: لقد حصل على الاحترام لكنه كان أحد الفتيان ، لقد أحببناه جميعًا حقًا. لكنه كان ضخمًا في كل بُعد. يزيد ارتفاعه عن ستة أقدام ، لكنه مجرد فتى كبير. رجل كبير ، كبير ، كبير ، ضخم. وقال لنا "إذا كنت ستصمم مدخلًا ، فهل ستصممه للشخص العادي؟" والأدمغة البالغة من العمر 15 عامًا تقول "حسنًا ، إذا كان عمر كل شخص تقريبًا 5'9 ثم نعم" كان مثل "حسنًا ، على الفور ، هاري لا يمكنه استخدام هذا الباب." أنت لا تصمم للشخص العادي ، بل تصمم للأطراف لأنك تريد أن تكون مفيدة لمعظم الناس. إذا صممت كرسيًا للشخص العادي ، فلن يناسبه السيد Brocklesby. لقد علمني من عمر حقًا ، حقًا ، تصميم لأطرافك.

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

هاري: وهذا هو سبب إخبار العملاء بأنهم سيقولون لي أشياء مثل "حسنًا ، معظم مستخدمينا يستخدمون الجيل الرابع على أجهزة iPhone" لذا حسنًا ، حسنًا ، ونبدأ في اختبار 3G على Android ، مثل "لا ، لا ، معظم مستخدمينا هم أجهزة iPhone "حسنًا ... وهذا يعني أن المستخدم العادي الخاص بك سيحظى بتجربة أفضل ولكن أي شخص ليس بالفعل في النسبة المئوية الخمسين يتخلف عن الركب. لذا ، ضع سقفًا مرتفعًا لنفسك عن طريق وضع توقعات منخفضة جدًا.

هاري: آسف ، لدي عادة سيئة للغاية تتمثل في إعطاء إجابات طويلة حقًا لأسئلة قصيرة. لكنه كان سؤالًا رائعًا ، وللمحاولة والختام ، أتفق معك 100٪ بالتأكيد على أنك تريد إلقاء نظرة على ذلك الذيل الطويل ، فأنت تريد أن تنظر إلى ذلك ... الموقع وإلقاء نظرة على الوسيط ، وقمت بتحسين الوسيط ، وهذا يعني أنك جعلته أفضل للأشخاص الذين كانوا بالفعل راضين تمامًا. 50٪ من الأشخاص الذين يتم تجاهلهم بشكل فعال ليس هو النهج الصحيح. ونعم ، يعود الأمر دائمًا إلى السيد Brocklesby وهو يقول لي "لا تصمم للشخص العادي لأن هاري لا يستطيع استخدام الباب بعد ذلك". أوه ، بالنسبة لأي شخص يستمع ، طولي 193 سم ، لذا فأنا نحيف للغاية ، هذا ما هو عليه.

درو: وكل تلك الذراعين والساقين.

هاري: أجل. هذا واحد جيد أيضا. اكتشفت صديقتي مؤخرًا إعدادات إمكانية الوصول في نظام التشغيل iOS ... لذلك كل شخص لديه هاتفه في وضع صامت ، أليس كذلك؟ في الواقع لا أحد لديه هاتف يرن في الواقع ، الجميع يضعه في وضع صامت. اكتشفت أنه "يمكنك ضبطه بحيث يومض الفلاش عندما تتلقى رسالة. وإذا نقرت على الجزء الخلفي من الهاتف مرتين ، فسيتم عمل لقطة شاشة ". وهذه إعدادات إمكانية الوصول ، وهي مصممة للشريحة المئوية الـ 95. ومع ذلك فهي مثل "أوه ، هذا مفيد حقًا".

هاري: نفس الشيء مع OXO Good Grips. OXO Good Grips ، أواني المطبخ. لدي الكثير منهم في المطبخ. لقد تم تصميمها لأن زوجة المؤسس كانت مصابة بالتهاب المفاصل وأراد صنع أدوات أكثر راحة. صمم من أجل 99 بالمائة ، معظم الناس ليس لديهم التهاب المفاصل. ولكن من خلال التصميم لـ 99 بالمائة ، عن غير قصد ، فإن كل شخص آخر يشبه "يا إلهي ، لماذا لا تكون كل مقشرات البطاطس بهذه الراحة؟" وأشعر أنه حقًا ، حقًا ... أحب الشعور بالرضا أو الحكاية التي أحب أن أخرجها في مثل هذه السيناريوهات. لكن نعم ، إذا قمت بالتحسين من أجلهم ... حسنًا ، المد المرتفع يطفو على جميع القوارب ، وبالتالي يؤدي ذلك إلى تحسين ذيل الأشخاص وستجذب الكثير من العملاء الأكثر سعادة فوق ذلك.

درو: هل لديك خفاقة يدوية OXO Good Grips؟

هاري: لا أفعل. لا أفعل ، هل هو جيد؟

درو: انظر إليه. انه جيد جدا.

هاري: لديّ آلة تقطيع الماندولين OXO Good Grips التي خلعت نهاية إصبعي الأسبوع الماضي.

درو: نعم ، لن أقترب من أحد هؤلاء.

هاري: نعم ، هذا خطأي الغبي.

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

هاري: حسنًا.

درو: ... لأنهم أكبر المؤسسات التي تمتلك أكبر قدر من البيانات.

هاري: صحيح.

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

هاري: هذا بُعد رائع ، أليس كذلك؟ في الواقع ، كان لدي ... لم يكن لدي أي مكان بالقرب من تأثير الأعمال كما وصفته للتو ، لكنني عملت مع عميل منذ عامين ، وتواصل الرئيس التنفيذي معهم لأن موقعهم كان بطيئًا. مثل ، بطيء ، بطيء ، بطيء. رجل لطيف حقًا أيضًا ، إنه مجرد رجل لطيف حقًا ، لكنه مرشد ، مثل الثراء المناسب. وقد حصل على أحدث هاتف iPhone ، يمكنه تحمل تكاليف ذلك. إنه مليونيراً ، ويقضي الكثير من وقته في الطيران بين أستراليا ، ومن أين أتى ، وإستونيا ، حيث يقيم الآن.

هاري: إنه يطير بالدرجة الأولى ، بالطبع هو كذلك. ولكن هذا يعني أن معظم وقته على هاتف iPhone 12 Pro Max اللامع اللامع أيا كان ، أيا كان ، عبر شبكة WiFi بالطائرة ، وهو أمر فظيع. وكان هذا تجاورًا رائعًا حقًا حيث يمتلك الموقع ويستخدمه كثيرًا ، إنه موقع يستخدمه. وكان يدفعها ... أعني بسهولة أن أغنى زبون لهم كان الرئيس التنفيذي. وهو في هذا المنصب المتميز بشكل غريب حيث لديه اتصال أسوأ من جو بابليك لأنه في مكان ما فوق سنغافورة على متن رحلة كوانتاس ، حيث تم سكب الشمبانيا على رقبته ، وهو يكافح. وكانت تلك رؤية رائعة حقًا ... أوه نعم ، لأنك حصلت على 95 بالمائة يمكن أن تسير في أي اتجاه.

درو: نعم ، عندما تبدأ في التحسين لاستخدام موقع مع كأس من الشمبانيا في يد واحدة ، تعتقد "ربما بدأنا نفقد الطريق قليلاً."

هاري: أجل ، بالضبط.

درو: لقد تحدثنا قليلاً عن قياس الأداء ، وفي تجربتي الخاصة مع عمل الأداء ، من الضروري حقًا قياس كل شيء. أنت تُحدِث فرقًا مختلفًا ومقدار الاختلاف الذي تُحدثه. كيف يجب أن نقيس أداء مواقعنا؟ ما هي الأدوات التي يمكننا استخدامها ومن أين نبدأ؟

هاري: يا رجل ، سؤال رائع آخر. إذن ، هناك مجموعة من الإجابات تعتمد على مقدار الوقت والموارد والميل نحو إصلاح سرعة الموقع. لذا فإن ما سأحاول فعله مع العميل هو ... بعض المقاييس الجاهزة للاستخدام جيدة حقًا. وقت التحميل ، لا تهتم بذلك بعد الآن. إنه جدًا ، جدًا ، جدًا ... أعني ، إنه وكيل جيد إذا كان وقت التحميل 120 ثانية ، سأخمن أنه ليس لديك موقع ويب سريع جدًا ، ولكنه غامض جدًا ولا يواجه العملاء حقًا. أعتقد في الواقع أن العناصر الحيوية هي خطوة جيدة حقًا في الاتجاه الصحيح لأنها تقيس تجربة المستخدم ولكنها تستند إلى المدخلات الفنية. يعد Largest Contentful Paint أمرًا رائعًا حقًا للعرض البصري ، لكن الأشياء الفنية الموجودة هناك تفتح طريقك الحرج ، وتأكد من وصول صور البطل بسرعة وتأكد من أن إستراتيجية خط الويب الخاصة بك مناسبة. هناك تيار تقني خفي لهذه المقاييس. هذه حقا جيدة على الرف.

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

هاري: إذن ، العمل مع عميل E-Com في الوقت الحالي حيث يمكننا الربط ... كلما زادت سرعة عرض البداية ، ما هو احتمال إضافة إلى سلة التسوق. إذا كان بإمكانك عرض منتج لهم في وقت أقرب ، فمن المرجح أن يشتريه. وهذا جهد كبير للإعداد ، وهذا نوع من الهدف الممتد للعملاء الذين لديهم طموح حقًا ، ولكن أي شيء تريد حقًا قياسه ، لأنك كما قلت ، لا تريد حقًا قياس ما هو أكبر Contentful Paint ، هل تريد قياس أرباحك وهل تأثرت بـ Large Contentful Paint؟ لذا فإن الهدف الممتد ، الشيء النهائي ، سيكون أي شيء تراه كمؤشر أداء رئيسي لهذا العمل. يمكن أن يكون ، في الصحف ، إلى أي مدى انتقل أحدهم إلى أسفل المقالة؟ وهل هذا يرتبط بأي شكل من الأشكال بتأخير الإدخال الأول؟ هل قرأ الأشخاص المزيد من المقالات إذا كان CLS أقل؟ ولكن بعد ذلك قبل أن نبدأ في عمل مقاييس مخصصة ومخصصة ، أعتقد بصدق أن حيوية الويب هي مكان جيد حقًا للبدء ، كما تم تطبيعها جيدًا. يصبح ... لا أعرف ما هي الكلمة. أقل قاسم مشترك أعتقد ، حيث يمكن للجميع في الصناعة الآن مناقشة الأداء في هذا المجال المتكافئ.

هاري: إحدى المشكلات التي أواجهها ، وأحتاج في الواقع إلى إعداد اجتماع مع فريق العناصر الحيوية ، هي أنني أعتقد أيضًا أن Lighthouse رائعة حقًا ، لكن CLS تمثل 33٪ من عناصر الويب الحيوية. لديك LCP ، FID ، CLS. CLS هي 33٪ من العناصر الحيوية لديك. العناصر الحيوية هي ما يحدث عادةً أمام فريق التسويق لديك ، قسم التحليلات ، لأنه يظهر في وحدة تحكم البحث ، وقد تم ذكره في سياق صفحات نتائج البحث ، بينما يتعلق الأمر بالأمور الحيوية ، لديك وزن ثقيل ، 33٪ ، ثلث من العناصر الحيوية هي CLS ، إنها 5٪ فقط من مجموع نقاط Lighthouse. إذن ما ستحصل عليه هو المطورين الذين يبنون حول Lighthouse ، لأنه يمكن دمجها في الأدوات ، إنه مقياس معمل. العناصر الحيوية هي بيانات ميدانية ، إنها رم.

هاري: لقد حصلت على هذا الانفصال الهائل حيث لديك فريق التسويق الخاص بك يقول "CLS سيئة حقًا" ويفكر المطورون "حسنًا ، إنها 5٪ من درجة Lighthouse التي تمنحها لي DevTools ، إنها 5٪ من النتيجة تقدم لنا Lighthouse CLI في CircleCI "أو أيًا كان ما تستخدمه ، ولكن بالنسبة لفريق التسويق ، فإن 33٪ مما يهتمون به. لذا فإن المشكلة هناك نوعًا ما من الانفصال لأنني أعتقد أن Lighthouse ذات قيمة كبيرة جدًا ، لكنني لا أعرف كيف يوفقون بين هذا الاختلاف الهائل إلى حد ما حيث يمثل CLS في العناصر الحيوية 33٪ من درجاتك ... حسنًا ، ليس النتيجة لأنك ليس لديك واحد بالفعل ، و Lighthouse 5٪ فقط ، وأشياء من هذا القبيل لا تزال بحاجة إلى تسوية قبل أن نتمكن من جعل هذه المناقشة سلسة.

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

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

هاري: إنها كذلك ويمكن جعلها أكثر فائدة. التحليلات ، لسنوات عديدة حتى الآن ، قد استحوذت على معلومات الأداء الأولية. وهذا سيكون وقت DNS ، TCP و TLS ، الوقت حتى البايت الأول ، وقت تنزيل الصفحة ، وهو وكيل ... حسنًا ، أيا كان ، فقط وقت تنزيل الصفحة ووقت التحميل. مقاييس عالية جدا إلى حد ما. لكنها نقطة انطلاق جيدة وعادةً كل مشروع أبدأ به مع عميل ، إذا لم يكن لديهم New Relic أو Speedcurve أو أي شيء آخر ، فسأقول "حسنًا ، دعني ألقي نظرة على تحليلاتك" لأنني أستطيع ذلك أقل توكيلا للوضع من هناك. ولن يكون في أي مكان قريب من شيء مثل Speedcurve أو New Relic أو Dynatrace أو أي شيء آخر. يمكنك إرسال مقاييس مخصصة حقًا ، حقًا ، بسهولة حقًا إلى التحليلات. إذا أراد أي شخص يستمع أن يكون قادرًا على إرسال… موقعي على سبيل المثال. لدي مقاييس مثل "ما مدى سرعة قراءة عنوان إحدى مقالاتي؟ في أي مرحلة تم عرض صورة الصفحة "حول"؟ في أي مرحلة كانت دعوة العمل التي تطلب منك تعييني؟ متى يتم عرض ذلك على الشاشة؟ " من التافه حقًا التقاط هذه البيانات وتقريباً تافهة لإرسالها إلى التحليلات. لذلك إذا أراد أي شخص عرض المصدر على موقعي ، قم بالتمرير لأسفل إلى علامة إغلاق النص والعثور على مقتطف التحليلات ، فسترى مدى سهولة التقاط البيانات المخصصة وإرسالها إلى التحليلات. وفي واجهة مستخدم التحليلات ، لا تحتاج إلى فعل أي شيء. عادةً ما يتعين عليك إعداد تقارير مخصصة والتنقيب في البيانات وجعلها قابلة للتقديم. هؤلاء مواطنون من الدرجة الأولى في Google Analytics. لذا ، في اللحظة التي تبدأ فيها في التقاط التحليلات المخصصة ، يوجد قسم كامل من لوحة القيادة مخصص لها. لا يوجد إعداد ، ولا يوجد حمل ثقيل في GA نفسه ، لذلك فهو حقًا تافه ، وإذا كان العملاء بميزانية حقيقية أو ربما أريد أن أظهر لهم قوة المراقبة المخصصة ، لا أريد أن أقول "أوه ، نعم ، أعدك سيكون الأمر جيدًا حقًا ، هل يمكنني الحصول على 24 ألفًا فقط من أجل Speedcurve؟ " يمكنني أن أبدأ بالقول فقط "انظر ، هذا بدائي. دعونا نرى الاحتمالات هنا ، الآن يمكننا إقناعك بالترقية إلى شيء مثل Speedcurve ".

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

هاري: لا على الإطلاق. لدي مثال وثيق الصلة بهذا الأمر. التحميل المسبق ... مقدمة سريعة حقيقية لأي شخص لم يسمع عن التحميل المسبق ، فإن تحميل بعض الأصول على الويب بطيء جدًا بطبيعته والمرشحان الأساسيان هنا هما صور الخلفية في CSS وخطوط الويب ، لأنه قبل أن تتمكن من تنزيل صورة الخلفية ، يكون لديك لتنزيل HTML ، الذي يقوم بعد ذلك بتنزيل CSS ، ثم يقول CSS "أوه ، هذا div على الصفحة الرئيسية يحتاج إلى صورة الخلفية هذه." لذلك فهو بطيء جدًا بطبيعته لأن لديك هذا الجزء الكامل من وقت CSS بينهما. مع التحميل المسبق ، يمكنك وضع سطر واحد في HTML في علامة الرأس تقول "مرحبًا ، أنت لا تعرف ذلك بعد ، لكن صدقني ، ستحتاج إلى هذه الصورة حقًا ، حقًا ، قريبًا حقًا." لذلك يمكنك وضع تحميل مسبق في HTML والذي يؤدي إلى إيقاف هذا التنزيل بشكل استباقي. بحلول الوقت الذي يحتاج فيه CSS إلى صورة الخلفية ، يكون الأمر مثل "رائع ، لقد حصلنا عليها بالفعل ، هذا سريع." وهذا ما تم إجراؤه على أنه المسيح المثالي على الويب ... هذا هو الشيء ، وأعدك ، لقد قمت بالتغريد هذا الأسبوع الماضي وثبت أنني على صواب مرتين منذ ذلك الحين. يسمع الناس عن التحميل المسبق ، والوعد الذي يقدمه ، وأيضًا يدفعه بشدة بواسطة Lighthouse ، نظريًا ، يجعل موقعك أسرع. يتزوج الناس من فكرة التحميل المسبق لدرجة أنه حتى عندما أستطيع إثبات أنها لا تعمل ، فلن يقوموا بإزالتها مرة أخرى. لأن "لا ، ولكن لايتهاوس قالت." الآن هذه واحدة من تلك الأشياء حيث النظرية سليمة. إذا كان عليك انتظار خط الويب الخاص بك ، مقابل تنزيله مسبقًا ، فستشاهد الأشياء بشكل أسرع. تكمن المشكلة في أنه عندما تفكر في كيفية عمل الويب فعليًا ، أي صفحة تضغط عليها لأول مرة ، أو أي مجال جديد تمامًا تضغط عليه ، يكون لديك مقدار محدود من النطاق الترددي وإنفاق المتصفح الذكي للغاية لهذا النطاق الترددي بشكل صحيح. سوف يبحث في HTML الخاص بك بسرعة كبيرة ويقوم بعمل قائمة تسوق. أهم شيء هو CSS ، ثم هو jQuery ، ثم هذا ... ثم الأشياء القليلة التالية هي هذه ، وهذه ، وهذه أولوية أقل. بمجرد أن تبدأ في تحميل HTML الخاص بك مع التحميلات المسبقة ، فأنت تخبر المتصفح "لا ، لا ، لا ، هذه ليست قائمة التسوق الخاصة بك بعد الآن ، يا صديقي ، هذا ملكي. عليك أن تذهب وتحصل على هؤلاء ". لا يزال هذا المقدار المحدود من النطاق الترددي محدودًا ولكنه لا يتم إنفاقه عبر المزيد من الأصول ، لذلك يصبح كل شيء أبطأ بشكل هامشي. واضطررت إلى إطلاق صيحات الاستهجان مرتين في الأسبوع الماضي ، وما زال الناس يقولون "نعم ولكن لا ، لأنه يتم تنزيله عاجلاً." لا ، يتم طلبه عاجلاً ، ولكنه يسرق النطاق الترددي من CSS الخاص بك. يمكنك أن ترى حرفيًا أن خطوط الويب الخاصة بك تسرق عرض النطاق الترددي من CSS الخاص بك. لذا فهي واحدة من تلك الأشياء التي يجب عليك فيها ، ويجب عليك اتباع الأرقام. لقد فعلت ذلك من قبل مع عميل كبير الحجم. إذا كنت تستمع إلى هذا ، فقد سمعت عن هذا العميل ، وكنت شديد الإصرار على أنه "لا ، لا ، علامات رأسك في الترتيب الخاطئ لأن هذا هو ما ينبغي أن يكون عليه الأمر ويجب أن يكون لديك في هذا النظام لأنه من الناحية النظرية يشير إلى ذلك ... "حتى في ما كنت عليه بالنسبة للعميل ، كنت أعرف أنني كنت أضع نفسي لأحمق. بسبب طريقة عمل المتصفحات ، يجب أن تكون أسرع. لذلك أنا أقوم بالخدعة ، هذا التغيير ... للعديد من الملايين من الناس ، وأصبح أبطأ. أصبحت أبطأ. وأنا جالس هناك ، أصر بسخط على "لا ولكن ، المتصفحات تعمل بهذه الطريقة" لا فائدة منه لأنه لا يعمل. وقمنا بإعادتها وقلت "آسف! ما زلت بصدد إصدار فاتورة لك مقابل ذلك! " لذلك ليس أنت على الإطلاق.

درو: اتبع هذه الأرقام.

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

درو: مع تغير المناظر الطبيعية وتطور التكنولوجيا ، تطرح Google تقنيات جديدة تساعدنا في جعل الأمور أسرع ، هل هناك طريقة جيدة يمكننا من خلالها مواكبة التغييرات؟ هل هناك أي موارد يجب أن نبحث عنها لتحديث مهاراتنا باستمرار عندما يتعلق الأمر بأداء الويب؟

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

هاري: وللتخلص من شخص آخر لمدة ثانية ، فإن Cloudflare لديها شيء يسمى Rocket Loader ، وهو AMP-esque في سعيه. لقد تم تصميمه على النحو التالي "فقط قم بتشغيل هذا الشيء على شبكة CDN الخاصة بك ، وسوف يجعل موقعك أسرع." وهي في الواقع مجرد بديل لبناء موقعك بشكل صحيح في المقام الأول. لذا ... لمعالجة هذا الجانب منه ، حاول أن تظل مستقلاً قدر الإمكان ، واعرف كيف تعمل المتصفحات ، مما يعني على الفور أن Chrome monoculture ، لقد عدت إلى حضن Google ، لكن تعرف كيف تعمل المتصفحات ، وتلتزم ببعض الأيديولوجيات الأساسية. عندما تقوم ببناء موقع ، ابحث في الصفحة. سواء كان ذلك في Figma ، أو Sketch ، أو أينما كان ، انظر إلى التصميم وقل "حسنًا ، هذا ما يريد المستخدم رؤيته أولاً ، لذلك لن أضع شيئًا في طريق ذلك. لن أقوم بتحميل هذه الصورة الرئيسية كسولًا لأن هذا سخيف ، فلماذا أفعل ذلك؟ " لذا فكر فقط في "ماذا تريد أن يكون المستخدم أولاً؟" على موقع E-Com ، ستكون صورة المنتج هذه ، وربما تنقل في نفس الوقت ، لكن مراجعات المنتج ، Q و A للمنتج ، تحميلها كسول. دس ذلك خلف JavaScript.

هاري: بعض الطرق الأساسية للعمل التي من شأنها أن تخدمك بشكل صحيح بغض النظر عن التكنولوجيا التي تقرأ عنها ، وهي "إعطاء الأولوية لما يحدده عميلك من أولويات". سيكون القيام بمزيد من العمل على ذلك أسرع ، لذلك لا تضع الأشياء في طريق ذلك ، ولكن بعد ذلك المزيد من الأشياء التكتيكية التي يجب أن يكون الناس على دراية بها ، ومواكبة ... ومرة ​​أخرى ، مباشرة إلى Google ، ولكن الويب. يثبت أنه مورد هائل لإطار العمل الحيادي والرؤى الحيادية المكدسة ... لذلك إذا كنت تريد التعرف على العناصر الحيوية ، فأنت تريد التعرف على PWAs ، لذا فإن web.dev رائع حقًا.

هاري: هناك عدد قليل جدًا من المنشورات التي تركز على الأداء. البريد الإلكتروني الخاص بـ Calibre هو ، أعتقد أن بريده الإلكتروني المثالي كل أسبوعين هو مجرد استثنائي ، إنه هضم جيد حقًا. راقب منصة الويب بشكل عام ، لذلك هناك مجموعة عمل الأداء ، ولديهم الكثير من الأشياء في مقترحات GitHub. مرة أخرى ، عد إلى Google ، ولكن لا أحد يعرف عن هذا الموقع وظواهره: chromestatus.com. يخبرك بالضبط ما يعمل عليه Chrome ، وما هي الإشارات من المتصفحات الأخرى ، لذلك إذا كنت تريد أن ترى ما هو العمل في تلميحات الأولوية ، يمكنك الذهاب والحصول على روابط لجميع متتبعات الأخطاء ذات الصلة. تعرض لك حالة Chrome مراحل مهمة لكل ... "هذا يظهر في MAT8 ، تم إصدار هذا في عام 67 أو أي شيء آخر ، وهذا أمر جيد حقًا للحصول على رؤى تقنية تمامًا.

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

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

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

درو: لقد جمعت دورة فيديو بعنوان "كل ما فعلته لجعل سحر CSS سريعًا".

هاري: نعم!

درو: الأمر مختلف قليلاً عن دورات الفيديو التقليدية عبر الإنترنت ، أليس كذلك؟

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

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

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

هاري: أعتقد أنني حاولت الاحتفاظ به أكثر ... الفائدة من عدم اتباع منهج صارم هي أنك لست بحاجة إلى مشاهدة مقطع فيديو معين أولاً ، فلا توجد مقدمة ، إنها مجرد "اذهب وانظر حولك وشاهد ما تجده ممتعًا" مما يعني أن شخصًا ما يعاني من مشكلات LTP مثل "حسنًا ، يجب أن أغوص في هذا المجلد هنا" أو إذا كان يعاني من مشكلات CSS ، فيمكنه الغوص في هذا المجلد. من الواضح أنه ليس لدي أي إحصائيات ، لكني أتخيل أن هناك معدلًا مرتفعًا للتخلي عن الدورات ، لمجرد أنه يتعين عليك المضي قدمًا خلال ثلاث ساعات من التقديم في حال فاتك شيء ما ، ويكون الأمر مثل "أوه ، هل تعرف ماذا ، لا يمكنني استمر في القيام بذلك كل يوم "وقد يتخلى الأشخاص عن الكثير من الدورات التدريبية. لذلك كان تفكيري مجرد الغوص ، لست بحاجة إلى رؤية الساعات الثلاث السابقة ، يمكنك فقط الذهاب والعثور على ما تريد. لقد كانت التعليقات حقًا ، حقًا ... في الواقع ، ما سأفعله هو أنها غير موجودة بعد ، لكنني سأفعل ذلك مباشرة بعد المكالمة ، أي شخص يستخدم رمز الخصم SMASHING15 ، سيحصل على خصم 15٪ منه.

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

هاري: نعم ، غير مقصود لكنني سأحسب الفضل في ذلك.

درو: لقد تعلمت كل شيء عن أداء الويب ، ما الذي كنت تتعلم عنه مؤخرًا ، هاري؟

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

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

درو: ربما لا يوجد فرق كبير بين تحسين الأداء على الويب وتحسين الأداء في ركوب الدراجات ، فهذه كلها مكاسب هامشية ، أليس كذلك؟

هاري: أجل ، بالضبط. وكمية الرسوم البيانية التي كنت أنظر إليها على الدراجة ... لدي بيانات طاقة من الدراجة ، سأخرج في رحلة وأعود مثل "أوه ، إذا كان لدي خمسة واط أخرى هنا ولكن بعد ذلك وفرت 10 وات هناك ، يمكنني أن أفعل هذا ، وهذا ، وهذا هو الأسرع على الإطلاق "و ... كان هناك ضجة كبيرة حول هذا الموضوع. لكن نعم ، أنت على حق. هل تعرف ماذا ، أعتقد أنك واجهت شيئًا مثيرًا للاهتمام حقًا هناك. أعتقد أن هذا النوع من الأشياء هو رياضة / تسلية جيدة لشخص مهووس قليلاً ، يحب مطاردة الأرقام. هناك أشياء قيد التشغيل ، أعني أنك ستعرف هذا ولكن ، سترافا ، لديك KOMs الخاصة بك. لقد حصلت على 19 منهم العام الماضي وهو ، بالنسبة لي ، كمية هائلة. والأمر كله تقريبًا بسبب الهوس بالبيانات المتاحة والنظر إلى "هذا الرجل الذي أحاول التغلب عليه ، كان يعمل 700 واط في هذه المرحلة ، إذا كان بإمكاني الحصول على ما يصل إلى 1000 ثم التخلص منه" ... إنها مهووسة. الذي يذاكر كثيرا. لكنك على حق ، أعتقد أنه شيء مشابه ، أليس كذلك؟ If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

هاري: أجل. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.