تحسين الأداء وتجربة المستخدم: كيف وصلت بموقعي إلى سرعة استثنائية وأرشفة كاملة

فلسفة الأداء في المنصات الهندسية

عند بناء منصة شخصية لعرض مشاريع الميكاترونكس والأنظمة المدمجة، يجب أن تعكس بنية الموقع نفسه معايير الهندسة الدقيقة: الكفاءة العالية، واستهلاك الموارد المنخفض، والاستجابة الفورية.

خلال التحديث الأخير لـ Hasan TechLab، ركزت على معالجة الاختناقات البرمجية وتحسين درجات الأداء في تقارير Google PageSpeed Insights وGoogle Lighthouse للوصول إلى أعلى تقييم ممكن على الحواسيب والهواتف. لم يكن الهدف الحصول على رقم مرتفع في اختبار واحد فقط، بل بناء تجربة سريعة ومستقرة وقابلة للقياس في ظروف استخدام حقيقية.

كيف قست الأداء قبل التعديل؟

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

• LCP - Largest Contentful Paint: الزمن اللازم لظهور أكبر عنصر مرئي في الشاشة.
• INP - Interaction to Next Paint: سرعة استجابة الواجهة لتفاعل المستخدم.
• CLS - Cumulative Layout Shift: مقدار تحرك العناصر أثناء تحميل الصفحة.
• TTFB - Time to First Byte: الزمن بين طلب الصفحة ووصول أول بايت من الخادم.
• حجم JavaScript وCSS والصور، وعدد الطلبات، والموارد التي تمنع العرض.

التمييز بين بيانات المختبر (Lab Data) وبيانات المستخدمين الفعلية (Field Data) مهم هنا. Lighthouse يساعد على اكتشاف الاختناقات بسرعة، بينما تقارير المستخدمين الحقيقيين تكشف أثر الأجهزة القديمة والشبكات البطيئة وأحجام الشاشات المختلفة.

أبرز التحسينات المنفذة

1. معالجة أبعاد الصور وتحميلها

• المشكلة: كانت صورة الملف الشخصي تُحمّل بأبعاد أصلية كبيرة (1440×1440 بكسل وبحجم يقارب 101 كيلوبايت)، بينما تُعرض في الواجهة بمقاس 38×38 بكسل. أدى ذلك إلى زيادة استهلاك البيانات وتأخير مقياس LCP (Largest Contentful Paint) على شبكات الهاتف.
• الحل: أُعيد تحجيم الصورة وضغطها بصيغة ويب خفيفة ومناسبة لأبعاد العرض الفعلية، مما وفّر أكثر من 95% من حجم النقل الخاص بهذا العنصر وسرّع الاستجابة الأولية.

لا يكفي اختيار صيغة WebP أو AVIF ثم إرسال الصورة الأصلية نفسها. يجب أن تتطابق أبعاد المورد مع أبعاد العرض المتوقعة، مع تحديد width وheight لمنع القفزات البصرية، واستخدام srcset عندما توجد أحجام متعددة. أما الصورة الموجودة في الجزء الأول من الصفحة فتحتاج إلى أولوية تحميل مناسبة، بينما الصور أسفل الشاشة يمكن تحميلها عند الحاجة.

2. تقليل تكلفة JavaScript والموارد

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

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

3. تثبيت التخطيط وتحسين الوصول

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

4. توليد خريطة الموقع الديناميكية (XML Sitemap)

• المشكلة: لم تكن خريطة الموقع تُولّد بطريقة منظمة يمكن لمحركات البحث قراءتها مباشرة.
• الحل: دُمجت حزمة @astrojs/sitemap الرسمية ضمن إعدادات astro.config.mjs مع ضبط عنوان الموقع الأساسي:

import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://hasantechlab.com',
  integrations: [sitemap()]
});

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

لكن sitemap وحدها لا تضمن الفهرسة. يجب أن تكون الصفحات قابلة للوصول من خلال روابط داخلية، وأن تحتوي على عنوان ووصف وcanonical URL واضح، وألا تمنعها تعليمات robots.txt. بعد النشر، أتحقق من الملف في Google Search Console وأراقب أخطاء الفهرسة والصفحات المستبعدة.

5. تحسين SEO التقني وبنية المحتوى

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

من الكلمات التي تصف نطاق هذه الدراسة: تحسين سرعة الموقع، تحسين أداء الويب، Core Web Vitals، تحسين LCP، تقليل CLS، تحسين INP، SEO التقني، Astro Performance، Astro Sitemap، ضغط الصور، Google Lighthouse، وPageSpeed Insights.

6. خطة التحقق بعد النشر

بعد كل تعديل كبير، أكرر دورة قصيرة قابلة للمقارنة:

1. تشغيل بناء الإنتاج بدل قياس نسخة التطوير.
2. فحص حجم الملفات والموارد التي تمنع العرض.
3. تشغيل Lighthouse على سطح المكتب والجوال.
4. اختبار الصفحة في شبكة بطيئة وعلى شاشة صغيرة.
5. التحقق من sitemap-index.xml وrobots.txt والروابط الأساسية.
6. مراقبة Search Console وبيانات المستخدمين الحقيقيين بعد وصول زيارات كافية.

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

