تحقيق درجة Google Lighthouse 100%: دليل شامل لمواقع Gatsby بعد تحديث الإصدار 6

يُعد Google Lighthouse الأداة المجانية والرائدة في مجال تحسين محركات البحث (SEO)، والتي لا غنى عنها لتقييم الصحة العامة لموقعك الإلكتروني. بمجرد إدخال عنوان URL الخاص بك، يقوم Lighthouse بتحليل وتقييم مقاييس الأداء الرئيسية لموقعك، بما في ذلك سرعة تحميل الصفحات، وإمكانية الوصول، وأفضل الممارسات، وتحسين محركات البحث على الصفحة.

مع إطلاق الإصدار 6 من Lighthouse في وقت سابق من هذا العام، لاحظ العديد من المطورين انخفاضًا حادًا في مقاييس أداء مواقعهم الإلكترونية. كان هذا بمثابة صدمة خاصة لمجتمع المطورين الذين يعتمدون على إطار العمل الشهير GatsbyJS، المبني على React، والذي اشتهر بسرعته وأدائه الفائقين. بصفتي مطورًا لـ GatsbyJS، كنت أنا أيضًا في حيرة من أمري. لقد اعتدنا على رؤية تلك التقييمات الخضراء الرائعة التي تتجاوز 90 نقطة في الأداء، دون بذل الكثير من الجهد. ولكن بعد تحديث الإصدار 6، تراجع أداء موقعنا إلى المنطقة البرتقالية، وصولًا إلى 60 نقطة! بل إن بعض المواقع شهدت تراجعًا إلى المنطقة الحمراء، مسجلة أقل من 40 نقطة.

في هذا المقال، أشارككم الخطوات التي اتخذتها شخصيًا لاستعادة درجة Google Lighthouse المثالية البالغة 100 نقطة.

الخطوة 1: الحل السريع والفعال: التحول إلى Preact

مع إطلاق الإصدار 6 من Lighthouse، تم تقديم ثلاثة مقاييس أداء جديدة رئيسية: Largest Contentful Paint (LCP)، وCumulative Layout Shift (CLS)، وTotal Blocking Time (TBT). بعد البحث والتدقيق في مستودع Gatsby Github repo ووثائق Lighthouse، اتضح أن مقياس Total Blocking Time (TBT) كان هو المتسبب الرئيسي في إعاقة درجة الأداء للعديد من المواقع.

ما هو Total Blocking Time (TBT)؟

يُعرف Total Blocking Time (TBT) بأنه إجمالي الوقت المستغرق بين أول عرض محتوى (First Contentful Paint - FCP) والوقت اللازم للتفاعل (Time to Interactive - TTI). ببساطة، يقيس TBT المدة التي يتم فيها حظر الخيط الرئيسي للمتصفح بسبب المهام الطويلة، مثل تحليل وتنفيذ شيفرات JavaScript (JS). بناءً على ذلك، فإن أي خطوات تُتخذ لتقليل كمية شيفرات JS، بالإضافة إلى تقليل وقت تنفيذها، ستؤثر إيجابًا على أداء الموقع عن طريق خفض TBT.

التحول إلى Preact: بديل خفيف الوزن لـ React

يُعد Preact بديلاً صغيرًا (حوالي 3 كيلوبايت) وسريعًا لـ React. وبفضل إضافة gatsby-plugin-preact، أصبح تحويل موقع Gatsby الخاص بك من العمل على React إلى Preact أمرًا سهلاً للغاية. اتبع الخطوات التالية:

1. انتقل إلى المجلد الرئيسي لمشروعك وقم بتثبيت الحزم التالية باستخدام NPM:

   npm install --save gatsby-plugin-preact preact preact-render-to-string

2. أو باستخدام Yarn:

   yarn add gatsby-plugin-preact preact preact-render-to-string

3. بعد ذلك، أضف ببساطة gatsby-plugin-preact إلى ملف gatsby-config.js الخاص بك:

   // gatsby-config.js
   module.exports = {
     plugins: [
       `gatsby-plugin-preact`,
       // ... other plugins
     ],
   };

4. ثم قم بتشغيل أمر البناء:

   yarn gatsby build

