Core Web Vitals: Yeni Google Sayfa Deneyimi ve Hız Performansı Sıralama Faktörleri

Web site hızı performansının ve kullanıcı deneyiminin;

• Sektörünüz,
• Ürününüz,
• Hedef Kitleniz,
• Müşterileriniz,
• Satışlarınız

için önemli olduğunu düşünüyor musunuz?

2017-18 yıllarında Google tarafından yapılan sektörel araştırma benchmark raporlarında web uygulamanız (web site, SPA, App etc.) mobile cihazlarda 1 saniye geç açıldığında, bu size 20% dönüşüme mal oluyor. Saatlerce üzerinde çalıştığınız harika tasarımlar, daha verimli kullanıcı deneyimi için oluşturduğunuz bilgi mimarileri + wireframeler, özenle seçtiğiniz görseller + yazı tipleri ve derin bir araştırmayla ürettiğiniz içerikler. Tüm emekler web siteniz geç açıldığında 2020 ve sonrası SEO dünyasında pek de ehemmiyeti olmayacak gibi. 

Teknoloji geliştikçe insanoğlu bilgiye, hizmete ve ürüne daha çabuk ve daha hızlı sahip olma arzusuna erişti. Zaten teknolojinin en önemli faydalarından biri de zaman kazan(dır)mak. İnsanlar hızla elde edilen bilgi, ürün ve hizmetle daha da tatmin olmaya başladı ve en ufak bir gecikmede hepimiz sinir krizleri geçiriyoruz. Bu tatminsizliğe istinaden hızlı ulaşabilmek için uçaklar, uçan arabalar, dronelar, insansız hava araçları, daha hızlı arabalar, fiber internetler vs. derken hızın daha da köle olduk. 

Zihnimin Kıvrımları Podcast serisinde Serdar Kuzuloğlu bu duruma gayet açık ve net şekilde dikkat çekerek özellikle Zamanın Keşfi ve Telaş Çağı bölümlerinde ayrıntılarıyla değinmektedir. 

Web Site Hızı Satışlarınızı Nasıl Etkiler?

Gelelim konumuza. Site hızı SEO çalışmalarında sıklıkla üzerinde durulan önemli metriklerin başında gelmiştir. Kurgulanan SEO stratejilerinde ve oluşturulan yol haritalarında sıklıkla yer buldu kendine. 1 Haziran 2019 itibari web sitelerini mobil-öncelikli indexleme geçiş yapmaya başlayan Google için Mobile cihazlarda hız konusu hayati önem arz ediyor. 

Webmaster forumlarında, düzenlediği Webmaster sessionlarında, yazılım mühendislerinin geliştirdiği eklentiler ve web storylerinde görebiliyoruz ki Google pazarda pagespeed performansına en çok önem veren arama motoru. Kendisinin yaptığı aynı araştırma çalışmasında, web uygulamalarınız mobile ortamda olumsuz ve kötü bir deneyim sunuyorsa, hedef kitlenizin 62% gibi büyük çoğunluğu gelecekte sizden daha az satın alım yapacaktır.

Keza online alışveriş yapan müşterilerin 40%’ı yaşadığı olumsuz ve kötü alışveriş deneyimini çevresine anlatmaktan hiç de imtina etmiyorlar.

Devam edecek olursak, Hubspot Website Hızı Dönüşüm Oranını Nasıl Etkiler adlı çalışmasında sizinle olan online deneyimlerinden memnun kalıp web uygulamalarınıza tekrar dönen hedef kitle, olumsuz ve kötü bir deneyim yaşadığında, bu kitlenin 80%’i ilerleyen dönemlerde sizden tekrar alışveriş yapmayacaktır. Bu. Oldukça. Büyük. Bir. Kitle!  

Yine Walmart şirketinin müşterilerinin online satın almalarda ve arama alışkanlıklarını göz önüne alan araştırmasında web site hızının ne kadar hayati olduğunu ortaya koyuyor. 

Google, geliştirdiği algoritmalar ve altyapısıyla eriştiği + taradığı + indexlediği trilyonlarca web sayfası için düşündüğümüzden daha çok efor + kaynak sarf ediyor. Google’a göre;

“The Google Search index contains hundreds of billions of webpages and is well over 100,000,000 gigabytes in size.”

Durum bu iken haliyle Google bu tabiri caizse, çöplüğü temizlemek için son zamanlarda bir dizi güncelleme + altyapı iyileştirmesi yaptı. Bu sürece Yapay Zekayı da dahil ederek hem crawl budget limitini daha etkili kullanmaya başladı hem de bu teknolojik altyapı kullanımı için yapay zekayı kullanarak Sunucularda soğutma giderlerini 40% düşürdü. 

Aynı zamanda, Google artık her URLi indexlemiyor. Gerçekten kullanıcıya fayda sağlayan ve verimli bir kullanıcı deneyimi sunan web sayfalarını indexlemeye başladı.

Bittabi, Core Web Vitals güncellemesi yalnızca pagespeed faktörlerini değerlendirmiyor. 2021 UX’in yılı olacak 🙂 Dolayısıyla, yalnızca ışık hızında açılan sayfalar değil, bütünsel yapısıyla ve tüm varlığıyla kullanıcı için en iyi ve verimli deneyimi sunan web sayfaları uzun vadede kazançlı olacak.

Sayfa Deneyimi İle Google Bize Ne Anlatmak İstiyor?

Web Sayfası Deneyimi sinyalleri ile Google, kullanıcıların web sayfası ile olan etkileşimlerini algılamaya çalışır. Algılanan performans ise, bir web sayfasının ne kadar hızlı bir şekilde kullanıcıya anlamlı zengin bir görüntü oluşturduğudur. Mozilla bu konuda detaylı bir içerik hazırladı. Birçok yan parametre ile birlikte üzerinde sıkça durulan sinyalleri aşağıda inceleyelim:

• Mobile Friendliness (Mobile Uyumluluk): Web sayfanız mobile cihazlarla görüntü kararlılığına ve etkileşime duyarlı ve kullanışlılık olarak uyumlu mu?
• Safe Browsing (Güvenli Arama): Sayfalarınız Kullanıcılarınız için tehlike oluşturabilecek güvenlik açığı veya malware gibi içerikler içeriyor mu?
• HTTPS Security (HTTPS Güvenliği): Sayfalarınız kullanıcıların bilgilerini güvenli bir ortamda barındıracak gerekli lisans ve güvenlik sertifikalarına sahip mi?
• Intrusive Interstitials: Sayfalarınız kullanıcıların ekranlarında gereksiz kapatmalar ile içeriğe erişimi, etkileşimi minimize edecek sabit pop-uplar içeriyor mu?  
• Core Web Vitals: Sayfalarınız yüklenirken, etkileşim gerektiren görüntü kararlılığına/stabilizasyonuna sahip olup kullanıcıyı yanıltacak veya olumsuz bir davranışta bulunmasına sebebiyet verecek kötü bir deneyim sunuyor mu?

Web sayfalarınızda verimli bir kullanıcı deneyimi oluşturmak için mümkün mertebe tüm sayfa deneyimi bileşenlerini bir arada bulundurmalısınız. 

“Looking ahead towards 2021, we are investing in building better understanding and ability to measure page speed, and other critical user experience characteristics.

For example, extending the ability to measure input latency across all interactions, not just the first; new metrics to measure and quantify smoothness; primitives and supporting metrics that will enable delivery of instant and privacy preserving experiences on the web; and more.”

Her zaman kendinizi bir kullanıcı gibi düşünün. Hızlı yüklenen sayfalar + cihaz fark etmeksizin tüm içeriğin en iyi deneyimi ve görüntüyü sunması + Güvenli bir ortamda olduğumuzu bilmek + dönemin şartlarında rahatlıkla paylaştığımız bilgilerimizin güvende olduğunu bilmek + bizi sinir edecek ekran kapatan ve sağdan soldan çıkıp sürekli kapatıp durduğumuz pop-upları minimize etmek + Sağlıklı ve hoş bir deneyimle ayrılmak hemen hemen tüm kullanıcıların aradığı bir süreç.

Core Web Vitals Nedir?

Web sitesi performansı üzerine yapılan çalışmalar ilk değil ve son da olmayacak. İnsanlar web uygulamalarını hızlandırmak için günümüze kadar birçok geliştirme yaptı. SEO dünyasında 2020 ilk çeyreği gündemini işgal eden ve Mayıs 2020 tarihinde Google, sıralama algoritmasında önemli değişiklikler yapacağını resmi olarak duyurdu. Core Web Vitals adını verdiği ve son doğrulamalara göre Mayıs 2021 itibari ile yalnızca Mobile ortamda sıralama faktörü olacağını belirtti. 

Bu geliştirmenin/güncellemenin amacı;

Daha verimli ve performanslı sayfa deneyimine odaklanan Organik Sıralama Sinyallerini hesaba katarak en iyi performansı sunan web sayfalarını listelemek.

Core Web Vitals web sayfalarının hız performansına, uyumluluğuna ve görüntü kararlılığına/stabilizasyonuna odaklanan ve web site sahiplerinin uygulamalarını verimli bir kullanıcı deneyimi için daha iyi optimize etmelerini sağlayan kullanıcı-merkezli metrikler setidir.

Hali hazırda sıralama sinyalleri arasında olan Mobile-uyumluluk, güvenli arama, HTTPS güvenliği ve kullanıcı ekranlarında geçişleri denetleyen intrusive interstitials yönergeleri ile birlikte;

• LCP: Largest Contentful Paint,
• FID: First Input Delay,
• CLS: Cumulative Layout Shift

Metrikleri de sıralama sinyalleri arasına katıldı. Bunlardan en çok ses uyandıran ise Cumulative Layout Shift metriği oldu. 

Mahşerin 3 Atlısı — Core Web Vitals Bileşenleri: Largest Contentful Paint, First Input Delay, Cumulative Layout Shift

Efsaneler ölmez şekil değiştirir.

Google yıllardan beri farklı farklı yöntemlerle web sayfalarının hız performansını analiz etti ve etmeye devam ediyor. Özellikle, son zamanlarda Front-End ve Back tarafında çok fazla gelişme yaşandı. Kodlama verimliliğini arttırmak için geliştirilen JS kütüphanelerinde yaşanan bolluk, CSS tarafında bootstrap ile birlikte artan talep ve Back-End tarafında Code Quality Efficiency arttırmak adına yapılan geliştirme çalışmalarının hepsi günümüzde birçok alanda ve web sitesinde görmek mümkün. 

Google Core Web Vitals metrikleri ile adeta web site hız performansını nasıl iyileştirebileceğinizle ilgili rehberler hazırlamakta. Web sayfası performansına dayalı Sayfa Deneyimini iyileştirme algoritması nedeniyle geliştirdiği 3 temel Core Vitals bileşenini inceleyelim.

Web sayfası hız performansını analiz ederken belli bir skore üzerinden ölçümleme yapmak her zaman daha cazip ve tatmin edici gelir. Zaman içinde Pagespeed Insight gibi araçların evrim geçirerek farklı metrikler ile söz konusu web sayfamızın performansı ile ilgili öngörüler sundu. TTFB, FCP ve benzeri gibi metrikler ile durumu anlamaya çalıştık lakin buz dağının yalnızca görünen kısmıyla yetinemeyeceğimizi de anladık. 

LCP, FID ve CLS metrikleri ile web sayfasının hız performansını Google aşama aşama ölçmeye çalışırken bize de hikayeyi anlatmaya çalışıyor. 

1. LCP — Loading (Yükleniyor): Sayfa yüklenirken içeriğin anlamlı bir bütünlük kazanması ne kadar zaman aldı?
2. FID — Interactivity (Etkileşim): Sayfa yüklendiğinde ekran ve ekrandaki bileşenler kullanıcıların etkileşimine ne kadar duyarlı?
3. Visual Stability (Görüntü Kararlılığı/Stabilizasyonu): Sayfa yüklenirken ve yüklendikten sonra görüntü bileşenleri ne kadar stabil veya kayıyor? 

Largest Contentful Paint — Loading (Zengin İçerikli Görüntü) 

Largest Contentful Paint, Türkçe’si ile Zengin İçerikli Anlamlı Görüntü diyebileceğimiz metrik bir sayfanın yüklenirken gerçek kullanıcının gözünde ilk ekranda oluşan görüntünün ne kadar vakit aldığını ölçer. 

Bir diğer adıyla, kullanıcı bir linke tıkladığında ekranda oluşan görüntünün anlamlı bir hale gelmesine kadar geçen süreyi hesaplar. Örneğin; linke tıkladığınızda Sayfa Adının görünmesi, logonun görünmesi, varsa ilgili görselin yüklenmesi veya bir form gelecekse, form görünümünün gelmesi gibi.