7. تشريح رحلة تحميل الصفحة

رحلة الصفحة تبدأ قبل أن يرى المستخدم أول حرف. يترجم المتصفح اسم النطاق، وينشئ اتصالًا، ويرسل الطلب، وينتظر أول بايت، ثم يحلل HTML ويكتشف CSS والصور والخطوط والبرامج النصية.

أي مورد في هذه السلسلة قد يصبح عنق زجاجة. لذلك لا أتعامل مع LCP على أنه مشكلة صورة فقط، بل أتبعه إلى السبب السابق له: DNS، أو TTFB، أو CSS يمنع العرض، أو JavaScript يؤخر اكتشاف المورد.

التشخيص الصحيح يسأل: ما أول لحظة كان يمكن فيها للمتصفح أن يعرف المورد؟ وما الذي منعه من استخدامه؟

8. استراتيجية الخطوط

الخطوط المخصصة تحسن الهوية البصرية، لكنها قد تسبب FOIT أو FOUT إذا أُديرت بطريقة غير صحيحة.

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

عند استخدام Google Fonts يجب مراجعة أثر الطلبات الخارجية على DNS وTLS. في الصفحات الحرجة يمكن استضافة الملفات محليًا، مع اختيار subset للغة المطلوبة بدل تحميل مجموعة Unicode كاملة.

9. CSS الذي يمنع العرض

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

لا يعني ذلك تقسيم الملفات عشوائيًا. يجب قياس حجم CSS وتحديد القواعد التي تكرر نفسها أو تأتي من مكتبة لا تحتاجها الصفحة.

تساعد Astro في إبقاء HTML ثابتًا، لكن طريقة استيراد CSS وعدد المكونات ما زالا يؤثران على الناتج النهائي.

10. JavaScript في الصفحة الأولى

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

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

يجب كذلك تجنب listeners كثيرة على عناصر متشابهة عندما يمكن استخدام event delegation، مع الحفاظ على قابلية القراءة وعدم التضحية بسلوك لوحة المفاتيح.

11. تحسين الصور بطريقة قابلة للقياس

أبدأ بتحديد أبعاد العرض الفعلية لكل صورة. صورة avatar بحجم 38×38 لا تحتاج إلى ملف 1440×1440.

بعد ذلك أختار الصيغة وفق طبيعة المحتوى:

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

لا أستخدم loading="lazy" للصورة التي تمثل LCP. أما الصور البعيدة عن viewport فتستفيد غالبًا من التحميل الكسول.

12. منع Cumulative Layout Shift

يحدث CLS عندما يتحرك عنصر بعد أن يراه المستخدم. السبب الشائع هو صورة بلا أبعاد، أو إعلان بلا مساحة محجوزة، أو خط يغير حجم النص.

تحديد width وheight أو aspect-ratio يعطي المتصفح مساحة قبل وصول المورد.

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

13. تحسين INP والتفاعل

INP يقيس سرعة استجابة الصفحة لتفاعل المستخدم. لا يكفي أن تظهر الصفحة بسرعة إذا بقي زر اللغة أو نافذة المقال بلا استجابة.

المهام الطويلة في JavaScript تمنع المتصفح من تحديث الشاشة. يمكن تقسيم العمل، وتأجيل غير الضروري، وتقليل عمليات DOM الكبيرة.

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

14. تقليل TTFB والتخزين المؤقت

TTFB يتأثر بمكان الخادم، التخزين المؤقت، وقت توليد الصفحة، وطلبات الطرف الثالث. الصفحات الثابتة في Astro تقلل وقت التوليد عند الطلب، لكن لا يزال من المهم ضبط CDN وCache-Control واختيار منطقة نشر مناسبة.

الأصول ذات الأسماء الموقعة أو المولدة مع hash يمكن تخزينها لفترة طويلة:

Cache-Control: public, max-age=31536000, immutable

أما HTML وخريطة الموقع فيحتاجان سياسة أقصر حتى تصل التحديثات الجديدة. يجب التأكد من أن cache لا يعرض نسخة قديمة من robots.txt أو sitemap.

15. ميزانية الأداء

أضع ميزانية قابلة للمراجعة بدل عبارة عامة مثل “الموقع سريع”:

هذه الأرقام ليست قانونًا عالميًا، لكنها تجعل regression قابلًا للاكتشاف في Pull Request.

16. Lighthouse مقابل PageSpeed Insights

Lighthouse يعمل بظروف مختبرية قابلة للتكرار، ولذلك هو ممتاز للمقارنة قبل وبعد التعديل.

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

لا أفسر نتيجة واحدة بمعزل عن السياق. أكرر القياس، وأقارن الوسيط، وأراجع التوزيع بين الجوال وسطح المكتب.

17. اختبار الجوال الحقيقي

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

الاختبار اليدوي يكشف مشاكل لا تظهر في الرقم، مثل التفاف العنوان، خروج الجدول من الشاشة، أو تداخل زر الإغلاق مع حافة النافذة.

