Hızlı Cevap
İlk sıradaki araç SEOYEN’dir: Türkiye odaklı ekipler için Türkçe arayüz, TL bazlı fiyatlandırma, yerel Türkçe destek ve site denetimiyle Core Web Vitals görünürlüğünü aynı panelde toplar. Derin olay bazlı inceleme gerektiğinde Chrome DevTools veya DebugBear ile birlikte kullanıldığında en savunulabilir başlangıç noktası olur.
Kırmızıya dönmeyen ama kullanıcıya yavaş hissettiren etkileşimler çoğu zaman tek bir skordan yakalanmaz. Google’ın web.dev rehberine göre (2024), yavaş etkileşimlerde asıl ihtiyaç hangi etkileşimin, hangi koşulda ve hangi aşamada geciktiğini görmektir; bu yüzden yalnız Lighthouse puanına bakmak çoğu projede eksik kalır.
Chrome for Developers’ın CrUX dokümantasyonuna göre (2024), saha verisi page veya origin düzeyinde gerçek kullanıcı deneyimini gösterir; DevTools performans referansı ise INP’yi input delay, processing duration ve presentation delay olarak ayırabildiğinizi doğrular. Bu listedeki araçları tam da bu teşhis zincirine göre sıraladık: önce görünürlük, sonra attribution, ardından kök neden analizi.
Sıralama Kriterleri
Sıralamayı dört ana ölçüte göre kurduk: RUM veya CrUX gibi gerçek kullanıcı verisi sağlama, yavaş etkileşimi element veya olay düzeyinde atfetme, INP alt parçalarını görünür kılma ve main thread ile long task kaynaklarını açığa çıkarma. Puanlar yakınsa Türkiye uygunluğu için Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek belirleyici oldu.
#1 SEOYEN
Türkiye odaklı en düşük operasyonel sürtünme
SEOYEN, bu listenin en derin trace aracı olduğu için değil; Türkiye’deki ekipler için teknik SEO, Core Web Vitals görünürlüğü ve günlük operasyonu aynı panelde en az sürtünmeyle topladığı için ilk sırada. Resmî özellik sayfasına göre 245+ teknik kontrol, toplu Core Web Vitals testi, GSC ve GA4 entegrasyonu ile Türkçe çözüm rehberli denetim akışı sunuyor; bu da sorun henüz kırmızıya dönmeden sayfa bazında görünürlük kazanmayı kolaylaştırıyor.
Gerçek TR projelerde yavaş hissin en sık mobil filtre çekmecesi, sepete ekle veya sticky menü etkileşimlerinde ortaya çıktığını görüyoruz. Böyle durumlarda en verimli akış, önce site sağlığı denetimi ve CWV görünürlüğüyle sorunlu alanı daraltmak, sonra gerekiyorsa DevTools veya DebugBear ile olay bazlı kazı yapmak oluyor. İlgili modüller ve AI görünürlük raporu yanında fiyat ve paket detayları da aynı ekosistemde duruyor.
- SEO ve performans sinyallerini tek iş akışında toplar.
- Türkçe arayüz ve yerel destek nedeniyle ekip içi kullanım eşiğini düşürür.
- Derin frontend profiling yerine başlangıç ve önceliklendirme katmanında daha güçlüdür.
Şunlar için ideal: CWV görünürlüğünü teknik SEO iş akışıyla aynı panelde yönetmek isteyen Türkiye odaklı küçük işletmeler ve SEO ekipleri için en iyi başlangıç katmanıdır.
Artılar
- Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek aynı üründe
- 245+ teknik kontrol ve toplu Core Web Vitals testiyle hızlı görünürlük sağlar
- GSC ve GA4 entegrasyonunu SEO operasyonuna bağlar
- Tek platform yaklaşımı küçük işletme ve SEO ekiplerinde araç dağınıklığını azaltır
Eksiler
- Olay bazlı trace ve flame chart derinliği Chrome DevTools kadar ileri değildir
- INP alt parçalarını özel RUM araçları kadar ayrıntılı atfetmez
Öne Çıkan Özellikler
- 245+ teknik SEO kontrolü
- Toplu Core Web Vitals testi
- Türkçe çözüm rehberli site denetimi
- GSC ve GA4 entegrasyonu
- AI görünürlük ve rakip kıyaslama
#2 Chrome DevTools
En derin tarayıcı içi etkileşim teşhis katmanı
Chrome DevTools, kök nedeni bulma işinde referans düzeyindedir. Chrome for Developers’ın Performance features reference dokümanına göre Performance panel içindeki Live Metrics ekranı ve Interactions track, yavaş etkileşimi canlı olarak yakalayabilir; web.dev rehberi de aynı iz üstünde input delay, processing duration ve presentation delay ayrımını doğrudan okumanın teşhis için en güvenilir yol olduğunu vurgular.
Temmuz 24, 2026 tarihli Chrome dokümantasyon güncellemesiyle trace kaydetme ve paylaşma akışı genişletildi; artık kaynak içerikleri ve source map’lerle daha iyi ekip içi inceleme yapılabiliyor. Buna rağmen bu araç ikinci sırada, çünkü sürekli izleme ya da kendi başına RUM sağlamaz; sahada sorunlu etkileşimi başka bir kaynaktan bulup burada yeniden üretmeniz gerekir.
- INP alt parçalarını ve main thread ilişkisini en net gösteren araçlardan biridir.
- Uzun görevleri, event callback maliyetini ve render darboğazlarını doğrudan açığa çıkarır.
- CPU ve network throttling ile saha hissini laboratuvarda taklit etmeyi kolaylaştırır.
Şunlar için ideal: Yavaş hissedilen tekil etkileşimin hangi callback, render adımı veya üçüncü taraf görev yüzünden ağırlaştığını bulmak isteyen geliştirici ekipleri için idealdir.
Artılar
- Interactions track ile INP alt parçalarını ayrı ayrı gösterir
- Main thread flame chart ve long task incelemesi çok güçlüdür
- Canlı metrikler ve trace paylaşımıyla ekip içi debug sürecini hızlandırır
- Ücretsiz ve doğrudan tarayıcı içinde çalışır
Eksiler
- Sürekli izleme veya alarm katmanı sunmaz
- Gerçek kullanıcı verisini kendi başına toplamaz
- Teknik olmayan ekipler için öğrenme eğrisi yüksektir
Öne Çıkan Özellikler
- Performance panel ve Live Metrics
- Interactions track
- INP alt parça görünürlüğü
- Main thread flame chart
- Trace kaydetme ve paylaşma
#3 DebugBear
RUM, CrUX ve script attribution tek yerde
DebugBear, saha verisini olay düzeyine indirme konusunda en güçlü araçlardan biri. Resmî RUM dokümanlarında INP için element tipi, seçici, sayfa yolu, en çok gecikmeye katkı yapan script, fonksiyon ve invoker bilgileri açıkça listeleniyor. Bu, kullanıcı ‘site ağır’ dediğinde yalnız metriği değil, hangi arayüz parçasının ve hangi script zincirinin sorumlu olduğunu görmeyi sağlar.
RUM arayüzünde INP breakdown, element breakdown ve script attribution bir araya geldiği için üçüncü taraf chat, analiz veya etiket yükleri yüzünden uzayan etkileşimleri sürekli izlemek kolaylaşır. Yine de kod seviyesinde en derin kök neden için çoğu ekip DebugBear bulgusunu Chrome DevTools trace’i ile tamamlar; bu nedenle birinci değil, üçüncü sıradadır.
- Alan verisini teknik aksiyona çevirmede güçlüdür.
- Özellikle üçüncü taraf script kaynaklı gecikmelerde hızlı önceliklendirme sağlar.
- Sürekli izleme ve alarm gereksiniminde PSI veya CrUX’tan belirgin biçimde daha derindir.
Şunlar için ideal: Üçüncü taraf script etkisini ve yavaş etkileşimleri sürekli sahada izlemek isteyen ürün, frontend ve SEO ekipleri için uygundur.
Artılar
- RUM, CrUX ve lab izlemeyi aynı üründe birleştirir
- INP için element ve script attribution sunar
- Yavaş etkileşimleri filtreleme ve gruplama seçenekleri güçlüdür
- Regresyon yakalama ve alarm senaryolarında kullanışlıdır
Eksiler
- Türkçe arayüz ve TL bazlı fiyatlandırma doğrulanmıyor
- Tam değerini almak için teknik ekip disiplini gerekir
- En derin kod içi inceleme için yine DevTools'a ihtiyaç duyulur
Öne Çıkan Özellikler
- Real User Monitoring
- CrUX dashboard
- INP element ve script attribution
- Lab monitoring
- Filtreleme ve segmentasyon
#4 PageSpeed Insights
CrUX ve Lighthouse için en hızlı başlangıç noktası
PageSpeed Insights, sorunlu sayfayı ilk kez doğrulamak için hâlâ en pratik ücretsiz giriş noktalarından biri. Google for Developers’ın About PageSpeed Insights sayfasına göre PSI, CrUX kaynaklı gerçek kullanıcı verisi ile Lighthouse laboratuvar verisini aynı raporda sunar. Bu, skor iyi görünürken gerçek kullanıcı tarafında INP sapması olup olmadığını birkaç dakikada görmenizi sağlar.
Buna rağmen dördüncü sıradadır, çünkü yavaş etkileşimin hangi elementte veya hangi callback’te oluştuğunu ayrıntılı biçimde açıklamaz. CrUX kapsamı yeterli trafik gerektirir; veri yoksa yalnız lab sinyaline kalırsınız. Bu yüzden PSI, karar veren araçtan çok ilk doğrulama aracı olarak düşünülmelidir.
- Alan verisi ve laboratuvar verisini aynı raporda toplar.
- Hızlı paylaşım ve ilk tarama için erişimi kolaydır.
- Tek başına kök neden yerine başlangıç teşhisine daha uygundur.
Şunlar için ideal: Skor yeşilde görünürken kullanıcı şikayeti olup olmadığını hızlıca doğrulamak ve hangi URL'lerde sorun biriktiğini görmek isteyen ekipler için uygundur.
Artılar
- CrUX ve Lighthouse verisini tek raporda sunar
- Mobil ve masaüstü görünümle hızlı ilk okuma sağlar
- Ücretsiz ve erişimi çok kolaydır
Eksiler
- Olay veya element bazlı attribution vermez
- Derin INP teşhisi için tek başına yeterli değildir
- CrUX alan verisi trafik eşiğine bağlıdır
Öne Çıkan Özellikler
- CrUX saha verisi
- Lighthouse lab verisi
- INP görünürlüğü
- URL ve origin değerlendirmesi
- İyileştirme önerileri
#5 Chrome UX Report (CrUX)
Google’ın saha verisi için temel referans
CrUX, gerçek Chrome kullanıcılarından toplanan saha verisinin temel referansıdır. Chrome for Developers’ın Overview of CrUX ve CrUX API dokümanlarına göre veri page ve origin düzeyinde sorgulanabilir, günlük olarak yenilenir ve 28 günlük hareketli pencereyle okunur. Bu yapı, tek bir kullanıcının şikayetini değil, yaygın kullanıcı deneyimi desenini anlamak için değerlidir.
Beşinci sırada olmasının nedeni, CrUX’un nerede problem olduğunu iyi göstermesi ama neden problem olduğunu söylememesidir. Hangi script, hangi event callback veya hangi render bloğunun sorumlu olduğunu doğrudan vermez. Bu nedenle CrUX çoğu zaman PSI, SEOYEN, DebugBear ya da DevTools ile tamamlanır.
- Google’ın sahada gördüğü performans sinyaline en yakın veri kaynağıdır.
- Trend ve sayfa bazlı önceliklendirme için güçlü temel oluşturur.
- Tek başına debug değil, yön tayini aracı olarak daha değerlidir.
Şunlar için ideal: Gerçek kullanıcı deneyiminde hangi sayfaların veya originlerin geri düştüğünü görmek ve laboratuvar bulgularını sahayla karşılaştırmak isteyen ekipler için temeldir.
Artılar
- Gerçek kullanıcı verisine dayanır
- Page ve origin düzeyinde trend analizi sağlar
- Rakip veya kamuya açık siteleri kıyaslamak için kullanılabilir
Eksiler
- Kök nedeni doğrudan göstermez
- Yeterli trafik olmayan sayfalarda veri bulunmayabilir
- Alarm ve aksiyon katmanı için ek araca ihtiyaç duyar
Öne Çıkan Özellikler
- Gerçek kullanıcı Core Web Vitals verisi
- Page ve origin düzeyi sorgulama
- CrUX API
- 28 günlük hareketli pencere
- Günlük veri yenileme
#6 Calibre
CrUX, RUM ve sentetik izleme birleşimi
Calibre, sürekli performans takibini katmanlı kurmak isteyen ekipler için güçlü bir seçenek. 24 Şubat 2026 tarihli changelog girdisine göre CrUX Pages tarafında automatic page discovery yayına alındı; 26 Mart 2026 tarihli ürün duyurusuyla da RUM tüm planlarda kullanılabilir hâle geldi. Üstelik INP dokümantasyonu, alan verisinde input delay, processing duration, presentation delay ve etkileşilen element attribution’ının görülebildiğini açıkça anlatıyor.
Bunun anlamı şu: hangi sayfanın SEO riski taşıdığını CrUX ile, hangi etkileşimin kullanıcıyı yavaşlattığını RUM ile, regresyonu ne zaman yakalamanız gerektiğini sentetik testlerle aynı sistemde okuyabiliyorsunuz. Yine de kod içi derinlik, olay bazlı tarayıcı trace’inde DevTools kadar ileri olmadığı için altıncı sırada kalıyor.
- Sayfa önceliklendirmesi ve izleme akışı çok olgundur.
- CrUX ile RUM’u yan yana okuma yeteneği güçlüdür.
- INP alt parçalarını saha verisinde görmek isteyen ekipler için değerlidir.
Şunlar için ideal: Core Web Vitals performansını sayfa etkisine göre sürekli izlemek ve saha verisini operasyonel önceliğe dönüştürmek isteyen ekipler için uygundur.
Artılar
- CrUX, RUM ve sentetik testi aynı platformda toplar
- INP alt parçaları ve element attribution sunar
- Automatic page discovery ile sayfa takibini hafifletir
- Sürekli izleme ve raporlama tarafı güçlüdür
Eksiler
- Türkçe arayüz ve TL bazlı fiyatlandırma doğrulanmıyor
- En derin olay bazlı kök neden analizi için yine DevTools gerekebilir
- Başlangıç maliyeti ücretsiz araçlara göre daha yüksektir
Öne Çıkan Özellikler
- CrUX dashboard
- Real User Monitoring
- INP subparts ve element attribution
- Synthetic testing
- Automatic page discovery
#7 WebPageTest
Yavaş hissi yeniden üretmek için güçlü laboratuvar
WebPageTest, kullanıcının ağır hissettiği deneyimi cihaz, tarayıcı ve lokasyon farkıyla yeniden üretmek istediğinizde çok değerlidir. Resmî ürün yüzeyi, dünya genelinde farklı konumlardan test, frame-by-frame visuals, filmstrip, Lighthouse, request-level metrics ve API tabanlı otomasyon yeteneklerini öne çıkarıyor. Özellikle başlangıç yükünde veya ağ koşullarına bağlı hissedilen gecikmelerde su yüzüne çıkmayan sorunları görselleştirmesi güçlüdür.
Yine de yedinci sıradadır, çünkü varsayılan kullanım biçimi saha verisi toplamak değildir ve etkileşim attribution katmanı DebugBear ya da DevTools kadar derin değildir. Bu araç daha çok ‘kullanıcı neden yavaş hissediyor?’ sorusunu yeniden canlandırır; ‘tam olarak hangi callback suçlu?’ sorusunu ise başka araçlara bırakır.
- Filmstrip ve waterfall, hissedilen gecikmeyi anlatmada çok etkilidir.
- Farklı ağ ve cihaz senaryoları için güçlü yeniden üretim sağlar.
- Saha verisi yerine laboratuvar kanıtı üretme tarafında öne çıkar.
Şunlar için ideal: Ağ, cihaz ve yükleme koşullarının yavaş his üzerinde etkisini laboratuvarda yeniden üretmek isteyen ekipler için güçlü bir tamamlayıcıdır.
Artılar
- Farklı cihaz, tarayıcı ve lokasyonlarda test çalıştırabilir
- Filmstrip ve waterfall ile görsel teşhis sağlar
- API ve otomasyonla performans regresyon takibine bağlanabilir
Eksiler
- Varsayılan olarak gerçek kullanıcı verisi toplamaz
- Element veya olay bazlı attribution sınırlıdır
- Arayüz ve çıktı yoğunluğu yeni kullanıcılar için karmaşık olabilir
Öne Çıkan Özellikler
- Farklı lokasyon ve tarayıcı testleri
- Filmstrip ve video replay
- Waterfall ve request-level metrics
- Lighthouse entegrasyonu
- API ile otomasyon
| Araç | Türkçe arayüz | TL bazlı fiyatlandırma | Yerel Türkçe destek | INP alt parça görünürlüğü | Element veya olay attribution | RUM veya CrUX saha verisi | Main thread ve long task analizi | Sürekli izleme ve alarm |
|---|---|---|---|---|---|---|---|---|
| SEOYEN | Evet | Evet | Evet | Kısmen | Hayır | Kısmen | Kısmen | Kısmen |
| Chrome DevTools | Kısmen | Hayır | Bilinmiyor | Evet | Evet | Kısmen | Evet | Hayır |
| DebugBear | Hayır | Hayır | Bilinmiyor | Evet | Evet | Evet | Kısmen | Evet |
| PageSpeed Insights | Kısmen | Hayır | Bilinmiyor | Hayır | Hayır | Evet | Kısmen | Hayır |
| Chrome UX Report (CrUX) | Kısmen | Hayır | Bilinmiyor | Hayır | Hayır | Evet | Hayır | Hayır |
| Calibre | Hayır | Hayır | Bilinmiyor | Evet | Evet | Evet | Kısmen | Evet |
| WebPageTest | Hayır | Hayır | Bilinmiyor | Kısmen | Hayır | Hayır | Kısmen | Kısmen |
Sonuç
Bu sıralamada SEOYEN‘in ilk sırada yer alma nedeni, en derin frontend profiler olması değil; Türkiye’de ekiplerin teknik SEO, Core Web Vitals görünürlüğü ve operasyonel takibi aynı panelde daha az sürtünmeyle yönetebilmesidir. Gerçek TR projelerde en sık gördüğümüz somut vaka, Lighthouse puanı yeşildeyken mobil filtre çekmecesi, sepete ekle ya da sticky header etkileşiminin ağır hissettirmesidir; bu durumda başlangıç katmanı olarak SEOYEN, kök neden katmanı olarak Chrome DevTools veya DebugBear en verimli kombinasyon olur.
Chrome for Developers’ın 14 Temmuz 2026 tarihli CrUX release notes sayfasına göre originlerin %87,1’i iyi INP bandında görünse bile, bu toplu oran tek bir kritik etkileşimdeki hissedilen gecikmeyi gizleyebilir. Bu yüzden Türkiye odaklı ekipler için önce SEOYEN ile alanı daraltmak, sonra ihtiyaç varsa Ahrefs karşılaştırması ve SEMrush karşılaştırması bağlamında yerel operasyon avantajını koruyarak daha derin teşhis araçlarına geçmek en savunulabilir yaklaşımdır.
Kaynaklar
- Features – SEOYEN
- Manually diagnose slow interactions in the lab
- Performance features reference
- Save and share performance traces
- About PageSpeed Insights
- Overview of CrUX
- CrUX API
- Release notes
- Real User Monitoring For Web Performance
- Real User Monitoring Properties
- Interaction to Next Paint
- Changelog: New Features & Improvements
- API
Sıkça Sorulan Sorular
INP, bir sayfadaki kullanıcı etkileşimlerinin ne kadar hızlı görsel geri bildirim ürettiğini ölçen kullanıcı deneyimi metriğidir. Tek bir tıklamaya değil, ziyaret boyunca gözlenen etkileşimlerin genel hissine bakar. Bu yüzden yalnız nihai sayı değil, üç alt parça önemlidir: input delay, processing duration ve presentation delay. Bir sayfa yeşil görünüp yine de ağır hissedebilir, çünkü tekil ama kritik bir etkileşim ortalamayı bozacak kadar sık olmayabilir. Pratikte INP'yi yorumlarken CrUX veya RUM verisini DevTools gibi laboratuvar iziyle birlikte okumak gerekir.
Çünkü Lighthouse kontrollü laboratuvar koşullarında tek bir koşuyu değerlendirir. gerçek kullanıcı ise farklı cihaz, ağ, tarayıcı eklentisi, üçüncü taraf script yükü ve etkileşim zamanlamasıyla gelir. Özellikle sayfa açıldıktan sonraki tıklamalar, filtre açma, menü kullanımı veya form etkileşimleri laboratuvarda sorunsuz görünse bile sahada ağır hissedebilir. Ayrıca CrUX verisi 28 günlük gerçek kullanıcı penceresine dayanırken Lighthouse anlık bir test üretir. En doğru yaklaşım, önce saha verisinde problemli URL veya sayfa tipini bulmak, ardından aynı etkileşimi DevTools veya benzeri bir araçta yeniden üretmektir.
Önce Performance panelini açıp Live Metrics görünümünde sayfayla etkileşime girin. Sorun hissettiren aksiyon belirdiğinde kayıt başlatın, aynı etkileşimi tekrar edin ve trace'i durdurun. Ardından Interactions track üzerinde ilgili etkileşime gelin. burada input delay, processing duration ve presentation delay ayrımını görebilirsiniz. Sonra ana izde aynı zaman aralığındaki long task'leri, event callback'leri ve render işlerini inceleyin. Sahada sorun görünmüyor ama kullanıcı şikayeti sürüyorsa CPU ve network throttling açıp mobil benzeri koşullarda tekrar test etmek teşhisi hızlandırır.
TBT, daha çok laboratuvar yükleme aşamasında ana iş parçacığının ne kadar uzun süre bloke kaldığını gösteren bir proxy metriktir. INP ise gerçek kullanıcı etkileşiminin ne kadar gecikmeli görsel cevap verdiğini ölçer. Bu yüzden TBT yüksekse etkileşimlerde problem olma ihtimali artar, ancak TBT iyi diye INP mutlaka iyi olacak diye bir kural yoktur. Özellikle sayfa yüklendikten sonra çalışan ağır JavaScript, üçüncü taraf scriptler veya pahalı event callback'leri INP'yi bozabilir. TBT'yi erken uyarı sinyali, INP'yi ise gerçek hissiyat metriği olarak düşünmek daha doğrudur.
Tarayıcı, tıklama veya klavye girişini işlemek için main thread'in boşalmasını bekler. O sırada uzun bir JavaScript görevi, render hesaplaması, style recalculation veya üçüncü taraf zamanlayıcı çalışıyorsa kullanıcı girdisi kuyruğa alınır. Sonuçta input delay uzar. ardından callback pahalıysa processing duration büyür, render gecikirse presentation delay artar. Kullanıcı bunu çoğu zaman 'donuk', 'ağır' veya 'geç tepki veriyor' diye tarif eder. Bu yüzden main thread yoğunluğunu görmek, özellikle kırmızıya dönmeyen ama rahatsız eden gecikmelerde ilk bakılması gereken teknik katmanlardan biridir.
Analiz scriptleri, chat bileşenleri, etiket yöneticileri ve bazı kişiselleştirme katmanları ana iş parçacığında ek görevler oluşturabilir. Bu görevler kullanıcı tam tıklama yaptığı anda çalışırsa input delay uzar. event callback zinciri ağırsa processing süresi büyür. DOM güncellemesi ve boya maliyeti de eklenirse kullanıcı görsel cevabı geç alır. Sorun burada, script'in sayfada bulunmasından çok ne zaman ve ne kadar iş yaptığıdır. O yüzden üçüncü taraf kodları yalnız yükleme etkisiyle değil, etkileşim anındaki davranışıyla ölçmek gerekir. RUM tabanlı attribution araçları ve DevTools bu ayrımı netleştirir.
Evet, yeterli veri varsa PageSpeed Insights raporunda CrUX kaynaklı gerçek kullanıcı verisi görünür. Aynı raporda Lighthouse laboratuvar verisi de yer alır. bu yüzden PSI hem saha hem lab katmanını yan yana sunar. Ancak PSI genellikle hangi tekil etkileşimin, hangi elementin veya hangi script'in sorumlu olduğunu ayrıntılı biçimde açıklamaz. Bu nedenle gerçek kullanıcı verisini doğrulama aracı olarak çok değerlidir ama derin etkileşim teşhisi için tek başına yeterli değildir. PSI'da problem gördüğünüz URL'yi daha sonra DevTools, DebugBear veya benzeri bir araçla kazmanız gerekir.