Lighthouse puanı almak normalde kolay, Chrome Developer Tool’u açıp sonucu alıyoruz. Bunu pipeline üzerinde yapmak isteyince işler biraz karmaşık hale geliyor 🥲
Benim derdim şuydu:
“Pull request açıldığında Lighthouse otomatik çalışsın, skoru yorum olarak gelsin, belirli bir puan altındaysa da beni uyarsın.” 🚦
Kulağa basit geliyor değil mi? Ben de öyle sandım 😄
Sonra Lighthouse’u GitHub Actions içinde çalıştırmaya başladım ve aynı sayfa için birbirinden alakasız skorlar görmeye başladım;
★ İlk çalıştırma: 72
★ İkinci çalıştırma: 89
★ Üçüncü çalıştırma: 81
Bir run’da performans kötü çıkıyor, bir sonrakinde gayet iyi, bir diğerinde yine düşüyor.
Aynı sayfa. Aynı branch. Aynı gün.
Ama bambaşka skorlar…
O an fark ettim ki benim çözmeye çalıştığım şey aslında “Lighthouse çalıştırmak” değilmiş.
Asıl soru şuymuş:
“Lighthouse’u CI içinde nasıl benzer skorlar alacak hale getiririm?” 🤔
Tek seferlik Lighthouse ölçümü CI ortamında fazla nazlı davranıyor.
★ Bazen network dalgalanıyor
★ Bazen runner yavaşlıyor 🐢
★ Bazen cache etkisi giriyor 🧊
★ Bazen de hedef site art arda gelen istekleri sevmiyor
Pipeline bazen gerçekten performans düştüğü için değil, sadece ölçüm tutarsız olduğu için kırılıyor
Bu da bir süre sonra çok sinir bozucu hale geliyor 😅
Benim için en kritik nokta şuydu:
Tek bir run’a güvenmemek.
Bir kez ölçüp karar vermek yerine, birkaç kez ölçüp ortalma skoru almak çok daha mantıklı oldu
Çünkü bazen bir run çok kötü geliyor, bazen aşırı iyi geliyor,
bence ortalama değer ise daha dengeli bir sonuç veriyor
CI içinde Chrome başlatıp kapatmak da ayrı macera 😅
Bir şey hata verdiğinde arkada process kalırsa sonraki run’lar da saçmalamaya başlıyor.
O yüzden tarayıcı lifecycle’ını güvenli yönetmek benim için önemliydi.
Küçük gibi görünüyor ama CI’da bu detaylar gerçekten önemli
Ayrıca ard arda aynı urle istek atınca bazen Lighthouse bunu bot gibi algılayabiliyor. Ben de run’ların arasına biraz bekleme ve biraz rastgelelik ekledim.
💡 Tabi bunun bazı dezavantajları da var 😅. Eğer ölçüm yaptığınız sayfa sayısı çoksa, pipeline süresi uzun sürer. Doalyısıyla sadece SEO açısından önemli olan Lighthouse puanı düşük olan ve sürekli ölçüm yaptığımız sayfalar için kullanmakta yarar var.
Peki Ben Ne Yaptım? 🛠️
Kendi GitHub Action’ımı yazdım: lighthouse-guard 🛡️
Amacım çok basitti:
★ Kurulum gerektirmesin, direkt Github üzerinde çalışsın
★ Skorlar daha stabil gelsin 📊
★ Eğer istersem sonuçları Slack’e bildirim göndersin 🔔
★ PR içinde okunabilir sonuç versin 💬
Kendi websiteme entegre ettim, incelemek isterseniz;
lighthouse action başarılı olduğunda 👇
https://github.com/yasinatesim/yasinates.com/pull/49#issuecomment-4105926556
lighthouse action pipeline’ı kırdığında 👇
https://github.com/yasinatesim/yasinates.com/actions/runs/23407111830/job/68087826160
Sonuç Ne Oldu? 🚀
Ortaya benim işimi gerçekten kolaylaştıran bir şey çıktı:
★ Daha stabil skorlar
★ PR yorumları
★ HTML dashboard artifact’i
★ Slack bildirimi
★ Threshold altındaysa kırılan pipeline
Ve en güzeli de şu oldu:
Performans takibi “arada bir manuel baktığım bir şey” olmaktan çıkıp, PR sürecinin doğal bir parçası haline geldi 🙌
Neden Bu Aracı Geliştirdim 👀
Çalıştığım şirketlerde bulunduğum projeler ve kendi projelerimdeki deneyimlerimden yola çıkarak bu aracı geliştirdim. SEO odaklı ve performans kaybı olmadan geliştirme yapmak, Frontend geliştirmenin en önemli parçalarından birisi
Repo 👇
github.com/yasinatesim/lighthouse-guard
📬 Geri Bildirim
Makaleyi yazarken, kaynakları belirleme ve araştırma için kendi notlarımı, yazım denetimi ve ek araştırma için Claude Opus 4.6 modelini kullandım. Resimleri üretmek için ise Gemini 3 Pro Preview 2k (Nano Banana Pro) modelini kullandım.
Yazı ile ilgili tavsiye, öneri, eleştirileri dikkate alıyorum. İletişime geçmek isterseniz bana websitemdeki sosyal medya adreslerimden veya Linkedin üzerinden ulaşabilirsiniz.
Sevgiyle kalın, Yasin 🤗
📚 Makaleyi Yazarken Kullandığım Kaynaklar
- https://github.com/GoogleChrome/lighthouse-ci
- https://github.com/marketplace/actions/lighthouse-ci-action