18. SEO التقني وبنية المحتوى

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

استخدام العبارة نفسها عشرات المرات قد يضر جودة النص. الأفضل تغطية المصطلحات القريبة مثل تحسين سرعة الموقع، أداء الويب، Web Performance، Core Web Vitals، وSEO التقني ضمن سياق مفيد.

خريطة الموقع تساعد محرك البحث على اكتشاف العناوين، لكن الروابط الداخلية تساعده على فهم العلاقة بينها. لذلك ترتبط مقالات الأداء وOTA وRing Buffer بسياق واضح بدل روابط عامة.

19. إمكانية الوصول كجزء من الأداء

الصفحة السريعة التي لا يمكن استخدامها بلوحة المفاتيح ليست منتجًا مكتملًا.

أتحقق من ترتيب Tab، ووضوح focus، ونصوص الأزرار، والتباين، ووجود lang وdir المناسبين للمقال العربي.

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

20. المراقبة ومنع الانحدار

بعد نشر نسخة جيدة، يمكن أن يتدهور الأداء بسبب صورة جديدة أو مكتبة جديدة. لذلك أراجع تقرير البناء، وأفحص حجم الملفات، وأعيد Lighthouse عند تغيير المكونات الأساسية.

أحتفظ بنتائج القياس بتاريخها حتى أعرف هل التحسن مستمر أم كان نتيجة مؤقتة. كما أراقب sitemap-index.xml وrobots.txt وحالة الفهرسة في Search Console.

21. أخطاء تحسين شائعة

• ضغط كل الصور دون الانتباه إلى النص داخلها.
• تأجيل صورة LCP باستخدام lazy loading.
• إزالة JavaScript ضروري ثم إعادته بطريقة أكبر.
• الاعتماد على Lighthouse مرة واحدة.
• إضافة كلمات مفتاحية لا علاقة لها بالنص.
• إنشاء sitemap دون ضبط site الأساسي.
• نسيان اختبار الصفحة من اليمين إلى اليسار.

22. قائمة فحص قبل النشر

1. هل يعمل build الإنتاجي دون أخطاء؟
2. هل يظهر عنوان ووصف فريدان؟
3. هل لكل صورة أبعاد ونص بديل مناسب؟
4. هل LCP أقل من الهدف على الجوال؟
5. هل CLS مستقر أثناء تحميل الخطوط والصور؟
6. هل أزرار اللغة والنافذة تعمل بلوحة المفاتيح؟
7. هل روابط المقالات الداخلية صحيحة؟
8. هل sitemap وrobots.txt متاحان؟
9. هل لا توجد موارد خارجية غير ضرورية؟
10. هل تم اختبار صفحة المقال على شاشة صغيرة؟

النتائج والأرقام المحققة

بعد نشر التحديثات في بيئة الإنتاج، أظهرت تقارير Lighthouse النتائج التالية:

ما الذي يمكن تحسينه لاحقًا؟

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

الخلاصة

تحسين الأداء ليس خطوة تجميلية، بل جزء من جودة المنتج نفسه. تقليل حجم الأصول، وضبط JavaScript، وتحسين Core Web Vitals، وكتابة HTML قابل للوصول، وتوفير خريطة موقع صحيحة، كلها قرارات مترابطة ترفع سرعة التجربة وقابليتها للاكتشاف في الوقت نفسه. أفضل نتيجة لا تأتي من حيلة واحدة، بل من قياس مستمر وقرارات صغيرة يمكن إثبات أثرها بالأرقام.

Mühendislik platformlarında performans felsefesi

Mekatronik ve gömülü sistem projelerini sergileyen kişisel bir platformun yapısı da mühendislik standartlarını yansıtmalıdır: yüksek verimlilik, düşük kaynak tüketimi ve anında yanıt.

Hasan TechLab'in son güncellemesinde yazılım darboğazlarını ele alıp Google PageSpeed Insights ve Google Lighthouse raporlarındaki performans puanlarını masaüstü ve telefonda yükseltmeye odaklandım. Amaç tek testte yüksek sayı değil, gerçek koşullarda hızlı, kararlı ve ölçülebilir bir deneyim kurmaktı.

Değişiklikten önce performansı nasıl ölçtüm?

Her dosyayı değiştirmeden önce açık bir baseline kaydettim. Telefon ağı, işlemci ve bellek sonucu büyük ölçüde değiştirdiği için masaüstü ve mobil sürümleri inceledim:

• LCP - Largest Contentful Paint: Görünen en büyük öğenin ortaya çıkma süresi.
• INP - Interaction to Next Paint: Kullanıcı etkileşimine arayüzün yanıt hızı.
• CLS - Cumulative Layout Shift: Yükleme sırasında öğelerin ne kadar hareket ettiği.
• TTFB - Time to First Byte: İstek ile sunucudan ilk byte arasındaki süre.
• JavaScript, CSS ve görsellerin boyutu, istek sayısı ve render'ı engelleyen kaynaklar.