Largest Contentful Paint metriği FID metriğinin başlamasına yakın bir noktadadır. Yani, kullanıcının etkileşime geçmeye başlaması için görüntünün anlamlı bir hale gelmesi durumudur. TTFB (Time To First Byte) veya First Contentful Paint (İlk Anlamlı Görüntü — FCP) gibi metriklerle karıştırılamamalıdır. Öncesinde, Hem teknik anlamda hem de site sahibi olarak site hızını ölçerken görece metriklerden faydalanırdık. DOMContentLoaded gibi metrikler web sayfası hızını ölçümlemede bir öngörü sunabilir lakin son kullanıcı nezdinde anlamlı bir görüntü sunmayıp daha çok teknik yeterlilik bakımından öğelerin eksiksiz yüklenmesi ile ilgilenir. 

Ayrıca, diğer metriklerden;

• Daha iyi anlamda kullanıcı deneyimi ile ilişkilendirilmeyi,
• Görüntünün nedenini ve amacını saptamayı,
• Gereksiz yoruma açık göreceli değerlendirmeleri ortadan kaldırmayı,
• Bir sayfa için gerekli temel içeriğin yüklenmesi için hayati tüm elementlerin ölçümlenmesini amaç edinir. Örneğin; DNS Lookup, TLS & SSL Negotiation, HTML, CSS, JS, Fonts, Images etc. Asenkron yüklenen ve lazy-loading ile DEFER edilen (yüklenmesi ertelenen) kaynaklar hariç.

Largest Contentful Paint metriği aşağıda belirtilen 5 aşama sonrasında gerçekleşir:

1. Sunucuya gerekli kaynaklar için Request oluşturulur, DNS Lookup Yapılır ve TCP Connection bağlantısı açılır.
2. Bağlantı sağlandıktan sonra TLS & SSL doğrulaması yapılır.
3. HTML kaynağı Sunucudan çağrılır ve alınan cevapla birlikte HTML parse edilir.
4. İlk görüntüyü oluşturmak için gerekli Kritik Kaynaklar (CSS, JS etc.) indirilir, parse edilir ve ayrıştırılarak işlenir.
5. LCP için gerekli kaynaklar (Görseller, Fontlar, Videolar etc.) indirilir ve render edilir. 

Web sayfasının hız performansını iyileştirmek için yapabileceğiniz en iyi geliştirme gerekli kaynakların yüklenmesini mümkün olduğunda hızlandırmaktır. Unutmayın ki, kaynakların teslimatını 150 ms erken yaparsanız, bu kaynakların anlamlı bi görüntü oluşturarak kullanıcı tarafında verimli bir deneyim oluşturması 150 ms erken gerçekleşir. 

Aşağıda Icerikbulutu.com sitemiz için WebPageTest.org aracı ile 3G bağlantı ortamında Motorola G4 Mobile cihazı emulate edilerek yapılan ölçümleme verilerini görebilirsiniz. Aynı zamanda, hangi aşamanın ne kadar vakit aldığını da kaynak özelinde inceleyebilirsiniz.

Yaptığım web site hızı performans testlerinde sıklıkla karşılaştığım ve kaynakların teslimatında vakit alan major öğeler;

• DNS Lookup & Prefetch
• TCP Connection
• TLS & SSL Negotiation
• TTFB
• HTML
• Preconnect
• Preload
• Async & DEFER

Sunucuya gerekli kaynaklar için Request oluşturulur, DNS Lookup Yapılır ve TCP Connection bağlantısı açılır. Bağlantı sağlandıktan sonra TLS & SSL doğrulaması yapılır. HTML kaynağı Sunucudan çağrılır ve alınan cevapla birlikte HTML parse edilir. Bu süreçte en çok öncelik verilen kaynaklar browser tarafından CSS ve JS kaynakları olur. Sonrasında multimedia kaynakları yüklenir. Eğer browser web sayfasını oluşturma sürecinde render-blocking olan bir kaynakla karşılaşırsa, — ki genelde async ve defer uygulanmamış CSS ve JS kaynaklar olur bunlar — HTML ayrıştırma ve işlenme sürecü duraklatılarak CSS ve JS kaynakları indirilir + ayrıştırılır + işlenir/render edilir. 

Aşağıda Render-blocking niteliği taşıyan CSS ve JS kaynakları için ASYNC ve DEFER işlemlerinin amacı anlatılmıştır.

Önemli!: JS kaynaklarını DEFER etmelisiniz lakin DEFER edilmiş JS kaynakları Execute olduktan sonra, Render edilen JS kaynakları ile kullanıcı arayüzüne yeni bir frame eklenerek arayüz kayıyorsa, bu da CLS değerinin artmasına olumsuz etki eder.

Yeterli ve Verimli bir LCP Verisi Nedir?

Bir web sayfasının verimli ve kullanışlı bir anlamlı görüntü sunması için maksimum 2.5 saniye içerisinde gerekli görüntüyü kullanıcıya sunmalıdır. Web sayfanızın ilk ekranda yüklenen görüntüsü için en verimli eşik ise Google’ın belirttiğine göre 75% baseline olarak verildi. Eğer bu değer 4 saniyeyi aşıyorsa, — ki aşmıyorsa bile, daha verimli çıktılar için optimizasyon yapmalısınız.

Largest Contentful Paint metriğini Google Search Console üzerinden Core Web Vitals bölümünden Mobile ve Desktop olarak ayrı cihaz kategorisi bazında inceleyebilirsiniz.

Google Search Console aracında Core Web Vitals bölümünden LCP metriğine tıkladığınızda Google size söz bulunduğunuz mülkte kaç tane URL Adresinin etkilendiğini söyler. Aynı zamanda Detaylar bölümünde de örnek birkaç URL Adresini diğerleriyle birlikte gruplandırarak size sunar. 

Largest Contentful Paint Nasıl Optimize Edilmelidir?

Largest Contentful Paint değerini 2.5 saniye altında tutmak ve daha da minimize etmek için yapabileceğiniz optimizasyon çalışmalarını aşağıda paylaşıyorum:

1. Sunucu yanıt süresini mümkün mertebe kısaltın.
2. DNS-Prefetch yaparak, kaynakların çağrılacağı sunucuya erken DNS lookup yaptırın.
   1. DNS-Prefetch optimizasyonu yaparken hız performansını hantallaştıracak 3rd party entegrasyonlar için bunu devre dışı bırakın. Sayfanızın yüklenmesi, Hotjar, Criteo, Segmentify gibi 3rd party entegrasyonlardan daha önemli.

1. PRECONNECT optimizasyonu ile kaynakların yükleneceği sunucuya erken istekte bulunun.
   1. PRECONNECT optimizasyonu yaparken hız performansını hantallaştıracak 3rd party entegrasyonlar için bunu devre dışı bırakın. Sayfanızın yüklenmesi, Hotjar, Criteo, Segmentify gibi 3rd party entegrasyonlardan daha önemli.

1. PRELOAD optimizasyonu ile kaynakları önceliklendirin.
2. Mümkün mertebe kullanılmayan JS kaynaklarını DEFER edin. 
3. İçerikleri en yakın sunuculardan kullanıcılara ulaştırmak için CDN altyapısı kullanınç
4. Statik kaynaklar /JS, CSS, IMGs, Fonts, Videos etc.) için ayrı bir CDN altyapısını yine ayrı bir (Sub)domainde tutun.
5. Tarayıcı önbellekleme özelliğinden yararlanın.
6. Statik kaynaklar için Cache politikanızı güncelleyin.
7. Farklı kaynakların dosya boyutunu optimize edin.
   1. Development Stage sürecinde yazılımcılar rehberlik etsin diye sürekli yorumlarda bulunurlar. Canlıya çıktığınız bu kaynakları (HTML, CSS, JS etc.) Minify edin ve gereksiz dosya boyutundan kurtulun.
   2. Görsellerin dosya boyutunu optimize edin.
   3. WEBP ve WEBM gibi uzantılardan yararlanın. 
   4. Srcset ile farklı ekranlar için tahmini ölçüleri varyant olarak bulundurun.
8. İlk ekran dışında kalan görselleri erteleyin. Lazy-load edin.
9. Sayfa bazlı JS ve CSS kaynaklarını bölün. Sepet veya Ödeme sayfasının CSS veya JS dosyası neden ana sayfada yükleniyor?
10. Mobile cihazlarda kimsenin izlemediği Timer ile ayarlanmış birkaç saniye sonra kendiliğinden geçiş yapacak sliderlar için JS çalıştırmayı durdurun.
11. HTTP/1.1 1999 yılından kalma ilkel bir protokol. Kullanıcı gizliliğine önem veren HTTPSi de sürece dahil ederek HTTP/2 — hatta geç kaldık biz doğrudan HTTP/3+QUIC e geçelim. 
12. GZIP veya BROTLI kullanarak kaynakları sıkıştırın. Unutmayın, ülkeler arası yük taşımacılığında giydiğimiz jilet gibi elbiseler vs. hepsi kompress ile sıkıştırılıyor ve öyle ulaştırılıyor.
13. Yapabiliyorsanız, Kritik CSS Kaynaklarını INLINE edin. İlk etapta belli bir maksimum ekran ölçüsü baz alarak, ilk ekran için gerekli CSS kodlarını INLINE yükleyin.
14. İçerikleri Statik ve Raw HTML tabanlı yüklemeye çalığın. Client-Side Renderingden vazgeçin ve Server-Side Rendering için var gücünüzle çalışın.
15. Front-End ve Back-End kod kalitesini iyileştirin. Derinlere nüfus eden DOM oluşumunu önlemek için daha flat bir yapı kurmalı ve optimize etmelisiniz. Tarayıcı sayfa için gerekli iskeleti DOM + CSSOM ile yapılandıracağım derken, zaten düşük bağlantı ortamında sabırsız kullanıcılar durmadan tıklayacaklardır. Bunun önüne geçin.
16. İlk Ekranda yoğun JS kaynağı kullanacak elementleri elimine edin.
17. Icon formatında küçük görseller için CSS-Sprite yöntemi ile birleştirin. 
18. Web fontlarının yüklenmesi ve özelleştirilmiş yazı tiplerinin değişimi sırasında içeriklerin görünür olmasına dikkat edin.
19. Yönlndirme zincirlerini kırın. Zincirdeki halka sayısını azaltın. 

First Input Delay — Interactivity (Etkileşim)

Bir web sayfasını ziyaret ettiğinizde o web sayfasının bağlı bulunduğu tüm web sitesi yüklenmez. Tarayıcı yalnızca, söz konusu sayfa için gerekli kaynakların yüklenmesi ihtiyacı için Sunucuya istekte bulunur ve o sayfanın bütünüyle anlamlı ve kullanışlı bir görüntü vermesi için gerekli çağırma + yükleme + ayrıştırma + işleme süreçlerini yönetir. Bulunduğunuz bu sayfada edindiğiniz yeterli izlenim ve edindiğiniz deneyim ile sayfa üzerinde bulunan butonu, linki veya sayfayı scroll etmeyi devam ettirirsiniz. Sayfa üzerinde bulunan bu elementlerden birine tıkladığınızda olay işleyicisi tetiklenen işlem için beklenen  amaç doğrultusunda gerekli kaynakları tekrar yeni sayfa veya olay için tekrarlar ve işleme alır. Yeni ekranda İlk anlamlı boya (First Contentful Paint) oluştuğunda ve duyarlı şekilde cevap verecek etkileşim oluşturan elemente tıklama zamanına kadar oluşan gecikmeye First Input Delay (İlk Giriş/Etkileşim Gecikmesi) denir.

Her sayfa için tekrar bu süreci olabildiğince kısaltmak için gerekli optimizasyonları içeriğin devamında bulabilirsiniz.

LCP konusunda işlediğimiz gibi JS kaynakları bir web sayfasısının etkileşimsel ve içeriksel olarak zenginliği için önemli bir varlık unsurudur. Tarayıcı her bir event için çalıştırdığı bu zaman diliminde gerçekleştirilen ve oluşan tüm durumlar için default bir önceliklendirme yapar. JS kaynakları da yapısı gereği render-blocking bir yapıya sahip olduğu için tarayıcu bu kaynakları önceliklendirmediğinizde varsayılan olarak gerekli indirme + ayrıştırma + işleme işlemlerini uygular fakat bu da sayfalar veya işlemler arası gecikmelere sebebiyet verir.