إذا كنت تستخدم محلل حزمة webpack bundle analyzer، فيجب أن تلاحظ الآن انخفاضًا في حجم الحزمة بحوالي 100 كيلوبايت! هذا ليس سيئًا على الإطلاق. تحقق من الفرق الذي أحدثه هذا التبديل في حجم حزمتنا في الصورة أدناه:

انخفاض بنسبة 8 بالمائة في حجم الحزمة بفضل سطر واحد من التعليمات البرمجية – إنجاز رائع! من المتوقع أن يؤدي التحول إلى Preact إلى رفع درجة أدائك من 5 إلى 10 نقاط.

الخطوة 2: إعادة تقييم ضرورة الصورة البطلة (Hero-Image)

مقياس آخر أثر سلبًا على أداء موقعنا، SmartRate، هو Largest Contentful Paint (LCP). يُعد LCP مقياسًا حيويًا لقياس سرعة التحميل المُدركة من قبل المستخدم. ويشكل هذا المقياس، جنبًا إلى جنب مع Total Blocking Time (TBT)، نسبة 50% من إجمالي درجة أداء Lighthouse. مع أخذ ذلك في الاعتبار، ليس من المستغرب أن تؤثر الصورة التي تغطي 80 بالمائة من الجزء العلوي المرئي من الصفحة (the fold) سلبًا على مقياس LCP، حتى لو تم تحسينها باستخدام تنسيق webp.

تعديلات أولية ونتائجها

لقد قمنا بتعديل الصورة البطلة وحققنا نجاحًا جزئيًا عن طريق تعطيل تأثير التلاشي (fade-in) وتبديل تحميلها من المعامل الافتراضي (lazy) إلى (eager):

ومع ذلك، كانت التحسينات هامشية وبالكاد ملحوظة في Lighthouse (حوالي 2-4 نقاط فقط)، لذلك قررنا إعادة التفكير والتقييم. ما هو الغرض الحقيقي من الصورة البطلة في موقعنا؟

تُستخدم الصورة البطلة عادةً لجذب انتباه المستخدم ونقل رسالة مركزية لتعزيز علامتك التجارية. ولكن في حالتنا، لم يكن هذا هو الاستخدام الأمثل للجزء العلوي من الصفحة (the fold).

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

الحل البديل: خلفية SVG

بدلاً من ذلك، واستلهمنا من مواقع مثل Spotify.com، قررنا استخدام خلفية SVG. هذا القرار الواحد قلل من حجم تحميل الصفحة الأولي بما يصل إلى 65 كيلوبايت! من صورة webp محسّنة بحجم 67 كيلوبايت تقريبًا إلى ملف SVG صغير بحجم 2 كيلوبايت فقط لنفس المساحة المرئية. بعد أن وجدنا أن هذا الحل قد أصلح تمامًا مشكلاتنا مع مقياس LCP، سرعان ما تخلينا عن فكرة استخدام الصورة البطلة في صفحتنا الفرعية الأكثر أهمية، företagslån (قروض الأعمال)، أيضًا.

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

اعتبارات رئيسية إذا كان موقعك يستخدم صورة بطلة

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

• هل الصورة البطلة مصممة خصيصًا لموقعك أم أنها صورة مخزنة (stock-photo)؟
• هل تضيف الصورة البطلة قيمة لعلامتك التجارية؟
• ما هو الغرض من الجزء العلوي من الصفحة (the fold) في موقعك؟

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

موارد رائعة لخلفيات SVG

لقد قمت بتجميع قائمة قصيرة أدناه بموارد وأدوات قيمة لأي شخص يرغب في التحول من استخدام صورة بطلة إلى استخدام أنماط SVG/CSS:

• Hero Patterns بواسطة Steve Schoger: أداة رائعة توفر أنماط SVG متعددة قابلة للتخصيص.
• SVG Patterns بواسطة Philip Rogers: معرض آخر لأنماط SVG المجانية.
• SVGOMG بواسطة Jake Archibald: مورد مجاني رائع لتصغير ملفات SVG (minifying SVG-files). الأمر كله يتعلق بتقليل حجم الكيلوبايت، أليس كذلك؟