Lab Data ile gerçek kullanıcı Field Data ayrımı önemlidir. Lighthouse darboğazları hızlıca bulur; gerçek kullanıcı raporları eski cihazların, yavaş ağların ve farklı ekran boyutlarının etkisini gösterir.

Uygulanan başlıca iyileştirmeler

1. Görsel boyutlarını ve yüklenmesini ele almak

• Sorun: Profil fotoğrafı 1440×1440 piksel ve yaklaşık 101 KB olarak yüklenirken arayüzde 38×38 piksel gösteriliyordu. Bu, mobil ağlarda veri tüketimini ve LCP (Largest Contentful Paint) süresini artırdı.
• Çözüm: Görsel gerçek gösterim boyutuna yaklaştırıldı ve web için hafif bir formatla sıkıştırıldı. Bu öğenin aktarım boyutunun %95'inden fazlası azaltıldı.

WebP veya AVIF seçip aynı büyük kaynağı göndermek yeterli değildir. Kaynağın boyutları beklenen gösterim boyutuyla eşleşmeli, width ve height belirtilmeli, farklı boyutlarda srcset kullanılmalıdır. İlk ekrandaki görsel uygun yükleme önceliği ister; ekran altındaki görseller gerektiğinde yüklenebilir.

2. JavaScript ve kaynak maliyetini azaltmak

Her JavaScript dosyası indirme, ayrıştırma ve çalıştırma maliyeti getirir. Etkileşimli kodu gözden geçirip ilk sayfada yalnızca gerekli davranışı tuttum; küçük bir iş için büyük kütüphane yüklemedim. Astro'nun statik bileşenleri, tam istemci tarafı yeniden çizimine göre daha az JavaScript gönderir.

Pratik kural JavaScript'in açık bir etkileşime hizmet etmesidir: pencere açmak, dil değiştirmek, e-posta kopyalamak veya projeyle etkileşmek. Sabit metin ve temel yapı tarayıcıya hazır HTML olarak ulaşmalıdır.

3. Yerleşimi sabitlemek ve erişimi iyileştirmek

Performans erişilebilirlikten ayrı değildir. Görsel boyutlarını ayarlamak, doğru başlık sırasını korumak, düğmelere açık etiketler vermek ve klavyeyi desteklemek görsel karmaşayı azaltır. Yükleme sırasında yerleşimin değişmemesi CLS'yi doğrudan düşürür.

4. Dinamik XML Sitemap üretmek

• Sorun: Sitemap arama motorlarının doğrudan okuyabileceği düzenli biçimde üretilmiyordu.
• Çözüm: Resmi @astrojs/sitemap paketi astro.config.mjs içine eklendi ve temel site adresi ayarlandı:

import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://hasantechlab.com',
  integrations: [sitemap()]
});

Bu işlem platforma yeni makale veya sayfa eklendiğinde sitemap'i otomatik günceller.

Ancak sitemap tek başına indeksleme garantisi vermez. Sayfalar dahili bağlantılarla ulaşılabilir olmalı, açık bir title, description ve canonical URL içermeli, robots.txt tarafından engellenmemelidir. Yayından sonra dosyayı Google Search Console'da kontrol eder, indeksleme hatalarını izlerim.

5. Teknik SEO'yu ve içerik yapısını iyileştirmek

Makale tek bir ana başlıkla başlıyor; alt başlıklar problemi, çözümü ve sonucu açıklıyor. Bu yapı kullanıcı ve arama motoru için okumayı kolaylaştırır. Anahtar kelimeler başlık, açıklama, alt başlık ve görsel alternatif metninde doğal kullanılmalıdır; ifade yapay biçimde tekrarlanmamalıdır.

Bu çalışmanın kapsamını tanımlayan terimler arasında web sitesi hızını artırma, web performansı, Core Web Vitals, LCP optimizasyonu, CLS azaltma, INP iyileştirme, teknik SEO, Astro Performance, Astro Sitemap, görsel sıkıştırma, Google Lighthouse ve PageSpeed Insights bulunur.

6. Yayın sonrası doğrulama planı

1. Geliştirme yerine production build çalıştırmak.
2. Dosya boyutlarını ve render'ı engelleyen kaynakları incelemek.
3. Masaüstü ve mobil Lighthouse çalıştırmak.
4. Yavaş ağda ve küçük ekranda test etmek.
5. sitemap-index.xml, robots.txt ve temel bağlantıları doğrulamak.
6. Search Console'u ve yeterli trafik geldikten sonra gerçek kullanıcı verisini izlemek.

Bu döngü bir metriği iyileştirirken başka deneyimi bozmayı önler. Önemli bir görseli ertelemek sayfa boyutunu düşürürken LCP'yi bozabilir; JavaScript'i fazla azaltmak etkileşimi veya erişimi kırabilir.

7. Sayfa yükleme yolculuğunu incelemek

Sayfa, kullanıcı ilk harfi görmeden önce başlar. Tarayıcı alan adını çözer, bağlantı kurar, istek gönderir, ilk byte'ı bekler; sonra HTML'i analiz edip CSS, görseller, fontlar ve script'leri keşfeder.