Bakın yukarıdaki çizelgede gösterilen gri satırlarda görüldüğü gibi, her bir sayfa yüklenmesi veya event tetiklenmesinde geçen sürede tarayıcının ağda yaptığı istek sayısını önceliklendirilmiş. Bu doğrultuda, birkaç uzun task yüklenene kadar kullanıcı bu zaman zarfında işlem yapmak için etkileşime geçtiğinde yapılan bu hareket algılanıp cevap verilinceye kadar geçen zmaan kadar gecikme yaşanacaktır. Burada önemli olan uzun taskları kısaltmak ve sabırsız olan kullanıcılar etkileşime geçtiğinde en kısa sürede cevap verebilmek.

Chrome Developer Tools ile Performance bölümünden  Icerikbulutu.com sitemiz için ana sayfası tüm kaynakları ile WI-FI bağlantı ortamında yüklendiğinde aşağıda grafikte gösterildiği gibi 5 saniyey yakın bir IDLE veriyor.

Yine, Icerikbulutu.com sitemiz için ana sayfası tüm kaynakları ile Fast-3G bağlantı ortamında yüklendiğinde aşağıda grafikte gösterildiği gibi 15 saniyeye yakın bir IDLE veriyor.

Buradan hareketle Bottom-Up bölümünden Group by URL ile hangi kaynağın ne kadar süre aldığını inceleyebilirsiniz. Icerikbulutu.com sitemiz JS dosyalarını DEFER ettiği takdirde, ilk ekran açılışında gereksiz ve uzun vakit alacak JS kaynaklarından epey bir tasarruf eder.

First Input Delay metriğini Google Search Console üzerinden Core Web Vitals bölümünden Mobile ve Desktop olarak ayrı cihaz kategorisi bazında inceleyebilirsiniz.

Google Search Console aracında Core Web Vitals bölümünden FID metriğine tıkladığınızda Google size söz bulunduğunuz mülkte kaç tane URL Adresinin etkilendiğini söyler. Aynı zamanda Detaylar bölümünde de örnek birkaç URL adresini diğerleriyle birlikte gruplandırarak size sunar. 

Yeterli ve Verimli bir FID Verisi Nedir?

Verimli ve sağlıklı bir sayfa deneyimi için olması gereken FID eşiği;

• İyi — 100 ms altında,
• Eh İşte! Geliştirilmeli / Orta — 100 ms – 300 ms arasında,
• Aman Allah’ım! Düşük — 300 ms üzerinde.

First Input Delay Nasıl Optimize Edilmelidir?

First Input Delay değerini 100 ms altında tutmak ve daha da minimize etmek için yapabileceğiniz optimizasyon çalışmalarını aşağıda paylaşıyorum:

1. Yüklenmesi + Ayrıştırılması + İşlenmesi uzun süren taskları kısaltın. 
2. 3rd Party entegrasyonları — mümkünse, kaldırın veya ertleyin,
3. Kritik olmayan Javascript kaynaklarını DEFER edin,
4. JS ve CSS dosyalarını Minify edin.
5. Javascript dosyalarını sayfa bazlı bölün. Webpack, bundling tarafında işini görecektir.
6. Javascript kaynaklarının performansını iyileştirin.
7. CSS dosyalarını asenkron yükleyin. PRELOAD işinizi çözecektir.
8. DNS-Prefetch optimizasyonu yapın,
9. Görseller için PRELOAD optimizasyonunu yapın.
10. Yazı Tipleri için için PRELOAD optimizasyonunu yapın.
11. Total Blocking Time değerini düşürün.
12. İçerikleri Statik ve Raw HTML tabanlı yüklemeye çalığın. Client-Side Renderingden vazgeçin ve Server-Side Rendering için var gücünüzle çalışın.
13. Bazı uzun taskları ve ağır yükleri yük dengeleyici görevi gören Web Worker ile aynı anda çok fazla işi görerek örneğin ağır işleyen JS süreçlerin hızlandırabilirsiniz
14. Idle until urgent methodunu kullanın. Gerekmedikçe lüzumsuz kaynakları yüklemeyin. Google mühendisi Philip Walton’ın yazdığı bu harika içeriği buraya bırakıyorum: https://philipwalton.com/articles/idle-until-urgent/ 
15. Kullanıcı-Merkezli Performans Modeli olan RAIL ile kullanıcıların her davranışını aşama aşama test edebileceğiniz ve bununla bir deneyim yaratabileceğiniz Responsive bir yapı oluşturun.

Cumulative Layout Shift —  Visual Stability (Görüntü Kararlılığı/Stabilizasyonu)

Bir web sayfasını ziyaret ettiğinizde sağdan soldan çıkan pop-up pencereleri ve bildirim uyarıları oldukça sinir bozucudur. Hangi birini kapatacağınızı bilemezsiniz. Bulunduğunuz ekranda herhangi bir butonla, linkle veya elementle etkileşime geçeceğiniz zaman kayması, aşağı – yukarı ya da sağa – sola hareket etmesi de hem kullanıcıyı yanıltır hem de oldukça sinir bozucu bir durumdur. 

Görüntü kararlığını olumsuz etkileyen ve oluşan görüntüde beklenmedik görsel kaymalara sebebiyet veren durumları temsil eden bir süreç/veri noktasıdır. Bir dondurmacıdan Maraş dondurması almaya çalıştınız mı hiç? 🙂 O dondurmacıdan O dondurmayı alana kadar sinir oluruz. Ya pes etmeyip dondurmayı alırız, tabi 1001 güçlükten sonra, ya da vazgeçeriz dondurmadan. Hepimiz zaman zaman şöyle durumlarla karşılaşmışızdır 🙁 bir butonu tıklarken oluşan kaymalardan dolayı yanlışlıkla başka bir şeyi tıklarız ve bambaşka bir dünyada buluruz kendimizi. Peki ya bir haberi okurken kendiliğinden yeniden yüklenen web sayfasına ne demeli? 

Google’dan Addy Osmani’ye göre CLS:

“Cumulative Layout Shift (CLS) – a Core Web Vitals metric, measures the instability of content by summing shift scores across layout shifts that don’t occur within 500ms of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.”

Kullanıcı-Merkezli performans problemlerine odaklanan Core Web Vitals metriklerinden en dikkat çekeni Cumulative Layout Shift bir web sayfasının yüklenmesi sırasında veya devamında kullanıcı sayfa üzerinde ziyaretini tamamlayıncaya kadar geçen süre içerisinde görüntü kararlılığını ve duyarlılığını ölçmeye ve korumaya odaklanan bir metriktir.