الخطوة التالية أكثر ارتباطًا بالموقف، ولكنها ستظل ذات صلة جدًا لمن يستخدمون مكتبة واجهة مستخدم (UI library). بالنسبة لنا، كانت هذه الخطوة لا تقل أهمية عن الخطوتين الأوليين في تحسين مقاييسنا.

الخطوة 3: التخلي عن Material UI لصالح TailwindCSS

دعني أذكر في البداية أنني معجب كبير جدًا بـ Material UI (MUI)، ولست وحدي في هذا الرأي. حتى وقت قريب، كانت MUI المكتبة الأكثر شعبية لواجهة المستخدم (UI) في React على Github (وهي حاليًا في المرتبة الثانية). عندما بدأنا في تطوير موقعنا، كان التصميم يعتمد بالكامل على مكونات MUI. المشكلة الوحيدة كانت أنها كانت تبطئ أداء الموقع بشكل كبير، خاصة لمستخدمي الأجهزة المحمولة.

مشكلة الأداء مع Material UI

بعد إصدار Lighthouse الإصدار 6، لم نتمكن ببساطة من رفع تقييمات أداء الأجهزة المحمولة فوق 70 نقطة، وذلك بسبب ارتفاع كبير في مقياس Total Blocking Time (TBT). لم يبدُ أن أي شيء فعلناه قد أحدث فرقًا في البداية. حتى أننا جربنا تقسيم التعليمات البرمجية (code-splitting) باستخدام Loadable Components، والتحميل الكسول (lazy-loading) للمكونات غير الأساسية.

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

حسنًا، كما اتضح، فإن استيراد مكون MUI واحد فقط كان يجلب مكتبة Material UI بأكملها إلى الحزمة (bundle). وكان تحميل الصفحة الرئيسية يتطلب من المستخدم تنزيل كامل شيفرات CSS و JS الخاصة بـ Material UI. ولكن ماذا عن تقنية tree-shaking التي قد تتساءلون عنها؟ حسنًا، لا يمكنني سوى الرد بأننا اتبعنا توصيات MUI لتقليل حجم الحزمة. ومع ذلك، لم تؤت جهودنا ثمارها. عند إزالة آخر استيراد لـ MUI، لاحظنا انخفاضًا مذهلاً بحوالي 170 كيلوبايت في حجم الحزمة!

التحول إلى TailwindCSS

أخيرًا، ارتفع أداء موقعنا إلى المنطقة الخضراء، متجاوزًا 90 نقطة، حتى على الأجهزة المحمولة! أصبح مقياس TBT غير موجود تقريبًا، ولكن كذلك كان تخطيط موقعنا. لذلك بدأنا في البحث عن بدائل، وتذكرت أنني قرأت عن دمج TailwindCSS في Gatsby في وقت سابق. عبارة واحدة لفتت انتباهي وهي “تنقية CSS الخاص بك” (Purging your CSS). تقوم أداة PurgeCSS، المدمجة الآن في TailwindCSS، بما تتوقعه تمامًا – إزالة شيفرات CSS غير المستخدمة! هذا مثالي.

من خلال الانتقال من Material UI إلى TailwindCSS، تمكنا من الحصول على تصميم شبيه بـ Material مع درجة أداء رائعة. كان مجرد اتباع دليل تثبيت Tailwind في وثائق Gatsby كافيًا لنا للبدء. بدأنا ببطء في تصميم مكونات شبيهة بـ Material باستخدام Tailwind عبر PostCSS. لم تكن بنفس جمال مكونات MUI تمامًا، لكنها لم تكن بعيدة جدًا. وبالنظر إلى الزيادة الهائلة في الأداء، فقد كان الأمر يستحق العناء تمامًا. بصفتنا مبتدئين تمامًا، يجب أن أقول إن تصميم المكونات باستخدام Tailwind بديهي بشكل مدهش. وسرعان ما ستعتاد عليه.

إعادة الاتصال بالخطوة الأولى: ميزة إضافية لـ Preact

ميزة صغيرة أخرى لاستخدام Preact بدلاً من React هي إمكانية استخدام المعامل class بدلاً من المعامل className (الذي لا يزال يعمل). وهذا يجعل تصميم المكونات أسرع قليلاً – خاصة عند نسخ التعليمات البرمجية من موقعهم الرسمي.