Bu zincirdeki her kaynak darboğaz olabilir. LCP'yi yalnızca görsel sorunu olarak değil, DNS, TTFB, render engelleyen CSS veya kaynak keşfini geciktiren JavaScript açısından izlerim.

Doğru teşhis şunu sorar: Tarayıcı kaynağı ilk ne zaman bilebilirdi ve onu kullanmasını ne engelledi?

8. Font stratejisi

Özel fontlar görsel kimliği güçlendirir, ancak yanlış yönetilirse FOIT veya FOUT oluşturabilir.

Sınırlı ağırlıklar kullanır, sayfada görünmeyen ağırlığı yüklemez ve metnin hemen görünmesi anlık eşleşmeden önemli olduğunda font-display: swap ayarlarım.

Google Fonts kullanırken dış isteklerin DNS ve TLS etkisi incelenmelidir. Kritik sayfalarda dosyalar yerel barındırılabilir ve tüm Unicode kümesi yerine gereken dil için subset seçilebilir.

9. Render'ı engelleyen CSS

Büyük veya gereksiz CSS ilk çizimi geciktirebilir. Kritik stiller sayfanın ilk bölümünün ihtiyaç duymadığı stillerden ayrılmalıdır.

Bu, dosyaları rastgele bölmek demek değildir. CSS boyutu ölçülmeli, tekrar eden veya sayfanın kullanmadığı kütüphaneden gelen kurallar belirlenmelidir.

Astro HTML'i sabit tutmaya yardımcı olur; yine de CSS import biçimi ve bileşen sayısı nihai çıktıyı etkiler.

10. İlk sayfadaki JavaScript

Her script indirme, ayrıştırma ve çalıştırma maliyeti ekler. Dil değiştirme veya proje ayrıntısı açma gibi bazı etkileşimler gereklidir; tanıtım sitesinin tamamını istemci uygulamasına dönüştürmeye gerek yoktur.

Önemli içerik HTML'de bulunmalı ve etkileşim kademeli eklenmelidir. Bu SEO'yu iyileştirir ve JavaScript tamamlanmadan da sayfayı kullanılabilir kılar.

Okunabilirliği ve klavye davranışını koruyarak benzer öğelerde çok sayıda listener yerine event delegation kullanmak da yararlıdır.

11. Ölçülebilir görsel optimizasyonu

Her görselin gerçek gösterim ölçüsünü belirlerim. 38×38 boyutundaki avatarın 1440×1440 dosyaya ihtiyacı yoktur.

Sonra formatı içeriğe göre seçerim:

• WebP çoğu görsel için iyi sıkıştırma sunar.
• AVIF daha küçük olabilir; destek ve decode hızı test edilmelidir.
• PNG, şeffaflık veya keskin kenar gerektiğinde uygundur.
• SVG basit ikonlar için uygundur; kaynak ve güven kontrol edilmelidir.

LCP'yi temsil eden görsele loading="lazy" uygulamam. Viewport'tan uzaktaki görseller ise çoğu zaman lazy loading'den yararlanır.

12. Cumulative Layout Shift'i önlemek

CLS, kullanıcı gördükten sonra bir öğe hareket ettiğinde oluşur. Yaygın nedenler boyutsuz görsel, alanı ayrılmamış reklam veya metin boyutunu değiştiren fonttur.

width, height veya aspect-ratio tanımlamak kaynağın gelmesinden önce tarayıcıya alan verir.

Yüklemeden sonra üstte boşluk ayırmadan uyarı çubuğu eklenmemeli ve geç gelen font nedeniyle düğmelerin yüksekliği değişmemelidir.

13. INP ve etkileşimi iyileştirmek

INP kullanıcının etkileşimine sayfanın yanıt hızını ölçer. Sayfa hızlı görünse bile dil düğmesi veya makale penceresi yanıt vermiyorsa yeterli değildir.

Uzun JavaScript görevleri tarayıcının ekranı güncellemesini engeller. İş bölünebilir, gereksiz kısım ertelenebilir ve büyük DOM işlemleri azaltılabilir.

Makale arayüzünde pencere hızlı açılmalı, kod etkileşimle ilgisiz bölümleri yeniden kurmamalıdır.

14. TTFB ve cache

TTFB sunucu konumundan, cache'den, sayfa üretme süresinden ve üçüncü taraf isteklerinden etkilenir. Astro'daki statik sayfalar istek anındaki üretim süresini azaltır; yine de CDN, Cache-Control ve yayın bölgesi ayarlanmalıdır.

Cache-Control: public, max-age=31536000, immutable

Hash içeren asset'ler uzun süre cache'lenebilir. HTML ve sitemap ise güncellemelerin ulaşması için daha kısa politika ister. Cache'in eski robots.txt veya sitemap sunmadığı doğrulanmalıdır.

15. Performans bütçesi

“Site hızlı” gibi genel bir ifade yerine gözden geçirilebilir bir bütçe belirlerim:

Bunlar evrensel yasa değildir; ancak Pull Request'te regression keşfini mümkün kılar.

16. Lighthouse ve PageSpeed Insights karşılaştırması

Lighthouse tekrarlanabilir laboratuvar koşullarında çalışır ve değişiklik öncesi sonrası için mükemmeldir.

PageSpeed Insights, varsa CrUX verisini gösterir; bu veri farklı cihaz ve ağlardaki gerçek kullanıcı deneyimine daha yakındır.

Tek sonucu bağlamından koparmam. Ölçümü tekrarlar, medyanı karşılaştırır ve mobil ile masaüstü dağılımını incelerim.

17. Gerçek mobil testi

Emülatör her zaman sınırlı belleğe sahip eski bir telefonu temsil etmez. Gerçek cihazda test eder, yavaş ağ veya throttling kullanır, metnin görünme süresini ve düğmelerin yanıtını izlerim.

Manuel test; başlığın sarılması, tablonun ekrandan taşması veya kapatma düğmesinin pencere kenarıyla çakışması gibi sayıların göstermediği sorunları ortaya çıkarır.

18. Teknik SEO ve içerik yapısı

Her sayfanın faydasını açıklayan açık bir başlığı ve anahtar kelime listesi olmayan bir açıklaması olmalıdır. Başlık ana konuyu, açıklama sonucu, alt başlıklar gerçek soruları anlatır.

Aynı ifadeyi onlarca kez kullanmak kaliteyi düşürebilir. Hız optimizasyonu, web performansı, Core Web Vitals ve teknik SEO gibi yakın terimler yararlı bağlamda ele alınmalıdır.

Sitemap başlıkların keşfine yardım eder, dahili bağlantılar ise arama motoruna aralarındaki ilişkiyi anlatır. Bu nedenle performans, OTA ve Ring Buffer makaleleri genel bağlantılar yerine açık bağlamla ilişkilendirilir.

19. Erişilebilirlik performansın parçasıdır

Klavye ile kullanılamayan hızlı sayfa tamamlanmış ürün değildir.

Tab sırasını, focus görünürlüğünü, düğme metinlerini, kontrastı ve makalenin uygun lang ile dir değerlerini kontrol ederim.

Görsel boyutlarını sabitlemek CLS'yi azaltır; hiyerarşik başlıklar ve açık etiketler ekran okuyucularının gezinmesine yardım eder. Bu yüzden erişilebilirlik ile performans metrikleri düşündüğümüzden daha çok kesişir.

20. İzleme ve regression önleme

İyi bir sürümden sonra yeni bir görsel veya kütüphane performansı bozabilir. Bu yüzden build raporunu ve dosya boyutlarını gözden geçirir, temel bileşen değişince Lighthouse'ı tekrar çalıştırırım.

Ölçüm sonuçlarını tarihleriyle saklarım; iyileşmenin kalıcı mı geçici mi olduğunu bilirim. Ayrıca sitemap, robots.txt ve Search Console indeksleme durumunu izlerim.

21. Yaygın optimizasyon hataları

• İçindeki metni düşünmeden tüm görselleri sıkıştırmak.
• LCP görselini lazy loading ile ertelemek.
• Gerekli JavaScript'i kaldırıp daha büyük biçimde geri eklemek.
• Lighthouse'a yalnızca bir kez güvenmek.
• Metinle ilgisiz anahtar kelimeler eklemek.
• Temel site değerini ayarlamadan sitemap üretmek.
• Sayfayı sağdan sola test etmeyi unutmak.

22. Yayın öncesi kontrol listesi

1. Production build hatasız çalışıyor mu?
2. Benzersiz title ve description görünüyor mu?
3. Her görselin boyutu ve uygun alternatif metni var mı?
4. Mobilde LCP hedefin altında mı?
5. Font ve görseller yüklenirken CLS kararlı mı?
6. Dil ve pencere düğmeleri klavyeyle çalışıyor mu?
7. Dahili makale bağlantıları doğru mu?
8. Sitemap ve robots.txt erişilebilir mi?
9. Gereksiz dış kaynak var mı?
10. Makale sayfası küçük ekranda test edildi mi?

Elde edilen sonuçlar ve sayılar

Daha sonra ne iyileştirilebilir?

Mevcut sonuçlar güçlü bir noktadır, ancak iş bitmiş değildir. Sonraki adımlar ziyaretçilerden gerçek veri toplamak, kalan görselleri iyileştirmek, font boyutlarını gözden geçirmek ve büyük görsellerle kırık bağlantıların geri gelmesini önleyen otomatik testler eklemektir. Sabit asset'ler için daha hassas cache politikası ve makale sayısı arttıkça makale performansını izleme de eklenebilir.

Sonuç

Performans kozmetik bir adım değil, ürün kalitesinin parçasıdır. Asset boyutunu azaltmak, JavaScript'i ayarlamak, Core Web Vitals'ı iyileştirmek, erişilebilir HTML yazmak ve doğru sitemap sağlamak, hız ile keşfedilebilirliği birlikte yükselten bağlantılı kararlardır. En iyi sonuç tek bir hileden değil, etkisi sayılarla kanıtlanabilen sürekli ölçüm ve küçük kararlardan gelir.