Görüntü olarak kullanıcıya güven vermeyen ve hali hazırda internet ortamında özel bilgilerini paylaşmaktan çekinen kullanıcılar için bu tarz güven zedeleyici durumlar markanıza olan güveni ve sadakati azaltır. Günün sonunda size dönüşüme ve paraya mal olacak e zarar verecektir. Google bu durumun çokça yaşandığını ve kullanıcıları aldatmaya yönelik birçok manipülasyonun yapıldığını fark etti ki böylesine yeni bir tedbiri alma gereği duydu. 

https://storage.googleapis.com/web-dev-assets/layout-instability-api/layout-instability2.webm

Tıpkı yukarıdaki videoda görüldüğü üzere kullanıcı kararlı şekilde bir butona tıklarken ekran kayarak başka bir buton sahneye giriyor ve kullanıcı aldata bir çıktıya sebebiyet veriyor. Dolayısıyla, görüntü kararlılığı önemlidir ve kimse ordan burdan ekrana giren, beklenmedik sıçramalar gerçekleşen görüntü kaymalarını sevmez. 

Cumulative Layout Shift, diğer metrikler gibi SEO ve kullanıcı deneyiminiz için önemlidir.

Cumulative Layout Shift metriğini Google Search Console üzerinden Core Web Vitals bölümünden Mobile ve Desktop olarak ayrı cihaz kategorisi bazında inceleyebilirsiniz.

Google Search Console aracında Core Web Vitals bölümünden CLS metriğine tıkladığınızda Google size söz bulunduğunuz mülkte kaç tane URL Adresinin etkilendiğini söyler. Aynı zamanda Detaylar bölümünde de örnek birkaç URL Adresini diğerleriyle birlikte gruplandırarak size sunar. 

Cumulative Layout Shift Neden Oluşur?

Görüntü kaymaları birçok faktöre bağlı oluşacağı gibi web sayfanızın yüklenirken sunucu tarafından yüklenen ektegrasyonlarların etkileşimi sonucu görüntü kaymaları oluşabilir. Aşağıda bu muhtemel nedenleri listeledik:

1. Ölçüleri belli bir alan için net olarak belirtilmemiş görseller,
2. Ölçüleri belli bir alan için net olarak belirlenmemiş iframe ve reklam yerleşimleri,
3. Asenkron yüklenen sayfa kaynaklarının neden olduğu görüntü kaymaları,
4. Dinamik şekilde ekrana enjekte edilen/yüklenen içerikler,
5. Özelleştirilmiş Yazı Tiplerinin Neden Olduğu FOUT ve FOIT değişimi,
6. DOMa bağlı içerikler yüklenmeden önce onaylanması beklenen beklenen ağ istekleri,
7. Animasyonlar ve ekran kaymaları,
8. Mobile cihazlarda ekran görünümünü koruması için optimize edilmemiş Viewport Meta Data,

Cumulative Layout Shift Nasıl Hesaplanır?

https://twitter.com/JohnMu/status/1265990156705808385?s=20  John Mullerin de bu Tweetinde belirttiği gibi Etki Aralığı ve Mesafe Aralığı değerlerinin çarpılması ile hesaplanıyor. 

Tarayıcı söz konusu sayfanın CLS değerini hesaplamak için görüntü alanında ve beklenmedik hareket eden elementlerin bulunduğu alan ve kaydığı alan arasındaki değerlere bakar. CLS metriğinin hesaplanma formulu aşağıdaki gibidir.

Layout Shift Score = Impact Fraction * Distance Fraction

Örneğin; Impact Fraction değerinin 1,0 olduğunu;  Distance Fraction değerinin 0,3 olduğu bir durumda Layout Shift Score = 1,02 * 0,3 hesabına göre  Cumulative Layout Shift Değeri 0,306 olacaktır.

Cumulative Layout Shift Nasıl Optimize Edilmelidir?

Cumulative Layout Shift değerini 0.1 altında tutmak ve 0’a çekmek için yapabileceğiniz optimizasyon çalışmalarını aşağıda paylaşıyorum:

• Özelleştirilmiş yazı tiplerinin yüklenirken ekran kayması yapmasını önlemek için https://meowni.ca/font-style-matcher/ gibi araçlar kullanarak Font uyumluluğunu kontrol etmelisiniz.
• Özelleştirilmiş yazı tiplerinin yüklenirken ekran kayması yapmasını ve FOUT veya FOIT değişimini önlemek için önlemek için font-display:swap kullanmalısınız. Google Web Font kullanıyorsanız, bunu son güncellemelerle birlikte default geldiğini göreceksiniz. Ayrıca, WordPress gibi CMS altyapılarında Litespeed veya Autoptimize eklentileri ile Google Fontları Swap yüklensin seçebiliyorsunuz.

• Yazı Tiplerini PRELOAD ile asenkron yükleyin.
• Ölçüleri belli bir alan için net olarak belirlenmiş görseller kullanın. Genellikle Responsive tasarıma uygun görsel kullanımında bu tip problemlerle karşılaşılır. width: 100%; olarak ayarlanır.

 <img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons"> 

Veya srcset ile her ekran ölçüsü için tahmini görsel varyantları ekleyin.

<img width="1000" height="1000"
      src="puppy-1000.jpg"
   srcset="puppy-1000.jpg 1000w,
           puppy-2000.jpg 2000w,
           puppy-3000.jpg 3000w"
          alt="Puppy with balloons"/>

• Ölçüleri belli bir alan için net olarak belirlenmiş iframe ve reklam yerleşimleri için en boy oranını ayarlayın. 
• DOMa bağlı içerikler yüklenmeden önce onaylanması beklenen beklenen ağ isteklerini hızlandırmak için PRECONNECT ve DNS-Prefetch optimizasyonlarını yapın.
• Mobile cihazlarda ekran görünümünü koruması için Viewport Meta Data optimizasyonu yapın. Böylelikle, ekranı duyarlı olmayan veya ekranı büyütmek isteyen kullanıcılar için yanıltıcı bir deneyime sebebiyet vermemek için görüntü alanını koruyun.
• Hangi cihazda olursa olsun ölçüleri belli bir alan için net olarak belirlenmiş iframe ve reklam yerleşimleri için önceden yer ayırtın. Google Tag Manager ile reklamların asenkron yüklenmesini ve GTM alan adını PRECONNECT + DNS-Prefetch yaparak mümkün mertebe hızlı şekilde yükletin.
• Front-End ve Back-End kod kalitesini iyileştirin. Derinlere nüfus eden DOM oluşumunu önlemek için daha flat bir yapı kurmalı ve optimize etmelisiniz. Tarayıcı sayfa için gerekli iskeleti DOM + CSSOM ile yapılandıracağım derken, zaten düşük bağlantı ortamında sabırsız kullanıcılar durmadan tıklayacaklardır. Bunun önüne geçin.
• Animasyonlar için transform özelliğini kullanın.