إذا قررت التخلي عن Material UI، أو Bootstrap، أو أي مكتبة واجهة مستخدم أخرى مبنية على React لصالح Tailwind، فسيسعدك معرفة الموارد التالية:

• Tailwind UI: من صنع مبدعي TailwindCSS، وهو مستودع حيث يمكنك العثور على مكونات مصممة مسبقًا وجميلة. يمكن استخدام عدد قليل منها مجانًا.
• Tailwind Components: مستودع لمكونات Tailwind المجانية التي صنعها المجتمع.

نصيحة إضافية: إدارة حجم الحزمة للمستقبل

كما يمكنك أن تتخيل، كان تحسين حجم الحزمة (bundle size) وإعادة بناء واجهة المستخدم (UI) بالكامل لموقعنا أمرًا مرهقًا للغاية. إذا تعلمت درسًا واحدًا مهمًا خلال هذه العملية، فهو هذا: انتبه لحجم الحزمة!

مع تزايد وعينا بكيفية تأثير حجم الحزمة على أداء موقعنا، عثرنا على أداة رائعة تسمى bundlephobia.

هذه الأداة الممتازة “تكتشف تكلفة إضافة حزمة npm إلى حزمتك”. ليس هذا فحسب، بل تعرض لك حزمًا مشابهة وكيف ترتبط في الحجم بالحزمة التي تشاهدها حاليًا. كان هذا مفيدًا حقًا لنا عندما قمنا بتطوير الصفحة الفرعية bolån (أسعار الرهن العقاري).

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

باستخدام bundlephobia، قارنا حجم الحزمة لمكتبات الرسوم البيانية المختلفة ووجدنا أنه بناءً على احتياجاتنا، ستكون مكتبة chartist.js كافية لنا.

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

كانت أولويتنا هي الأداء، كما يتضح من النتائج أدناه:

درجة Google Lighthouse شبه مثالية! نقطتان فقط منخفضتان في إمكانية الوصول (Accessibility) بسبب نسبة تباين منخفضة جدًا في بعض الأزرار. ولكن مهلاً، يجب أن يسود التصميم في مكان ما، أليس كذلك؟

في هذا المقال، قمنا بتغطية الخطوات التي اتخذناها لتحقيق درجة Google Lighthouse شبه مثالية، وذلك من خلال:

• تحسين مقياس Total Blocking Time (TBT) بالتحول من React إلى Preact.
• تحسين مقياس Largest Contentful Paint (LCP) بتحسين معلمات الصورة البطلة، أو استبدال الصورة البطلة بنمط SVG.
• تحسين مقياس Total Blocking Time (TBT) بالتحول من Material UI إلى TailwindCSS، وتنقية شيفرات CSS غير المستخدمة باستخدام PurgeCSS.
• تقليل حجم الحزمة الإجمالي.

آمل حقًا أن تلهمك الدروس التي تعلمناها وتفيدك أيضًا!

الخلاصة التقنية

لقد أظهرت تجربتنا أن تحقيق درجة Google Lighthouse مثالية لمواقع Gatsby بعد تحديث الإصدار 6 يتطلب نهجًا متعدد الأوجه يركز على تحسين المقاييس الأساسية مثل Total Blocking Time (TBT) و Largest Contentful Paint (LCP). من خلال التحول الاستراتيجي إلى مكتبات خفيفة الوزن مثل Preact، وإعادة تقييم الحاجة إلى العناصر الثقيلة بصريًا مثل الصور البطلة لصالح بدائل محسّنة مثل خلفيات SVG أو تدرجات CSS، وتبني أطر عمل CSS فعالة مثل TailwindCSS مع ميزات تنقية الشيفرة، يمكن للمطورين تحقيق قفزات كبيرة في الأداء. الأهم من ذلك هو الوعي المستمر بحجم الحزمة الكلي واستخدام أدوات مثل bundlephobia لاتخاذ قرارات مستنيرة بشأن تبعيات المشروع. في النهاية، غالبًا ما تكون هناك مفاضلة بين الجمالية والأداء، ولكن مع التخطيط السليم، يمكن تحقيق توازن يرضي المستخدمين ومحركات البحث على حد سواء.