Performance philosophy for engineering platforms

A personal platform for mechatronics and embedded-systems projects should reflect precise engineering standards: high efficiency, low resource use, and immediate response.

In the latest Hasan TechLab update, I focused on software bottlenecks and performance scores in Google PageSpeed Insights and Google Lighthouse on desktop and mobile. The goal was not one high score, but a fast, stable, measurable experience in real conditions.

How did I measure performance before the change?

I recorded a clear baseline before changing any file. I reviewed desktop and mobile because network, processor, and memory change the result:

• LCP - Largest Contentful Paint: Time until the largest visible element appears.
• INP - Interaction to Next Paint: Interface response speed after user interaction.
• CLS - Cumulative Layout Shift: How much elements move during loading.
• TTFB - Time to First Byte: Time between the request and the first server byte.
• JavaScript, CSS, and image size, request count, and render-blocking resources.

The distinction between Lab Data and real-user Field Data matters. Lighthouse quickly finds bottlenecks, while real-user reports reveal old devices, slow networks, and different screen sizes.

Key improvements

1. Image dimensions and loading

• Problem: The profile image loaded at 1440×1440 pixels and about 101 KB while it was displayed at 38×38 pixels. This increased data use and delayed LCP on mobile networks.
• Solution: I resized and compressed the image to a lightweight web format close to its display size, saving more than 95% of this element's transfer size.

Choosing WebP or AVIF and sending the original image is not enough. Resource dimensions should match the expected display size, width and height should be declared, and srcset should be used when multiple sizes exist. An above-the-fold image needs appropriate loading priority; images below the viewport can load when needed.

2. Reduce JavaScript and resource cost

Every JavaScript file adds download, parse, and execution cost. I reviewed interactive code, kept only essential first-page behavior, and avoided loading a large library for a small task. Astro's static components send less JavaScript than a full client-side redraw.

The practical rule is that JavaScript should serve a clear interaction: opening a window, changing language, copying an email, or interacting with a project. Static text and the basic structure should arrive as ready HTML.

3. Stabilize layout and improve accessibility

Performance is inseparable from accessibility. Setting image dimensions, preserving heading order, giving buttons clear labels, and supporting the keyboard reduce visual confusion. Avoiding layout changes during loading directly lowers CLS.

4. Generate a dynamic XML Sitemap

• Problem: The sitemap was not generated in an organized form search engines could read directly.
• Solution: The official @astrojs/sitemap package was integrated into astro.config.mjs with the base site URL:

import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://hasantechlab.com',
  integrations: [sitemap()]
});

This keeps the sitemap updated when new pages or articles are added.

A sitemap alone does not guarantee indexing. Pages must be reachable through internal links, have clear title, description, and canonical URL, and not be blocked by robots.txt. After publishing, I check the file in Google Search Console and monitor indexing errors.

5. Improve technical SEO and content structure

The article uses one main heading followed by subheadings that describe a problem, solution, and result. This helps users and search engines. Keywords should occur naturally in the title, description, subheadings, and image alt text rather than through artificial repetition.

Terms describing this study include website speed optimization, web performance, Core Web Vitals, LCP optimization, CLS reduction, INP improvement, technical SEO, Astro Performance, Astro Sitemap, image compression, Google Lighthouse, and PageSpeed Insights.

6. Post-deployment verification plan

1. Run a production build instead of measuring development.
2. Inspect file sizes and render-blocking resources.
3. Run Lighthouse on desktop and mobile.
4. Test on a slow network and a small screen.
5. Verify sitemap-index.xml, robots.txt, and core links.
6. Monitor Search Console and real-user data once enough traffic arrives.

This cycle prevents improving one metric at the expense of another: deferring an important image can reduce page size but hurt LCP, while aggressively reducing JavaScript can break interaction or accessibility.

7. Examine the page-load journey

The page begins before the user sees its first character. The browser resolves the domain, creates a connection, sends a request, waits for the first byte, then parses HTML and discovers CSS, images, fonts, and scripts.

Any resource in this chain can become a bottleneck. I do not treat LCP as only an image problem; I trace it to DNS, TTFB, render-blocking CSS, or JavaScript delaying resource discovery.

Good diagnosis asks: when could the browser first have known about the resource, and what prevented it from using it?

8. Font strategy

Custom fonts improve visual identity but can cause FOIT or FOUT when managed poorly.

I use limited weights, avoid loading weights that do not appear, and set font-display: swap when showing text matters more than immediate visual matching.

With Google Fonts, review the effect of external DNS and TLS requests. On critical pages, host files locally and select a language subset instead of loading the entire Unicode set.

9. Render-blocking CSS

Large or unnecessary CSS can delay the first paint. Separate critical styles from styles the first viewport does not need.

This does not mean splitting files randomly. Measure CSS size and identify duplicate rules or rules from a library the page does not use.

Astro keeps HTML static, but CSS import style and component count still affect the final output.