Detaylı Optimizasyon çalışmaları için Addy Osmani’nin videosunu izlemenizi öneriririm:

Cumulative Layout Shift hakkında daha detaylı bilgi almak için Koray’ın yazdığı içeriğe göz atabilirsiniz. Yusuf Özbay’ın CLS hakkında erken dönem yazdığı içeriğe de göz atmanızı öneririm.

Web Sitenizin Core Web Vitals Değerlerini Nasıl Ölçebilirsiniz?

Bir Web sayfasının deneyim ve hız performansını ölçmek için Google bir yığın parametre arasında özenle seçerek sayfa deneyimini iyileştirme faktörlerini belirtmiştir. Core Web Vitals metriklerini 4 önemli temele oturtarak muhtemel en iyi ölçümleme yapmak amaçlanmıştır;

1. Laboratuvar Ortamı Verileriyle, — ki bu veriler gerçek dünyadan gerçek kullanıcının bağlantı şartlarını simüle/emulate ederek yaptığı çıkarsamalar;
   1. Lighthouse,
   2. Pagespeed Insight
   3. Chrome Dev Tools,
   4. Core Web Vitals Eklentileri,
   5. GTMetrix,
   6. WebPageTest,
   7. Speedcurve,
   8. Pagespeed.compare
   9. Treo.sh/pagespeed
2. Doğrudan Kullanıcı Verileriyle, — ki bu veriler gerçek dünyadan gerçek kullanıcıların bağlantı şartlarının GEOlocation, Device-based (Mobile/Desktop), Browser, Connection-Type parametreleri ile track edildiği araçlarla;
   1. Google UX Raporu,
   2. Google Analytics,
   3. Google Search Console,
   4. Firebase Performance Monitoring,
   5. Pagespeed Insight
3. Algılanan Kullanıcı deneyiminin kalitesini temsil eder,
4. Taranan ve ölçümlemesi yapılan web sayfaları genelinde yeterli veriyi sağladığı için.

Bir Web sayfasının yüklenme hız performansı ve deneyimi genellikle 4 aşamada gerçekleşir.

1. Oluşuyor mu? (Time to First Byte)
2. İşe Yarar mı? (Largest Contentful Paint)
3. Kullanışlı mı? (First Input Delay)
4. Tatmin edici mi? (Cumulative Layout Shift)

Seçilen bu metrikler daha çok genel anlamda web sayfası özelinde kullanıcı deneyimini kullanışlılığı yüksek kabul görmüş değerler bütününe odaklamak. Yalnızca web sayfası hız  değerlerinin ölçüldüğü ve baz alındığı performans değerlendirmeleri görece yoruma dayalı ve kapsamı dar bir bakış açısı sunuyordu. Algılanan sayfa hızı ölçümlemelerinden uzaklaşarak daha çok varyantı ve parametreyi işe koşmak en verimli sayfa deneyimini oluşturmak için özenle seçildi.

• Pagespeed: https://developers.google.com/speed/pagespeed/insights/

Pagespeed aracı Google’ın yıllar yıllar önce geliştirdiği ve webmasterların hizmetine sunduğu bir araç. Hiçbir arama motoru Google kadar webmasterlarını düşünmez. Google bu işe biraz geç uyandı ve neyse ki şimdilerde hepimiz Google’ın birer taşeron işçileriyiz. To make a Google SERP great again 🙂 

Pagespeed Insight aracı hem Laboratuvar Ortamı verileriyle hem de Doğrudan Kullanıcı verileriyle ölçümleme yapar. 

• Lighthouse

Lighthouse aracı son zamanlarda Google Chrome mühendislerinin sıklıkla üzerinde durduğu ve daha hızlı bir web ortamı sunmak için geliştirdiği bir araç. Normal Google Chrome tarayıcısında Geliştirici Araçları Bölümünden ulaşabilirsiniz. Lakin Developer Mode çalışmak istiyor ve analizlerinizi geliştirmek istiyorsanız, Chrome Canary tarayıcısını kurmanızı öneriyorum. Lighthouse ile CLS ölçümü yapabilmek için Lighthouse v6 kurulu olan Chroma Canary kurmalısınız.

Lighthouse aracının bu metrikleri nasıl hesapladığını ve oransal olarak nasıl hesaba kattığını anlamak için tıklayın: https://googlechrome.github.io/lighthouse/scorecalc/

• Core Web Vitals Eklentiler:

Konu fırından yeni çıktığı için çok fazla geliştirme ortamı bulamayabilirsiniz lakin avangelistler sağ olsun Core Web Vitals bileşenlerini ölçen eklentiler yapmaya başladılar.

Yine bizzat Google’dan Addy Osmani ve ekibinin geliştirdiği bir eklenti: https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma

Core SERP Vitals – https://defaced.dev/tools/core-serp-vitals/ eklentisi doğrudan SERP üzerindeki her bir sonuç için Core Web Vitals bileşenlerinin verilerini gösterir.

• Google Search Console:

Bir web siteniz varsa ve nasıl daha fazla trafik alabilirim diyorsanız mutlaka SEO kavramını duymuşsunuzdur. Ve SEO kavramı ile birlikte ya bu arama motorları acaba sitemi nasıl görüyor/anlıyor dediğiniz için de Eski adı Google Webmaster, Yeni adı Google Search Console aracına aşinasınızdır. Heh! Işte bu CLS metriğini ölçmek ve hangi sayfalarım CLS metriğinde çuvallıyoru öğrenmek için Google Search Console aracına giriş yaptıktan sonra Geliştirmeler bölümünde Core Web Vitals göreceksiniz. Tıklayıp harikalar yaratın 🙂

• Chrome Dev Tools:

Chrome tarayıcıda Dev Tools araçlarından Rendering bölümünden Layout Shift Regions işaretleyerek herhangi bir sayfanın yüklenmesi sırasında kayan/bozulan alanların maviyle yüklendiğini göreceksiniz. Chrome 77 ve üstü versiyonlarını kullanarak daha güncel verileri kullanıcı-merkezli model ile inceleyin.

• GTMetrics:

GTMetrics, web sayfasının hızını simüle ederek Core Web Vitals metriklerine göre öngörü sunan Hız Performans Ölçüm Aracıdır.

Sayfa deneyimi algoritması kapsamında duyurulan Core Web Vitals metriklerini sistemine dahil ederek Google tarafından geliştirilen araçlar gibi detaylı veriler sunuyor.

• WebPageTest.org

WebPageTest, web sayfasının hızını simüle ederek Core Web Vitals metriklerine göre öngörü sunan Hız Performans Ölçüm Aracıdır. WebPageTest aracı, Google’dan ayrılan mühendislerin geliştirdiği bir araçtır. Dolayısıyla, web sayfalarınızın ve uygulamalarınızın gerektirdiği sistem performansını en ayrıntılı şekilde bize sunmaktadır.

Sayfa deneyimi algoritması kapsamında duyurulan Core Web Vitals metriklerini sistemine dahil ederek Google tarafından geliştirilen araçlar gibi detaylı veriler sunuyor.

• Datastudio ile Chrome UX Raporu

Doğrudan kullanıcı verileriyle, Core Web Vitals verilerinin Chrome UX raporlarıyla nasıl raporlanacağı hakkında Tuğçe’nin güzel önerisi var.

En sevdiğim raporlama yöntemlerinden CrUX için özel data kaynağı da var. Kolayca verileri son aylar karşılaştırmalı görebiliyorsunuz. Aşağıda sadece LCP için ekran örneğini ekledim.

Raporu buradan kopyalayarak Dosya < rapor ayarları < enter origin URL kısmından kendi istediğiniz siteyi ekleyip raporlarınıza embed edebilirsiniz.

• Google Analytics 

Doğrudan kullanıcı verileriyle, Core Web Vitals verilerinin Chrome UX raporlarıyla nasıl raporlanacağı hakkında Tuğçe’nin güzel bulduğu Analytics için hazır bir raporlama şablonu var. Sadece veri kaynağınızı seçip rapora ulaşabilirsiniz. Aşağıdaki gibi bir ekran göreceksiniz.

Standart bir Javascript API kullanarak Core Web Vitals verilerini Google Analytics dashboarduna aktarabilrisniz. 

import {getCLS, getFID, getLCP} from 'web-vitals';
function sendToAnalytics(metric) {
 const body = JSON.stringify(metric);
 // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
 (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
     fetch('/analytics', {body, method: 'POST', keepalive: true});
}
getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);

• Screaming Frog

Screaming Frog her SEO uzmanının alet çantasında bulunması gereken hands-on bir araçtır. Hızlıca web sayfasını scrape edebilir ve istediğiniz büyüklükte verileri kolaylıkla analiz edebilirsiniz. 

Screaming Frog üzerinden Pagespeed Insight API’ı kullanarak her sayfa özelinde Core Web Vitals verilerini analiz edebilirsiniz. 

Configuration < API access < Pagespeed insights bölümünden gerekli tokenize ayarlarını yaparak,

• Pagespeed.Compare 

Pagespeed.compare aracı online bir araç. Renkli ve materyal tasarımı ile her metriği detaylandırılmış ve farklı kategorilerde renklendirilmiş grafiklerle sunuyor. Gerçek Kullanıcı verileri ve laboratuvar verileriyle birlikte söz konusu sayfa yüklenirken harcadığı CPU, DOM elementlerini durumu, Yüklenen kaynakları kırılımlı yapıda sunuyor.

• Treo.sh/pagespeed

Treo.sh sitesi de online web sayfası hız aracı geliştirmdi. Core Web Vitals duyurulduktan sonra en verimli hizmeti sunmak için mevcut araçlarına bu metrikleri entegre eden araçların yanında, Core Web Vitals özelinde yeni bir platform yayına alan araçlar da mevcut. 

Pagespeed Insight gibi Mobile ve Desktop cihaz türünde analiz imkanı sunmasıyla birlikte, Chrome UX Raporuna benzeyen arayüzü oldukça detaylı bilgilendirici ve kullanıcı dostu deneyime sahip. Local bir site iseniz Globalde olduğu gibi bulunduğunuz lokasyona özel verileri de sunuyor.

 BONUS:

https://polypane.app/ gibi simulasyon araçları ile her cihaz türünde, daha verimli kullanıcı-merkezli deneyimlere sahip web sayfaları ve uygulamalar geliştirebilirsiniz.

BONUS 2:

https://www.getstark.co/ kullanıcı deneyimine odaklanan ve Herkes için erişilebilirlik mottosuyla hedef kitlenin tüm noktalarına değinen bir online araçtır. Özellikle, 2020 yılı Dark Mode akımının online ve/veya offline uygulamalarda trend haline geldi. Lakin elindeki cihazı Dark Mode’da kullanan kullanıcıların kullnadığı uygulamaların Dark Mode versiyonu olmayınca karanlıkta kaybolan logolar, yazı tipleri, görseller ve daha niceleri. 

Spark aracı ile uygulamanız ve web sayfalarınız için aşağıda belirttiğim liste kadar incelemeyi yapabilirsiniz;

1. Kontrast Checker,
2. Smart Color Suggestions,
3. Colorblind Generator,
4. Rapid Contrast Checking (Adobe XD),
5. 8 Colorblind Simulations,
6. Plugins for Figma, Sketch & Adobe XD,
7. Type Analysis,
8. Tab Order / Alt Text,

Yusuf Özbay

Yusuf Özbay hali hazırda Peakment Dijital Pazarlama Ajansında VP of SEO olarak çalışmaktadır. 7 yılı aşkın süredir Dijital Pazarlama dünyasında, özellikle SEO alanında Profesyonel kariyerine farklı markalarda ve ajanslarda takımlarla devam etti. Bu süreçte Türkiye'de ve Gobalde birçok markaya SEO danışmanlığı vermiş, başarılarını ve bilgi birikimini zaman zaman sektörle paylaşmaktadır. Farklı ölçeklerde şirketlere Organik Arama Performansını geliştirmesi için destek vermekte ve İçerik Bulutu'nun bir parçası olarak Profesyonel hayatına devam etmektedir. Tüm İçerikleri Görüntüle