10. JavaScript on the first page

Every script adds download, parse, and execution cost. Some interactions, such as language switching or opening project details, are necessary; the entire portfolio does not need to become a client application.

Keep important content in HTML and add interaction progressively. This improves SEO and keeps the page useful before JavaScript finishes.

Also avoid many listeners on similar elements when event delegation is possible, while preserving readability and keyboard behavior.

11. Measurable image optimization

Start by finding the actual display dimensions for each image. A 38×38 avatar does not need a 1440×1440 file.

Then choose a format for the content:

• WebP suits most images with good compression.
• AVIF may be smaller, but support and decode speed must be tested.
• PNG suits graphics needing transparency or precise edges.
• SVG suits simple icons, with attention to source and trust.

Do not use loading="lazy" for the image representing LCP. Images far below the viewport usually benefit from lazy loading.

12. Prevent Cumulative Layout Shift

CLS occurs when an element moves after the user sees it. Common causes are an image without dimensions, an ad without reserved space, or a font that changes text size.

Declaring width, height, or aspect-ratio gives the browser space before the resource arrives.

Do not add a notification bar after loading without reserving space, and do not let late fonts change button height.

13. Improve INP and interaction

INP measures page response to user interaction. A page that appears quickly is not enough if the language button or article window does not respond.

Long JavaScript tasks prevent screen updates. Split work, defer what is unnecessary, and reduce large DOM operations.

In the article interface, opening the window should be quick and code should not rebuild unrelated areas.

14. Reduce TTFB and cache

TTFB depends on server location, caching, page generation time, and third-party requests. Astro static pages reduce request-time generation, but CDN, Cache-Control, and deployment region still matter.

Cache-Control: public, max-age=31536000, immutable

Hashed assets can be cached for a long time. HTML and the sitemap need a shorter policy so updates arrive. Verify that cache does not serve an old robots.txt or sitemap.

15. Performance budget

Set a reviewable budget rather than saying “the site is fast”:

These are not universal laws, but they make regressions detectable in a Pull Request.

16. Lighthouse versus PageSpeed Insights

Lighthouse runs in repeatable lab conditions and is excellent for before-and-after comparisons.

PageSpeed Insights shows CrUX data when available, which is closer to real users on different devices and networks.

Do not interpret one result without context. Repeat the measurement, compare the median, and review mobile versus desktop distribution.

17. Test on a real phone

An emulator does not always represent an old phone with limited memory. Test on a real device, use a slow network or throttling, and watch text appearance and button response.

Manual testing finds problems numbers miss: a wrapped heading, a table leaving the screen, or a close button overlapping a window edge.

18. Technical SEO and content structure

Every page needs a clear title and a description that explains its value, not a keyword list. The title names the main subject, the description summarizes the result, and subheadings answer real questions.

Repeating the same phrase dozens of times can hurt quality. Related terms such as website speed, web performance, Core Web Vitals, and technical SEO should appear in useful context.

A sitemap helps a search engine discover titles, while internal links explain their relationship. Performance, OTA, and Ring Buffer articles therefore connect through clear context rather than generic links.

19. Accessibility is part of performance

A fast page that cannot be used with a keyboard is not a complete product.

Check tab order, visible focus, button text, contrast, and appropriate lang and dir values for the article.

Fixed image dimensions reduce CLS, while hierarchical headings and clear labels help screen-reader navigation. Accessibility and performance metrics intersect more than they appear to.

20. Monitoring and regression prevention

After a good release, a new image or library can degrade performance. Review the build report and file sizes, and rerun Lighthouse when core components change.

Keep measurement results dated so you know whether an improvement is lasting. Also monitor sitemap, robots.txt, and Search Console indexing.

21. Common optimization mistakes

• Compressing every image without considering text inside it.
• Lazy-loading the LCP image.
• Removing necessary JavaScript and adding it back in a larger form.
• Relying on Lighthouse once.
• Adding keywords unrelated to the text.
• Creating a sitemap without setting the base site.
• Forgetting to test the page right-to-left.

22. Pre-deployment checklist

1. Does the production build pass?
2. Are unique title and description visible?
3. Does every image have dimensions and suitable alt text?
4. Is mobile LCP below target?
5. Is CLS stable while fonts and images load?
6. Do language and window buttons work with the keyboard?
7. Are internal article links correct?
8. Are sitemap and robots.txt available?
9. Are there unnecessary external resources?
10. Was the article page tested on a small screen?

Results and achieved numbers

What can improve later?

The current results are a strong point, but they are not the end. Next steps include collecting real visitor data, improving remaining images, reviewing font sizes, and adding automated tests that prevent large images or broken links from returning. A more precise cache policy for static assets and article-page performance monitoring can follow as the collection grows.

Conclusion

Performance is not cosmetic; it is part of product quality. Reducing asset size, tuning JavaScript, improving Core Web Vitals, writing accessible HTML, and providing a correct sitemap are connected decisions that improve speed and discoverability together. The best result comes from continuous measurement and small decisions whose impact can be proven with numbers.