Mobil Uyumlu (Responsive) Web Tasarım Rehberi 2026

Responsive (mobil uyumlu) tasarım, bir web sitesinin telefon, tablet ve masaüstü gibi her ekran boyutunda otomatik olarak kendini yeniden düzenleyerek okunabilir ve kullanılabilir kalmasıdır. Tek bir HTML kaynağı ve esnek CSS kullanarak; sabit pikseller yerine yüzde/akışkan ölçüler, esnek ızgaralar (flexbox/grid), uyarlanabilir görseller ve medya sorguları (media queries) ile içerik cihazın genişliğine göre yeniden konumlanır. Yani her cihaz için ayrı bir site (örneğin eski "m.site.com" yaklaşımı) yapmak yerine, tek site tüm cihazlara uyum sağlar. 2026 itibarıyla bu artık tercih değil zorunluluktur: küresel web trafiğinin yaklaşık %60'ı mobil cihazlardan gelir (StatCounter, 2026; kaynağa göre %52-64 arası değişir) ve Türkiye gibi pazarlarda bu oran %80'e kadar çıkar. Üstüne Google, mobil öncelikli indeksleme (mobile-first indexing) ile sitenizin masaüstü değil mobil sürümünü dizine ekleyip sıraladığı için, mobilde bozuk veya eksik bir site doğrudan görünürlük ve dönüşüm kaybıdır.

Bu rehberde responsive'in ne olduğunu, "mobil öncelikli" yaklaşımdan farkını, teknik bileşenlerini, mobil performansın neden ayrıca kritik olduğunu ve dokunmatik/form akışında dikkat edilmesi gereken somut noktaları danışman gözüyle ele alıyoruz. Amaç, sitenizin telefonda sadece "sığması" değil; hızlı açılması, parmakla rahat kullanılması ve gerçekten dönüşüm getirmesidir. Estetik ve kullanılabilirlik kararlarının bütününü merak ediyorsanız iyi web tasarımı nasıl olmalı yazımız bu rehberin doğal devamıdır.

Responsive tasarım "uyarlanabilir" (adaptive) tasarımdan ne farkı var?

İki kavram sık karıştırılır ama mantıkları farklıdır. Responsive (duyarlı) tasarımda tek bir esnek düzen vardır; içerik, tarayıcı penceresinin genişliğine göre akışkan biçimde sürekli yeniden akar. Sayfa 320 piksellik bir telefonda da, 1440 piksellik bir monitörde de aynı kaynaktan beslenir; aradaki her boyutta düzgün görünür. Adaptive (uyarlanabilir) tasarımda ise belirli sabit ekran boyutları için önceden hazırlanmış ayrı düzenler vardır; site, cihazı algılayıp en yakın hazır düzeni gösterir. Adaptive daha çok kontrol verir ama daha çok bakım ister ve aradaki "kaşlar" (örneğin katlanabilir telefonlar, geniş tabletler) için boşluk bırakır.

Farkı somutlaştırmak için iki yaklaşımı yan yana koyalım:

Pratikte 2026'da baskın yaklaşım responsive'dir, çünkü cihaz çeşitliliği artık o kadar yüksektir ki sabit boyutları tek tek hedeflemek anlamsızdır. Modern CSS bu işi çok daha zarif çözer: container queries (bir bileşenin, tüm sayfa yerine içinde bulunduğu kabın genişliğine göre uyum sağlaması) ve akışkan tipografi için clamp() fonksiyonu (yazı boyutunun min-max sınırlar arasında ekranla orantılı büyüyüp küçülmesi) ile artık tek tek breakpoint yazmadan da gerçek anlamda uyumlu arayüzler kurulabilir. Sıfırdan bir site planlıyorsanız bu kararları en baştan vermelisiniz; süreci bütününde görmek için web sitesi nasıl yapılır 2026 rehberi yazımızdaki adım sıralamasına göz atabilirsiniz.

Responsive tasarım neden artık opsiyonel değil?

Birkaç somut sebep responsive'i pazarlık dışı bir temel haline getiriyor:

• Mobil trafik çoğunluğu: Çoğu sitede ziyaretin yarıdan fazlası mobilden gelir; e-ticaret ve yerel hizmet sitelerinde bu pay daha da yüksektir. Mobilde bozuk bir deneyim, gelen trafiğin büyük kısmını kaybetmek demektir. Müşterilerimizde gördüğümüz en yaygın "neden satış yok" sebeplerinden biri, masaüstünde güzel görünen ama telefonda butonu tıklanamayan, formu doldurulamayan sitelerdir.
• Google mobil öncelikli indeksleme: Google artık sitenizin mobil sürümünü temel alır. Mobilde gizlenen içerik, kırpılan metin veya yüklenmeyen görsel, masaüstünde var olsa bile arama motoru için "yok" sayılır. Yani SEO performansınız doğrudan mobil sürümünüzün kalitesine bağlıdır; teknik tarafı derinlemesine ele aldığımız teknik SEO denetimi nasıl yapılır yazısı bu bağlantıyı detaylandırıyor.
• Tek kaynak, tek bakım: Responsive tek bir kod tabanı kullandığından içerik ve güncelleme tek yerden yönetilir. Ayrı mobil site tutmak çift içerik, çift hata, çift bakım demektir ve genelde mobil sürüm güncellenmeden geri kalır. Ayrı bir "m." sürümünde aynı bilgiyi iki yerde tutmak, zamanla mobil ve masaüstü içeriğin birbirinden ayrışmasına ve mobil-öncelikli indekslemede eksik içeriğin dizine girmesine yol açar.
• Erişilebilirlik ve yasal uyum: Esnek, ölçeklenebilir bir düzen; metni büyüten, yakınlaştıran veya tek elle kullanan kullanıcıları da kapsar. WCAG 2.2 erişilebilirlik standardının dokunmatik hedef boyutu gibi kriterleri zaten mobil-dostu tasarımla örtüşür. Üstelik 28 Haziran 2025'te yürürlüğe giren Avrupa Erişilebilirlik Yasası (EAA) ile AB'ye ürün/hizmet satan firmalar için erişilebilirlik WCAG 2.1 AA düzeyinde zorunlu hale geldi; bu konuyu web erişilebilirliği nedir nasıl sağlanır yazımızda ayrıntılı ele alıyoruz.
• Dönüşüm ve gelir etkisi: Mobilde ziyaretçinin sayfanızda kalıp kalmayacağı ilk birkaç saniyede belli olur. Responsive olmayan bir sayfada kullanıcı sürekli yakınlaştırıp kaydırmak zorunda kalır; bu sürtünme doğrudan terk oranını yükseltir. Dönüşüm odaklı bir akışın nasıl kurulacağını dönüşüm odaklı landing page rehberi yazısında somut örneklerle anlatıyoruz.

Mobil öncelikli (mobile-first) ile responsive aynı şey mi?

Hayır, ilişkili ama aynı değiller. Responsive sonucu tanımlar: site her ekranda uyum sağlar. Mobil öncelikli (mobile-first) ise bu sonuca ulaşmak için izlenen tasarım sırasıdır: önce en küçük ekran (telefon) için tasarlarsınız, sonra düzeni büyük ekranlara doğru genişletirsiniz. Buna ilerlemeli geliştirme (progressive enhancement) denir. Tersi yön, yani masaüstünü tasarlayıp sonra küçülterek mobile sığdırmaya çalışmak (graceful degradation), genellikle kötü bir mobil deneyim üretir; çünkü masaüstü için tasarlanmış kalabalık menüler, geniş tablolar ve büyük hero görselleri küçük ekrana zorla sıkıştırıldığında bozulur.

Mobil öncelikli düşünmenin pratik faydası şudur: en kısıtlı alanda (küçük ekran, yavaş bağlantı, dokunmatik girdi) çalışmak, sizi en önemli içeriği ve tek net bir birincil eylem çağrısını (CTA) öne koymaya zorlar. Bu disiplin, sonradan masaüstüne genişlediğinizde de daha temiz, daha odaklı bir arayüz bırakır. Mobilde sınırlı dikey alan, hangi içeriğin gerçekten "ilk ekrana" (above the fold) gireceğini acımasızca seçmenizi sağlar.

İki yaklaşımın CSS düzeyindeki farkı da pratik bir sonuç doğurur. Mobil öncelikli yazımda taban stiller küçük ekrana göre yazılır ve min-width medya sorgularıyla ekran büyüdükçe kural eklenir; masaüstü öncelikli yazımda ise taban stiller geniş ekrana göredir ve max-width ile küçük ekran için kural ezilir. Mobil öncelikli yaklaşım, telefonun gereksiz büyük stilleri indirip sonra geçersiz kılmasını önlediği için mobil cihazda daha az iş yükü bırakır; bu da aşağıda değineceğimiz performans metriklerine doğrudan yansır.

Responsive tasarımın teknik bileşenleri nelerdir?

Responsive bir düzen birkaç temel teknik üzerine kurulur:

• Esnek ızgara (fluid grid): Sabit piksel genişlikleri yerine yüzde tabanlı veya CSS Grid/Flexbox ile akışkan kolonlar. Ekran daraldıkça kolonlar alt alta iner. Örneğin masaüstünde üç kolonlu bir hizmet bölümü, tablette iki, telefonda tek kolona düşer; bunu sabit genişlikler yerine grid'in otomatik sarmalama (wrap) davranışıyla kurmak en dayanıklı çözümdür.
• Esnek görseller: Görseller max-width: 100% ile kabını aşmaz; ayrıca srcset ile cihaza uygun çözünürlükte servis edilir, böylece telefona gereksiz büyük dosya inmez. Modern formatlar (WebP/AVIF) aynı kalitede daha küçük dosya verir; bu da mobil veri tüketimini ve yüklenme süresini düşürür.
• Medya sorguları ve breakpoint'ler: Düzenin bozulduğu noktalarda kırılım eklenir. Modern yaklaşım, sabit cihaz boyutlarını ezberlemek yerine içeriğin bozulduğu yerde breakpoint koymaktır. Yaygın referans aralıkları: yaklaşık 360-480px (telefon), 768px (tablet), 1024px ve üzeri (masaüstü).
• Viewport meta etiketi: Sayfanın <head> bölümündeki viewport tanımı olmadan mobil tarayıcı sayfayı masaüstü genişliğinde küçültüp gösterir ve responsive CSS devreye girmez. Bu, en sık atlanan ama en kritik tek satırdır.
• Modern CSS: Container queries ve clamp() ile akışkan tipografi, breakpoint sayısını azaltıp daha doğal uyum sağlar. Bir bileşenin (örneğin bir kart) yalnızca sayfa genişliğine değil, kendi yerleştiği kolonun genişliğine göre uyum sağlaması, aynı bileşeni farklı bağlamlarda yeniden kullanmayı kolaylaştırır.

Bu bileşenler arasında en kritik referans noktası breakpoint mantığıdır. Aşağıdaki tablo, sabit cihaz adı ezberlemek yerine içerik kırılımına göre düşünmenin pratik karşılığını özetliyor:

Bu değerler ezber değil başlangıç referansıdır; gerçek breakpoint'i her zaman içeriğinizin bozulduğu genişlik belirlemelidir. Örneğin uzun başlıklarınız 640px'te taşıyorsa kırılımı orada koymak, "çünkü telefon 480px'tir" demekten daha sağlıklıdır.

Mobilde performans neden ayrıca önemli?

Bir sitenin mobilde "uyumlu görünmesi" yeterli değildir; aynı zamanda hızlı olması gerekir. Mobil cihazlar genelde daha yavaş işlemci ve daha değişken şebeke koşulları kullanır, dolayısıyla Core Web Vitals metrikleri mobilde belirleyicidir. Google'ın "iyi" eşikleri (75. yüzdelik saha verisi): LCP (en büyük içeriğin görünme süresi) 2,5 saniye veya altı, INP (etkileşime yanıt hızı) 200 ms veya altı, CLS (beklenmedik düzen kayması) 0,1 veya altı.

INP'nin, 12 Mart 2024'te eski FID metriğinin yerini aldığını ve artık ilk tıklamayı değil tüm etkileşimleri ve tam yaşam döngüsünü ölçtüğünü hatırlatalım; bu yüzden mobilde menü, akordeon, sepete ekle gibi sık etkileşimli bileşenlerin yanıt hızı doğrudan bu metriğe yansır. Mobilde bu eşikleri tutturmanın yolu görsel optimizasyonu, lazy-load (görseli ekrana gelince yükleme), az ve bölünmüş JavaScript ve görsel/iframe alanlarına önceden yer ayırmaktan geçer. Özellikle CLS açısından, mobilde yer ayrılmamış bir banner veya geç yüklenen görsel, kullanıcı tam butona basacakken sayfanın zıplamasına ve yanlış tıklamaya yol açar. Bunu önlemenin en pratik yolu, her img/video/iframe öğesine açık genişlik-yükseklik (veya aspect-ratio) vermek ve fontlarda font-display: swap ile size-adjust kullanmaktır; doğru ayarlanmış size-adjust, font kaynaklı kaymayı belirgin biçimde düşürebilir. Hız ile sıralama arasındaki ilişkiyi ve ölçüm araçlarını ayrıntılı işlediğimiz site hızı ve SEO Core Web Vitals rehberi, mobil performansınızın nerede zayıfladığını görmek için iyi bir başlangıç noktasıdır; somut iyileştirme adımları için ise PageSpeed Insights nedir nasıl iyileştirilir yazımıza ve GEO denetim aracı ile e-ticaret altyapı tespit aracı gibi araçlarımıza bakabilirsiniz.

Mobil deneyimde dokunmatik ve form akışı

Responsive, sadece "her şeyin sığması" değil, parmakla rahat kullanılabilmesidir. Burada iki kritik nokta öne çıkar. Birincisi dokunmatik hedef boyutu: WCAG 2.2 (SC 2.5.8, AA seviyesi) minimum 24x24 CSS piksel veya yeterli boşluk şartı koyar; Apple Human Interface Guidelines 44x44 pt, Google Material ise 48x48 dp önerir. Pratik tavsiyemiz, tıklanabilir tüm öğeleri en az 44-48px tutmak ve birbirine yapışık linkler arasına yeterli boşluk koymaktır; aksi halde kullanıcı yanlış butona basar.

Dokunmatik hedef ölçüleri konusunda referans aralıklarını netleştirmek için:

İkincisi mobil form ve ödeme akışı: mobilde dönüşüm masaüstünden düşük olabildiği için form alanlarını azaltmak, otomatik doldurmayı (autofill) açmak, alana uygun klavye tipini (e-posta için @ klavyesi, telefon için sayısal klavye) tanımlamak ve tek elle erişimi gözetmek satışı doğrudan etkiler. Pratikte mobil dönüşümü en çok artıran düzenlemeler şunlardır:

• Alan sayısını azaltın: Her ek form alanı sürtünme ekler; mobilde bu etki daha keskindir. Yalnızca gerçekten gerekli bilgiyi isteyin.
• Doğru klavye ve autofill: Alanlara uygun girdi tipi tanımlayın; telefon alanında sayısal klavye, e-posta alanında @ içeren klavye açılsın. Tarayıcının kayıtlı bilgileri doldurmasına izin verin.
• Birincil CTA'yı baş parmak bölgesine koyun: Tek elle kullanımda ekranın alt-orta bölgesi en kolay erişilen yerdir; ana eylem butonunu sayfanın tepesine sıkışık biçimde değil, parmağın doğal eriştiği yere yerleştirin.
• Hata ve durum geri bildirimi net olsun: Hatalı alan anında ve çözüm önerili biçimde işaretlenmeli; "sistem dinliyor" hissini veren görünür durum geri bildirimi, mobilde terk oranını düşürür.
• Türkçe karakter ve dil tanımı: Sayfanın UTF-8 kodlamasında olması ve lang="tr" tanımı, hem doğru büyük/küçük harf dönüşümü (noktalı/noktasız I) hem de erişilebilirlik açısından gereklidir; seçtiğiniz fontun ç, ğ, ı, İ, ö, ş, ü karakterlerini sorunsuz desteklediğini mutlaka test edin.

Bu ilkeleri en baştan doğru kurmak, sonradan tüm siteyi yeniden elden geçirmekten çok daha ucuzdur. Mobil uyum, görsel hiyerarşi ve dönüşüm odaklı arayüz kararlarını birlikte ele aldığımız UI/UX tasarım nedir, nasıl yapılır yazısı, responsive düzenin estetik ve kullanılabilirlik tarafını tamamlar. Mevcut siteniz mobilde takılıyor, yavaş çalışıyor veya telefonda dönüşüm getirmiyorsa, mobil-öncelikli bir yaklaşımla yeniden tasarımı web ve mobil UI/UX tasarımı hizmetimizle ele alıyor; nereden başlamanız gerektiğini netleştirmek için ücretsiz bir analiz talep edebilirsiniz.

Mobil-Öncelikli (Mobile-First) Yaklaşım Nedir ve Breakpoint Mantığı Nasıl Kurulur?

Mobil-öncelikli tasarım, siteyi önce küçük ekran (telefon) için tasarlayıp sonra büyük ekrana doğru genişletmektir. Geleneksel yöntem olan "önce masaüstü tasarla, sonra küçült" yaklaşımının tersidir ve nedeni nettir: 2026 itibarıyla mobil cihazlar küresel web trafiğinin yaklaşık %60'ını oluşturuyor (StatCounter; kaynak ve döneme göre %52-64 arası değişiyor), Türkiye gibi pazarlarda bu oran %80'e kadar çıkıyor. Daha da kritik olan, Google'ın "Mobile-First Indexing" (mobil öncelikli indeksleme) artık varsayılan olması: Google sitenizin masaüstü değil mobil sürümünü indeksler ve sıralar. Yani mobilde eksik bıraktığınız her içerik doğrudan SEO kaybıdır. Müşterilerimizde gördüğümüz tablo da bunu doğruluyor; çoğu kurumsal ve e-ticaret sitesinde trafiğin yarıdan fazlası mobilden geliyor. Bu nedenle mobil, "düşünülecek bir varyasyon" değil, tasarımın başlangıç noktasıdır.

Mobil-öncelik üç ayrı disiplinin kesişimidir ve bu yazıda üçünü birlikte ele alıyoruz: düzen (içeriğin küçük ekranda nasıl akacağı), performans (zayıf cihaz ve şebekede hızlı yüklenme) ve erişilebilirlik (dokunma ergonomisi ve okunabilirlik). Çoğu ekibin yaptığı hata bunları ayrı kutular gibi görmektir; oysa mobilde bir tanesini ihmal ettiğinizde diğer ikisi de zarar görür. Örneğin mobil için fazla görsel ve script yüklerseniz performans çöker; performans çökünce kullanıcı CTA'ya ulaşmadan terk eder; dolayısıyla düzen ne kadar güzel olursa olsun dönüşüm kaybedersiniz.

Bu rehberin bütününü mobil uyumlu responsive web tasarım rehberi içinde derinlemesine ele alıyoruz; burada işin kalbi olan mobil-öncelikli yaklaşımı ve breakpoint kurgusunu pratikte nasıl uyguladığımızı anlatıyoruz. Sitenizin baştan doğru kurgulanması için izlenecek adımları web sitesi nasıl yapılır 2026 rehberi yazımızda bulabilirsiniz.

Neden "Önce Mobil"? Küçültmek ile Genişletmek Arasındaki Fark

Mobil-öncelikli yaklaşımın temel mantığı "progressive enhancement" (kademeli zenginleştirme) ilkesidir: en kısıtlı ortam olan küçük ekran, yavaş şebeke ve zayıf işlemci için tasarlarsınız, sonra ekran büyüdükçe boşluk, sütun ve görsel zenginlik eklersiniz. Bunun tersi olan "masaüstünden küçültme" (graceful degradation) yaklaşımı genelde kötü mobil deneyim üretir, çünkü masaüstü için tasarlanmış çok sütunlu, yoğun arayüzü telefona sığdırmaya çalışmak içeriğin ezilmesine, küçücük dokunma hedeflerine ve gizlenen önemli öğelere yol açar.

İki yaklaşım arasındaki farkı somutlaştırmak, kararın neden bu kadar belirleyici olduğunu netleştirir:

Önce mobil tasarlamanın disiplin getiren bir yan etkisi vardır: küçük ekran sizi öncelik belirlemeye zorlar. 360 piksellik bir genişlikte her şeyi gösteremezsiniz, bu yüzden en önemli mesaj, tek net birincil CTA ve değer önerisi en üste (above the fold) çıkmak zorunda kalır. Bu, Hick Yasası'nın (seçenek arttıkça karar süresi uzar) doğal bir uygulamasıdır; mobil kısıt, menüyü ve seçenekleri sadeleştirmenizi sağlar. Masaüstüne geçtiğinizde bu net hiyerarşiyi koruyarak yalnızca nefes alanı eklersiniz. UI/UX ilkelerinin bu yaklaşımla nasıl örtüştüğünü UI/UX tasarım nedir nasıl yapılır yazımızda ayrıntılandırıyoruz.

Bu kısıt mantığının pratik bir uzantısı da navigasyondur. Mobilde tam bir yatay menüyü gösteremediğiniz için en sık başvurulan kalıp hamburger menüdür; ancak müşterilerimizde gördüğümüz yaygın hata, hamburgerin altına on beş başlık doldurup mobil keşfedilebilirliği öldürmektir. Daha sağlıklı yaklaşım, mobilde en kritik üç-beş hedefi (örneğin Hizmetler, Referanslar, İletişim/Teklif) görünür ya da kolay erişilir tutmak; ikincil bağlantıları gruplamaktır. Jakob Yasası gereği kullanıcılar diğer sitelerden öğrendikleri kalıbı beklediğinden, hamburger ikonu sağ üstte ve tanıdık formda olmalı, "yaratıcı" olalım diye gizemli bir simgeye çevrilmemelidir.

Breakpoint Nedir ve Nereye Konur?

Breakpoint (kırılım noktası), sayfa düzeninin ekran genişliğine göre değiştiği eşiktir. Eski yaklaşım sabit cihaz boyutlarına (iPhone'un eni, iPad'in eni gibi) kırılım koymaktı; ama cihaz çeşitliliği o kadar arttı ki bu yöntem sürdürülemez. Modern ve doğru yaklaşım şudur: kırılımı cihaza değil, içeriğin bozulduğu noktaya koy. Tasarımı yavaşça genişletirken metin satırları çirkin uzadığında, bir kart düzeni dengesini kaybettiğinde veya boşluk gereksiz büyüdüğünde, orada bir breakpoint'e ihtiyacınız var demektir.

Pratikte referans aralıkları yine de işe yarar. Yaygın olarak kullandığımız bantlar:

Bu aralıkları "kanun" değil "başlangıç hipotezi" olarak kullanın. Doğru breakpoint'i bulmanın pratik yöntemi şudur: tarayıcı penceresini en dardan en geniş duruma yavaşça sürükleyin ve düzenin nerede çirkinleştiğine bakın. O kırılma anı sizin gerçek breakpoint'inizdir; çoğu zaman tabloda yazan yuvarlak rakamlara denk gelmez. Bir kurumsal sitede üç sütunlu hizmet kartlarının 900px civarında sıkıştığını, bir e-ticaret listesinde ise ürün kartlarının 620px'te bozulduğunu görebilirsiniz; bunlar içeriğe özgüdür.

Mobil-öncelikli CSS yazarken pratik kural, varsayılan stilleri en küçük ekran için yazmak ve ekran büyüdükçe min-width tabanlı media query'lerle özellik eklemektir; tersi yönde (max-width ile küçülterek) yazmak hem daha kırılgan hem de mobilde gereksiz kod yükü doğurur. Bu yaklaşım az JavaScript ve sade stil katmanıyla birleşince mobil performansa doğrudan katkı sağlar. İki ilave teknik nokta sık atlanır: ilki, viewport meta etiketi (sayfa meta name="viewport" ile width=device-width, initial-scale=1 tanımlamazsa mobil tarayıcı sayfayı masaüstü genişliğinde render edip küçültür ve tüm responsive çabası boşa gider); ikincisi, breakpoint sayısını abartmamaktır. Genelde iki-üç iyi yerleştirilmiş kırılım, ona yakın gereksiz kırılımdan daha sürdürülebilirdir; her ekstra breakpoint, bakımı ve test yüzeyini büyütür.

Esnek Izgara ve Akışkan Tipografi: Modern CSS Araçları

Responsive tasarımın iskeleti esnek ızgaradır (fluid grid). Sabit piksel genişlikler yerine yüzde, fr birimi (CSS Grid) veya esnek kutular (Flexbox) kullanarak düzenin kapsayıcıya göre akmasını sağlarsınız. 2026'da iki modern CSS özelliği bu işi breakpoint'lere olan bağımlılığı azaltarak çok daha temiz hale getiriyor:

• Container queries (kapsayıcı sorguları): Bir bileşenin stilini, tüm ekranın (viewport) değil, içinde bulunduğu kapsayıcının genişliğine göre ayarlar. Böylece aynı kart bileşeni hem dar bir kenar çubuğunda hem geniş bir ana alanda doğru görünür; bileşen gerçekten yeniden kullanılabilir olur. Bu, özellikle bileşen tabanlı framework'lerle (React, Vue) çalışan ekiplerde aynı kartı farklı sayfalarda yeniden kurgulama derdini ortadan kaldırır.
• Akışkan tipografi (clamp): CSS'in clamp() fonksiyonu, yazı boyutunu bir minimum ve maksimum arasında ekran genişliğine göre yumuşakça ölçekler. Bu, her breakpoint'te font boyutunu elle ayarlama ihtiyacını ortadan kaldırır ve metin her ekranda okunabilir kalır. Örneğin bir başlığı telefonda fazla büyütmeden, masaüstünde de cılız bırakmadan, aradaki tüm genişliklerde orantılı tutabilirsiniz.

Tipografide okunabilirlik için temel hedefler değişmez: gövde metni için yaklaşık 16px taban boyut, satır uzunluğu ~50-75 karakter ve 1.4-1.6 satır aralığı. Mobilde dar ekran zaten satır uzunluğunu kısalttığı için asıl risk masaüstünde satırların aşırı uzayıp okunaklığı düşürmesidir; akışkan ızgara ve maksimum genişlik (max-width) sınırlarıyla bunu kontrol altında tutarsınız. Bir uyarı: clamp ile ölçeklenen font boyutlarını fazla agresif kurarsanız, çok küçük ekranlarda gövde metni 16px'in altına düşebilir; bu hem okunabilirliği hem erişilebilirliği zedeler ve bazı mobil tarayıcılarda istenmeyen otomatik yakınlaştırma davranışını tetikler. Bu yüzden clamp'in alt sınırını okunabilir bir tabana (gövde için ~16px) sabitlemek iyi bir disiplindir. Görsel hiyerarşi, boşluk yönetimi ve tipografi gibi temellerin nasıl bir araya geldiğini iyi web tasarımı nasıl olmalı yazımızda topluca işliyoruz.

Esnek Görseller ve Dokunmatik Hedefler

Görseller responsive tasarımın hem en kritik hem en sık ihmal edilen tarafıdır. İki ayrı sorunu birlikte çözmeniz gerekir:

• Boyut esnekliği: Görsellerin kapsayıcıya sığması için akışkan davranması gerekir; ama dikkat, her img, video, iframe ve reklam alanına açık genişlik-yükseklik (veya aspect-ratio) tanımı vermek şarttır. Aksi halde görsel yüklenirken yer ayrılmaz, içerik aşağı kayar ve Cumulative Layout Shift (CLS) bozulur. CLS'nin en yaygın kök nedeni tam olarak budur: görsele yer ayırmamak. Hedef değer hatırlatma olsun: CLS "iyi" eşiği 0,1 ve altıdır.
• Mobilde ağırlık: Mobil cihazlar daha yavaş işlemci ve şebeke kullandığı için görsel optimizasyonu, lazy-load (geç yükleme) ve modern formatlar (WebP/AVIF) mobil Core Web Vitals için belirleyicidir. Özellikle ekranın en üstündeki en büyük görsel (LCP öğesi) preload edilmeli, kritik olmayanlar geç yüklenmelidir. Pratik bir incelik: ilk ekranda görünen LCP görselini lazy-load etmeyin; geç yükleme yalnızca ekran dışı (below the fold) görseller içindir, aksi halde LCP'yi yavaşlatırsınız.

Mobil için tek bir dev görseli küçültüp servis etmek yerine, farklı ekran genişliklerine farklı boyutta görsel sunmak (responsive images: srcset ve sizes öznitelikleri) mobil veri ve LCP açısından büyük fark yaratır. 360px genişlikteki bir telefona masaüstü için hazırlanmış 1920px'lik bir görseli indirtmek, hem gereksiz veri tüketir hem LCP'yi geciktirir. Tarayıcının cihaza uygun en küçük yeterli görseli seçmesini sağlamak, mobilde "tasarımı bozmadan hızlanmanın" en kazançlı yollarından biridir.

Dokunmatik hedef boyutu, mobil-öncelikli tasarımın erişilebilirlikle kesiştiği yerdir. WCAG 2.2 SC 2.5.8 (AA seviyesi) minimum 24x24 CSS piksel veya yeterli boşluk şartı getirir; Apple Human Interface Guidelines 44x44 pt, Google Material 48x48 dp önerir; WCAG 2.5.5 (AAA) ise 44x44 piksel ister. Aşağıdaki tablo bu referansları tek bakışta toplar:

Pratik tavsiyemiz: butonlar ve dokunulabilir öğeler için en az 44-48px hedefleyin ve aralarına yeterli boşluk bırakın; özellikle yan yana duran iki bağlantı arasında yeterli aralık olmazsa kullanıcı yanlış öğeye dokunur ("fat finger" hatası). Fitts Yasası burada doğrudan devreye girer; bir hedefe ulaşma süresi onun büyüklüğü ve uzaklığıyla ilişkilidir, dolayısıyla mobilde sık kullanılan butonlar büyük ve başparmağın kolay erişebileceği alanda (genellikle ekranın alt yarısı) olmalıdır. Sticky (sabit) bir alt aksiyon çubuğunda birincil CTA'yı tutmak, uzun sayfalarda dönüşümü pratikte yükselten bir kalıptır; çünkü kullanıcı CTA'ya ulaşmak için yukarı kaydırmak zorunda kalmaz. Bu erişilebilirlik standartlarının bütününü web erişilebilirliği nedir nasıl sağlanır yazımızda ele alıyoruz.

Mobil Performans ve Dönüşüm: Tasarımın Görünmeyen Yarısı

Mobil-öncelikli tasarım sadece düzenle ilgili değildir; performans ve dönüşümle iç içedir. Mobilde Core Web Vitals eşiklerini tutturmak masaüstünden daha zordur, çünkü cihaz daha güçsüzdür. Üç temel metrik ve "iyi" eşikleri (75. yüzdelik saha verisi) şunlardır:

INP, 12 Mart 2024'te FID'in (First Input Delay) yerini alarak resmî Core Web Vital oldu ve tek bir gecikmeyi değil tüm etkileşim yaşam döngüsünü (giriş gecikmesi + işleme + sunum) ölçtüğü için ağır JavaScript'e karşı çok daha hassastır. Mobilde ağır script ana iş parçacığını bloke edip dokunma yanıtını geciktirdiğinden, az script, kod bölme (code splitting) ve uzun görevleri parçalama mobil INP için kritiktir. CLS tarafında font kaynaklı kaymayı da unutmamak gerekir: @font-face üzerinde size-adjust descriptor'ı CLS'yi örneğin 0,15'ten 0,02'ye düşürebilir ve gövde metni için font-display: swap metnin hemen görünmesini sağlar. Bu metriklerin tasarım tarafındaki ayrıntılarını site hızı ve SEO Core Web Vitals rehberi yazımızda, ölçüm ve iyileştirme tarafını ise PageSpeed Insights nasıl iyileştirilir yazımızda bulabilirsiniz.

Bir başka kritik nokta: mobilde dönüşüm oranı genellikle masaüstünden düşüktür. Bunun nedeni çoğu zaman küçük ekrandaki form ve ödeme sürtünmesidir. Bu yüzden mobil form akışını ayrıca optimize etmek gerekir. Pratikte fark yaratan ayarlar:

• Otomatik doldurma (autofill): Alanlara doğru autocomplete ipuçları verin; kullanıcı ad, e-posta, adres ve kart bilgilerini tek dokunuşla doldurabilsin.
• Doğru klavye tipi: E-posta alanında @'li klavye, telefon alanında numara tuş takımı, sayısal alanda sayı klavyesi açılmalı; bu, doğru inputmode ve alan tipiyle sağlanır.
• Az alan, tek sütun: Mobilde her ek form alanı terk oranını yükseltir; yalnızca gerçekten gerekli olanı isteyin ve alanları tek sütun dizin.
• Tek elle erişim: Gönder butonunu başparmağın doğal eriştiği alt bölgede tutun; minik ve sayfanın en tepesinde bir buton mobilde sürtünme yaratır.
• Net hata geri bildirimi: Hatalı alanı anında, alanın yanında ve çözüm önerisiyle gösterin; kullanıcıyı gönder'e basıp en başa dönmeye zorlamayın.

Bu küçük ayarlar, dönüşüm-kritik sayfalarda ölçülebilir fark yaratır; dönüşüm odaklı landing page rehberi yazımız bu sürtünme azaltma prensiplerini derinleştiriyor. E-ticaret tarafında mobil ödeme akışındaki sürtünmenin dönüşüme etkisini ise e-ticarette dönüşüm oranı nasıl artırılır yazımızda ele alıyoruz.

Mobil Sürümü Test Etmek ve Doğrulamak

Mobil-öncelikli tasarım, gerçek cihaz ve gerçek koşulda test edilmeden tamamlanmış sayılmaz. Tarayıcı geliştirici araçlarının cihaz simülasyonu iyi bir başlangıçtır, ancak gerçek bir telefonda, hatta yavaş bağlantı (throttling) simülasyonuyla test etmek şarttır; çünkü simülasyon işlemci yavaşlığını ve dokunma ergonomisini tam yansıtmaz. Bir başka önemli ayrım: CWV ölçümünde "lab" (laboratuvar, tek seferlik test) verisi ile "saha" (gerçek kullanıcı, Chrome'un toplu verisi) verisi farklıdır. Sıralamayı etkileyen saha verisidir; bu yüzden lab testinde yeşil görünmek yetmez, gerçek kullanıcı verisini de izlemelisiniz.

Yayın öncesi mobil kontrol listemiz şu maddeleri içerir:

• Viewport meta etiketi doğru tanımlı mı (yatay kaydırma çubuğu çıkmıyor mu)?
• Gerçek bir telefonda, yavaş bağlantı simülasyonuyla LCP/INP/CLS ölçüldü mü?
• Tüm dokunma hedefleri en az 44-48px ve aralarında yeterli boşluk var mı?
• Her görsele genişlik-yükseklik ya da aspect-ratio tanımlandı mı (CLS kontrolü)?
• Formlar doğru klavye tipi, autofill ve tek elle erişilebilir buton ile çalışıyor mu?
• Türkçe karakterler (ç, ğ, ı, İ, ö, ş, ü) ve özellikle noktalı/noktasız I ayrımı ekranda doğru render oluyor mu? Sayfada lang="tr" tanımlı mı?
• Mobil menü tanıdık ve erişilebilir mi; kritik bağlantılar gömülü kalmadı mı?

Sitenizin gerçek altyapısının mobile-first prensiplere uygun kurulması ya da mevcut sitenizin mobil uyumluluğunun ve hızının profesyonel denetimi için web ve mobil UI/UX tasarımı hizmetimizden yararlanabilir, sitenizin durumunu öğrenmek için ücretsiz bir analiz talep edebilirsiniz.

Özetle mobil-öncelikli yaklaşım bir moda değil, 2026'nın kalıcı ilkesidir: trafiğin çoğunluğu mobilde, Google indekslemesi mobil sürüm üzerinden, ve en kısıtlı ortam için tasarlamak hem hız hem netlik hem erişilebilirlik kazandırır. Breakpoint'i içeriğin bozulduğu yere koyun, esnek ızgara ve clamp tabanlı akışkan tipografiyle çalışın, her görsele boyut tanımlayın, dokunma hedeflerini 44-48px tutun ve mobil performansı bir tasarım gereği olarak ele alın. Bu temeli doğru attığınızda, daha büyük ekranlar zaten kendiliğinden iyi görünür.

Mobilde Dokunmatik Deneyim Neden Ayrı Bir Tasarım Disiplinidir?

Dokunmatik deneyim, masaüstündeki imleç (mouse) mantığının değil, parmağın fiziksel gerçekliğinin kurallarıyla çalışan ayrı bir tasarım disiplinidir. Fare ile piksel hassasiyetinde tıklarsınız; parmakla yaklaşık 9-10 mm genişliğinde bir temas alanıyla ve çoğu zaman tek elle, hareket hâlinde, küçük bir ekranda dokunursunuz. Bu yüzden mobil tasarımda üç şey doğrudan dönüşümü belirler: dokunmatik hedeflerin yeterince büyük ve aralıklı olması, navigasyonun tek elle erişilebilir olması ve formların sürtünmeyi en aza indirecek kadar sade olması. Bunları ihmal eden bir site masaüstünde mükemmel görünse de mobilde "tıklanamayan buton", "yanlış basılan link" ve "yarıda terk edilen form" üretir.

Farkın kökeni girdi modelidir. Fare, ekranda sürekli görünen bir imleç sağlar; bu imleç "hover" (üzerine gelme) durumunu üretir ve kullanıcı tıklamadan önce nereye geleceğini görür. Parmakta hover yoktur: dokunduğunuz an eylem gerçekleşir, ön izleme penceresi yoktur. Bu tek farkın bile büyük tasarım sonuçları vardır. Yalnızca hover ile açılan açılır menüler (dropdown), yalnızca üzerine gelince beliren araç ipuçları (tooltip) veya yalnızca hover ile görünür hâle gelen "düzenle/sil" ikonları mobilde ya hiç çalışmaz ya da kullanıcıyı "ghost tap" denen, ilk dokunuşun menüyü açtığı, ikinci dokunuşun seçtiği iki adımlı kafa karışıklığına sokar. Pratik kural: hover ile erişilen her işlev, dokunmayla da doğrudan erişilebilir bir karşılığa sahip olmalı; kritik bilgi yalnızca hover'ın arkasına saklanmamalıdır.

Bu mesele küçük bir detay değil: küresel web trafiğinin yaklaşık %60'ı mobilden geliyor (2026, StatCounter; kaynağa ve döneme göre %52-64 arasında değişiyor) ve Türkiye gibi pazarlarda bu oran %80'e çıkıyor. Üstelik Google, sitenin masaüstü değil mobil sürümünü indeksleyip sıralıyor (mobile-first indexing varsayılan). Yani mobilde eksik içerik veya çalışmayan etkileşim doğrudan SEO kaybıdır; mobil dokunmatik deneyim hem dönüşümün hem aramada görünürlüğün temelidir. Bu rehberin web sitesi yapma adımlarını ve UI/UX ilkelerini anlatan parçalarıyla birlikte okunması, mobil-öncelikli bakışı tamamlar.

Dokunmatik ile Fare Mantığı Arasındaki Pratik Farklar

Aşağıdaki karşılaştırma, masaüstü için kurgulanmış bir arayüzü mobile taşırken nelerin bozulduğunu özetler. Müşterilerimizde en sık gördüğümüz mobil hataların büyük kısmı, bu farkların gözden kaçırılmasından doğar.

Dokunmatik Hedef Boyutu Ne Kadar Olmalı?

Pratik cevap: dokunulabilir her öğe (buton, link, menü ikonu, onay kutusu) en az 44-48 CSS pikseli olmalı ve komşu hedeflerle arasında yeterli boşluk bulunmalı. Bu, parmak temas alanının fiziksel genişliğiyle uyumlu en güvenli aralıktır. Standartlar bu konuda örtüşür: WCAG 2.2'nin SC 2.5.8 (AA seviyesi) başarı kriteri minimum 24x24 CSS pikseli (veya yeterli boşluk) şart koşar; WCAG 2.5.5 (AAA) ise 44x44 piksel önerir. Apple İnsan Arayüzü Yönergeleri (HIG) 44x44 pt, Google Material Design 48x48 dp tavsiye eder. Üç kaynağın da buluştuğu güvenli pratik: gerçek hedef boyutunu en az 44-48px tutmak.

Bu rakamları somutlaştırmak için referansları tek bir tabloda toplamak faydalı olur; özellikle "yasal asgari" ile "iyi pratik" arasındaki farkı görmek karar verirken yön gösterir.

Burada kritik bir ayrım var: görünen boyut ile dokunulabilir boyut aynı olmak zorunda değildir. Görsel olarak küçük bir ikon (örneğin 24px'lik bir çarpı/kapat ikonu) bırakabilirsiniz; ama etrafına şeffaf dolgu (padding) ekleyerek tıklama alanını 44px'e çıkarabilirsiniz. CSS tarafında bunu padding ile büyütmek, min-height/min-width tanımlamak veya görünmez bir ::before katmanıyla dokunma alanını genişletmek yaygın çözümlerdir. Önemli olan, denetim araçlarının ölçtüğü görünür kutu değil, kullanıcının parmağının isabet ettiği gerçek dokunma alanıdır; ikisini ayırmak, tasarımı sadeleştirip dokunmayı kolaylaştırmanın en pratik yoludur.

Bir başka sık hata, retina/yüksek yoğunluklu ekranlarda boyutları cihaz pikseliyle karıştırmaktır. Tüm bu eşikler CSS pikseli cinsindendir; tarayıcı, yoğun ekranlarda CSS pikselini birden fazla fiziksel piksele haritalar. Yani 44 CSS px, ekran ne kadar keskin olursa olsun parmak için aynı fiziksel boyutta kalır. Doğru viewport meta etiketi (width=device-width) olmadan bu eşleme bozulur ve sayfa "küçültülmüş masaüstü" gibi açılarak tüm hedefleri dokunulamayacak kadar küçültür; bu yüzden viewport tanımı mobil dokunmatik deneyimin görünmez ama zorunlu temelidir.

Hedefler Arası Boşluk Neden Boyut Kadar Önemli?

İki buton ölçü olarak yeterince büyük olsa bile, yan yana sıkışıklarsa kullanıcı yanlışına basar ("fat finger" hatası). WCAG 2.5.8, küçük hedeflere boşlukla istisna tanır: hedef 24px'in altındaysa, çevresinde başka hedefe değmeyen en az 24px'lik bir alan bırakılırsa kriter yine karşılanır. Pratikte iki dokunmatik öğe arasında en az 8px, tercihen daha fazla dikey/yatay boşluk bırakmak yanlış dokunmayı belirgin biçimde azaltır. Özellikle şu noktalara dikkat edin:

• Yan yana ikonlar: Paylaş, beğen, sil gibi aksiyon ikonları sıralanırken her birine ayrı dokunma alanı ve aralarına boşluk verin.
• Liste satırları: Tıklanabilir satırlarda tüm satırı dokunma hedefi yapın; sadece içindeki küçük metni değil.
• Metin içi linkler: Bir paragraf içinde art arda gelen iki link satır kaymasıyla üst üste binebilir; satır aralığını (1.4-1.6) yeterli tutun.
• Form alanları + onay kutuları: Küçük checkbox/radio'ların yanındaki etiket metnini de (label) tıklanabilir yapın, böylece hedef büyür.
• Sayfalama ve adım kontrolleri: Sayfa numaraları, "+/-" miktar artırıcılar ve takvim günleri gibi küçük, sık dizilen hedeflerde boşluğu özellikle artırın; bunlar yanlış dokunmanın en yaygın yaşandığı bileşenlerdir.

Yıkıcı ve geri alınamaz eylemlerde boşluk meselesi ayrıca önem kazanır. "Kaydet" ile "Sil", ya da "Devam et" ile "İptal" butonlarını yan yana ve aynı görsel ağırlıkta koyarsanız, mobilde yanlış dokunma kaçınılmaz olur. Çözüm: yıkıcı eylemi görsel olarak farklılaştırmak (renk tek başına yetmez; konum ve ikon da değiştirin), aralarına belirgin boşluk koymak ve gerekirse bir onay adımı eklemektir. Bu, aynı zamanda bir erişilebilirlik gereğidir; konuyu derinlemesine ele aldığımız web erişilebilirliği rehberinde WCAG 2.2'nin getirdiği hedef boyutu kriterini daha ayrıntılı bulabilirsiniz.

Başparmak Bölgesi (Thumb Zone) Tasarıma Nasıl Yansır?

Çoğu kullanıcı telefonu tek elle tutar ve başparmağıyla dokunur. Başparmağın rahatça uzandığı alan, ekranın alt-orta bölgesidir; üst köşeler (özellikle sol-üst, sağ-elini kullanan biri için) en zor erişilen bölgedir. Ekranlar büyüdükçe (6,5-7 inç telefonlar yaygınlaştıkça) bu sorun daha da belirginleşir: üst kenara yerleştirilen bir "menü" ya da "ara" butonuna ulaşmak için kullanıcı ya elini kaydırır ya ikinci elini kullanır; her ikisi de sürtünmedir. Bunun tasarıma üç pratik sonucu vardır:

• Birincil eylem butonunu (CTA) ve ana navigasyonu mümkünse ekranın alt yarısına yerleştirin; uzaktaki üst köşelere değil.
• "Geri", "kapat" gibi sık kullanılan kontrolleri başparmağın doğal yayına denk getirin.
• Yıkıcı eylemleri (sil, ödemeyi tamamla) erişimi kolay ama yanlışlıkla basılmayacak şekilde konumlandırın; gerekirse onay adımı ekleyin.

Pratik bir ölçüt olarak ekranı üç bölgeye ayırabilirsiniz: alt üçte bir (başparmakla en kolay, "doğal"), orta üçte bir (rahat, "esneme"), üst üçte bir (zor, "uzanma"). Sık kullanılan ve dönüşüm getiren eylemleri alt bölgeye; nadiren dokunulan ama tehlikeli eylemleri (hesabı sil gibi) bilinçli olarak zor bölgeye yerleştirmek mantıklıdır — kolay erişim her zaman iyi değildir, yanlış dokunmaması gereken bir eylem için zorluk bir koruma katmanıdır.

Bu mantık doğrudan Fitts Yasası'yla örtüşür: bir hedefe ulaşma süresi, hedefin uzaklığı ve büyüklüğüyle ters orantılıdır. Yani önemli ve sık kullanılan butonlar hem büyük hem de parmağa yakın olmalıdır. Tasarımda bunu sezgiselleştirmek, web ve mobil UI/UX tasarımı çalışmasının en somut çıktılarından biridir.

Mobil Navigasyon Nasıl Tasarlanmalı?

Mobil navigasyonun amacı, sınırlı ekranda kullanıcının "neredeyim, nereye gidebilirim" sorusunu hızla cevaplamaktır. Masaüstündeki geniş yatay menüyü olduğu gibi sıkıştırmak çalışmaz; menüyü mobile uyarlamak gerekir. Bu, bilgi mimarisinin (IA) mobilde sınanması demektir: masaüstünde 7 ana sekme rahat dururken, mobilde aynı 7 sekmeyi sığdırmaya çalışmak ya kalabalık bir çubuk ya da her şeyi yutan bir hamburger doğurur. Çoğu durumda doğru hamle menüyü kısaltmak — yani gerçekten birincil olan 3-5 hedefe odaklanıp gerisini ikincil katmana indirmektir. En yaygın kalıplar şunlardır ve her birinin yeri farklıdır:

Hamburger menü yer kazandırır ama bir bedeli vardır: içeriği görünmez kıldığı için kullanıcılar oradaki linkleri daha az keşfeder. Bu yüzden kritik eylemleri hamburger içine gömmeyin. "Teklif al", "İletişime geç", "Sepete git" gibi dönüşüm odaklı butonlar menüden bağımsız, her zaman görünür olmalıdır. Burada Hick Yasası devreye girer: seçenek sayısı arttıkça karar süresi uzar; mobil menüde linkleri sadeleştirip karar yükünü azaltmak doğrudan dönüşüme yarar. İçeriğin gizlenmesini hafifletmenin bir yolu, hamburger ikonuna "Menü" etiketi eklemektir; çıplak üç çizgi ikonu kimi kullanıcı için yeterince tanıdık olmayabilir ve etiket, keşfedilebilirliği ölçülebilir biçimde artırır.

Hamburger mi, Alt Sekme Çubuğu mu?

Net ayrım: site bir uygulama gibi 3-5 ana bölüm etrafında dönüyorsa (örneğin bir e-ticaret: Ana sayfa, Kategoriler, Sepet, Hesabım) alt sekme çubuğu genellikle daha iyidir, çünkü başparmak bölgesinde durur ve bölümler her zaman görünür. İçerik/kurumsal bir sitede onlarca bölüm varsa hamburger kaçınılmazdır; ama o zaman bile arama kutusu ve birincil CTA dışarıda kalmalıdır. İki kalıp birbirini dışlamaz: yaygın bir hibrit yaklaşım, ana 4 hedefi alt sekme çubuğuna koyup beşinci sekmeyi "Daha fazla" (hamburger benzeri) olarak ek bölümlere açmaktır — böylece sık kullanılan her şey görünür kalır, kuyruk uzunluğu gizli katmana iner.

Tutarlılık ilkesi de önemli: menü ikonu, açılma davranışı ve etiketleme her sayfada aynı olmalı (Jakob Yasası — kullanıcılar diğer sitelerden öğrendikleri kalıbı bekler). Aynı şekilde, "geri" davranışı tahmin edilebilir olmalı: tarayıcının geri tuşu menüyü kapatmalı, kullanıcıyı beklenmedik bir sayfaya fırlatmamalı. Bu navigasyon kararları, kurumsal yapılarda kurumsal web sitesi rehberinde ve B2B sitelerde ele aldığımız bilgi mimarisiyle iç içedir.

Mobil Navigasyonda Performans ve Erişilebilirlik

Görünmez bir tuzak: menü, ekranda yer kaplamadığı için "ucuz" sanılır, oysa kötü kodlanmış bir hamburger menü hem performansı hem erişilebilirliği bozar. Birkaç temel kural:

• Klavye ve ekran okuyucu erişimi: Menü düğmesi gerçek bir button olmalı, açık/kapalı durumu aria-expanded ile bildirilmeli; menü açıldığında odak (focus) menüye taşınmalı ve menü açıkken odak menü içinde tutulmalı (focus trap).
• Görünür odak halkası: Klavyeyle gezenler için odaklanan öğe belirgin olmalı (WCAG 2.2 odak görünürlüğü kriteri); outline:none ile odak halkasını silmek erişilebilirliği bozan en yaygın hatalardandır.
• Layout kayması yok: Menü açılırken/kapanırken sayfa içeriği zıplamamalı; bu CLS'yi (Cumulative Layout Shift, iyi eşik <=0,1) bozar.
• Az JavaScript: Ağır menü animasyonları ana iş parçacığını meşgul ederek INP'yi (Interaction to Next Paint, iyi eşik <=200 ms) kötüleştirir; sade CSS geçişleri tercih edin.
• Hareket duyarlılığı: Büyük geçiş animasyonlarında prefers-reduced-motion tercihine saygı gösterin; bazı kullanıcılarda ani hareket rahatsızlık yaratır.

Erişilebilirlik tarafının somut bir karşılığı vardır: WebAIM'in yıllık raporlarında en sık görülen hatalar arasında boş butonlar ve etiketsiz öğeler başı çeker; bir hamburger ikonu yalnızca grafikten ibaretse ve erişilebilir adı yoksa (örneğin aria-label="Menü"), ekran okuyucu kullanan biri için o buton "boş düğme" olarak okunur ve site gezilemez hâle gelir. Mobilde performans neden bu kadar kritik diye merak ediyorsanız, site hızı ve Core Web Vitals rehberimiz ile PageSpeed Insights iyileştirme rehberimiz bu metrikleri ölçme ve düzeltme adımlarını anlatıyor.

Mobil Formlar Neden Bu Kadar Sık Terk Ediliyor?

Kısa cevap: form, mobilde kullanıcının en çok emek harcadığı ve en kolay vazgeçtiği yerdir. Küçük ekranda yazmak zordur, yanlış klavye açılır, alanlar üst üste biner ve gereksiz her alan terk oranını yükseltir. Mobilde dönüşüm zaten masaüstünden düşük olma eğilimindedir; bu yüzden mobil form akışını ayrıca optimize etmek gerekir. Temel ilke, dönüşüm odaklı tasarımın özüyle aynıdır: sürtünmeyi azaltan, az alanlı form. Sorulmasını zorunlu kılmadığınız her alanı kaldırın; "telefon" gerçekten gerekli değilse istemeyin. Bir alanı eklemenin maliyeti her zaman somut bir terk riskidir; eklemeden önce "bu bilgi olmadan satışı/lead'i tamamlayabilir miyim?" diye sormak iyi bir filtredir.

Düzen tarafında mobil formun altın kuralı tek sütundur. Masaüstünde yan yana iki alan (ad / soyad) rahat dururken, mobilde dar ekrana sıkıştırıldıklarında ikisi de daralır ve dokunması zorlaşır; alanları alt alta, tek sütun akışında dizmek hem isabeti hem doldurma hızını artırır. Alan başına tek bir net soru, ilerleme hissi ve daha az kaydırma demektir.

Doğru Klavye ve Otomatik Doldurma

Mobil formlardaki en büyük kazanç, tarayıcının kullanıcıya yardım etmesine izin vermektir. Her giriş alanına doğru girdi tipini ve otomatik doldurma ipucunu tanımlayın:

• Doğru klavye tipi: E-posta alanında type="email" (klavyede @ görünür), telefon alanında type="tel" (sayısal tuş takımı), sayı/tutar alanında inputmode="numeric", URL alanında type="url". Yanlış klavye, kullanıcıyı sembol/harf arasında gezdirir ve yorar.
• Otomatik doldurma (autocomplete): autocomplete özniteliğiyle ad, e-posta, adres, kart gibi alanları tanımlayın (örneğin autocomplete="email", autocomplete="tel"); tarayıcı/telefon bunları tek dokunuşla doldurur. Bu, WCAG 2.2'nin "gereksiz tekrar girişin önlenmesi" ilkesiyle de örtüşür.
• Tek elle erişim: Gönder butonu başparmak bölgesinde olsun; klavye açıldığında butonun klavyenin altında kaybolmamasına dikkat edin.
• Etiketler yerinde kalsın: Yalnızca placeholder (yer tutucu) kullanmayın; kullanıcı yazmaya başlayınca ipucu kaybolur ve hangi alanı doldurduğunu unutur. Görünür, kalıcı label kullanın.
• Türkçe karakter ve büyük/küçük harf: Form alanlarında ve doğrulamada noktalı/noktasız I ayrımına dikkat edin; sayfa lang="tr" tanımlı ve UTF-8 olmalı ki "İstanbul" gibi girişler doğru işlensin.

Akıllı varsayılanlar da sürtünmeyi düşürür: ülke kodunu Türkiye için önceden seçmek, tek bir adres alanını birden çok küçük parçaya bölmemek, gereksiz "doğrulama kodunu tekrar girin" adımlarından kaçınmak gibi küçük kararlar mobilde toplamda büyük fark yaratır.

Hata Geri Bildirimi ve Doğrulama

Mobilde hatalı bir form, kullanıcıyı kolayca kaçırır. Nielsen sezgisel ilkelerinden ikisi burada belirleyicidir: sistem durumu her zaman görünür olmalı ve hata mesajları net, çözüm önerili olmalı. Pratikte:

• Hatayı, ilgili alanın hemen yanında ve anlaşılır bir dille gösterin ("Geçerli bir e-posta girin" gibi); kırmızı bir kenarlık tek başına yetmez (renk tek başına bilgi taşımamalı — renk körlüğü). Hata metnine küçük bir ikon veya açık ifade ekleyin.
• Doğrulamayı mümkünse alan terk edilince (anlık) yapın; kullanıcı tüm formu doldurup gönderdikten sonra başa dönmek zorunda kalmasın. Ama yazarken her tuşta hata fırlatmayın; bu da rahatsız edicidir.
• Gönder butonuna basıldığında "sistem dinliyor" geri bildirimi verin (yükleniyor durumu, butonu pasifleştirme); aksi halde kullanıcı tekrar tekrar basar ve çift gönderim oluşur.
• Hata oluştuğunda doğru alana otomatik odaklanın/kaydırın; mobilde kullanıcının hatalı alanı kendisi araması büyük bir terk nedenidir.
• Başarıda net bir onay gösterin; boş ekranla bırakmayın. İşlevsel mikro etkileşim (onay işareti, kısa bir geçiş) kullanıcıya "tamamlandı" hissi verir.

Yasal tarafı da unutmayın: Türkiye'de iletişim/kayıt formlarında KVKK aydınlatma metni ile açık rıza/ticari ileti izni ayrı ayrı sunulmalıdır — KVKK'nın güncel İlke Kararı bunu pekiştirdi; tek kutuda "hepsini kabul ediyorum" hukuken sakıncalıdır. Mobilde yer dar diye bu onayları tek kutuya sıkıştırmak hem yasal risk hem güven kaybıdır; doğru çözüm, aydınlatma metnine erişilebilir bir bağlantı vermek ve ticari ileti onayını ayrı, varsayılan olarak işaretsiz bir kutuda sunmaktır. Form ve dönüşüm optimizasyonunu daha derin ele aldığımız dönüşüm odaklı landing page rehberi bu konuda iyi bir devam okumasıdır.

Yapışkan (Sticky) CTA: Eylem Hep Elinizin Altında

Yapışkan CTA, kullanıcı sayfayı kaydırırken bile ekranda sabit kalan birincil eylem butonudur (örneğin altta sabit bir "Teklif Al" ya da "Sepete Ekle" çubuğu). Mantığı basittir: kullanıcı uzun bir mobil sayfada aşağı indikçe üstteki butonu kaybeder; eylemi her an erişilebilir tutmak, "dönüşmek isteyince yukarı kaydırma" sürtünmesini ortadan kaldırır. Tek net birincil CTA ilkesiyle birleştiğinde güçlü bir dönüşüm aracıdır. Doğru kullanım için birkaç kural:

• Tek ve net olsun: Yapışkan çubukta birden çok eşit ağırlıkta buton olmamalı; bir birincil eylem, en fazla bir ikincil link.
• Başparmak bölgesinde: Genellikle ekranın altında durması hem erişimi hem tıklamayı kolaylaştırır (Fitts Yasası).
• Yeterince büyük dokunma hedefi: Çubuktaki buton 44-48px yüksekliğinde ve kenar boşluklarıyla rahat dokunulur olmalı.
• İçeriği örtmesin: Sabit çubuk, alttaki metni veya formu kapatmamalı; sayfa içeriğine alt boşluk (padding) bırakın. Özellikle yasal metinlerin (KVKK, mesafeli satış linki) sabit çubuk altında kalmamasına dikkat edin.
• Layout kaymasına yol açmasın: Çubuk için baştan yer ayırın; sonradan "atlayarak" gelmesi CLS'yi bozar.
• Klavye açılınca akıllı davransın: Form doldurulurken klavye açıldığında sabit çubuğun gönder butonunu örtmemesi için gerekirse çubuğu geçici gizleyin.

Yapışkan CTA özellikle hizmet ve B2B sitelerinde işe yarar; çünkü B2B'de dönüşüm genelde "satın al" değil "teklif iste / demo planla / iletişime geç"tir ve bu eylemin her an görünür olması karar anını yakalar. E-ticarette ise ürün sayfasında sabit "Sepete Ekle" çubuğu, uzun ürün açıklamaları ve yorumlar arasında kaybolmadan satın almayı kolaylaştırır. Yine de yapışkan öğeyi abartmamak gerekir: ekranın hem üstünü hem altını sabit çubuklarla doldurmak, zaten dar olan mobil görüntü alanını daraltır ve içeriği boğar; tek, amaca hizmet eden bir sabit eylem genelde en iyisidir.

Kendi sitenizin mobil dokunmatik deneyimini, hız ve dönüşüm açısından ölçülü bir gözle değerlendirmek isterseniz ücretsiz analiz sihirbazımız üzerinden başlayabilir; kapsamlı bir yenileme düşünüyorsanız web sitesi yenileme (redesign) rehberimizi inceleyebilirsiniz. Mobil-öncelikli, dokunmatik deneyimi en baştan doğru kurgulanmış bir arayüz; hem Google'ın mobil-öncelikli indekslemesinde hem de gerçek kullanıcı dönüşümünde fark yaratır.

Mobilde Hız ve Core Web Vitals (INP) Neden Belirleyici?

Mobilde hız, sitenizin sıralamasını ve dönüşümünü doğrudan etkileyen ölçülebilir bir performans bütçesidir; ölçüm standardı ise Core Web Vitals'tır. Google'ın "iyi" kabul ettiği üç eşik, sahada gerçek kullanıcılardan toplanan verinin 75. yüzdeliğine göre hesaplanır: LCP (Largest Contentful Paint) ≤ 2,5 saniye, INP (Interaction to Next Paint) ≤ 200 ms ve CLS (Cumulative Layout Shift) ≤ 0,1. Bu üç metriğin de hepsini geçen siteler ölçülebilir organik SEO iyileşmesi, daha düşük hemen çıkma oranı ve daha yüksek etkileşim görür. Burada kilit ayrıntı şudur: eşik "ortalama" değil 75. yüzdelik üzerinden hesaplanır; yani kullanıcılarınızın en yavaş çeyreğini bile (eski telefon, zayıf şebeke) tatmin etmediğiniz sürece "iyi" rozetini alamazsınız. Ortalaması parlak ama uç senaryosu kötü bir site, raporda kırmızı kalır.

Bu rakamların mobilde ayrı bir önemi var: Google artık mobil öncelikli indeksleme (mobile-first indexing) kullanıyor, yani sitenizin masaüstü değil mobil sürümünü indeksleyip sıralıyor. Üstelik küresel web trafiğinin yaklaşık %60'ı mobil cihazlardan geliyor (2026; kaynak ve döneme göre %52-64 arası değişiyor) ve Türkiye gibi pazarlarda bu oran %80'e çıkabiliyor. Pratik sonuç şu: CWV puanınız esasen mobil cihazlarda ölçülür ve mobil cihazlar daha yavaş işlemci ile daha değişken şebeke kullandığı için, masaüstünde "yeşil" görünen bir site mobilde rahatlıkla "kırmızı" olabilir. Bu yüzden performansı her zaman mobil senaryoyu temel alarak değerlendirin. Konunun bütününü site hızı ve SEO: Core Web Vitals rehberinde ele alıyoruz; bu bölümde özellikle mobil tarafa ve tasarımcı/geliştirici kararlarına odaklanacağız.

Üç Metrik, Mobildeki Asıl Sorumlu ve Çözüm Ekseni

Önce panoramayı netleştirelim. Üç Core Web Vital birbirinden farklı bir deneyim boyutunu ölçer ve mobilde her birinin tipik bir "suçlusu" vardır. Aşağıdaki tablo, hangi metrik kırmızıysa hangi katmana yükleneceğinizi tek bakışta özetler:

Bu üç eksenin neden mobilde sertleştiğini akılda tutmak gerekir: mobil cihaz daha yavaş bir işlemci, daha az bellek ve daha değişken bir şebeke ile çalışır. Masaüstünde "bedava" görünen her kütüphane, her efekt, her boyutsuz görsel, mobilde ölçülen puanı doğrudan aşağı çeker. Bu yüzden mobil hız bir "son rötuş" değil, baştan kurulması gereken bir disiplindir.

INP Nedir, FID'den Farkı Ne?

INP (Interaction to Next Paint), bir kullanıcının sitenizle etkileşime girdikten sonra ekranda görsel yanıtı ne kadar hızlı gördüğünü ölçen metriktir. 12 Mart 2024'te resmî bir Core Web Vital oldu ve eski metrik FID (First Input Delay)'in yerini aldı; FID aynı tarihte emekliye ayrıldı. İyi eşik ≤ 200 ms (75. yüzdelik).

İkisi arasındaki fark mobilde kritik. FID yalnızca ilk etkileşimin giriş gecikmesini ölçüyordu; tarayıcının o ilk dokunuşu işlemeye ne kadar geç başladığını. INP ise sayfadaki tüm etkileşimleri ve etkileşimin tam yaşam döngüsünü ölçer: giriş gecikmesi + olayın işlenmesi (event handler'ların çalışması) + sonucun bir sonraki kareye boyanması (sunum). Yani bir kullanıcı menüyü açtığında, filtreyi değiştirdiğinde veya sepete eklediğinde gerçekte hissettiği gecikmenin tamamını yakalar. Bu yüzden INP, FID'den çok daha kapsamlı ve "gerçek hayata" çok daha yakındır. Mobilde dokunmatik etkileşim yoğun olduğu için (menü açma, akordeon, filtre, form) INP, mobil deneyimin gerçek nabzıdır.

Bu yapısal fark, ölçüm zihniyetini de değiştirir. FID döneminde bir sitenin ilk dokunuşu hızlı yanıtlaması yeterliydi; sayfa açıldıktan sonraki onuncu etkileşim ne kadar takılırsa takılsın metriğe yansımıyordu. INP ile birlikte, kullanıcının oturumu boyunca yaşadığı tüm etkileşimlerin en kötüsüne yakın bir değer raporlanır. Pratikte bu, "ilk ekran hızlı açılıyor ama menü/filtre/sepet ağır" diyen bir e-ticaret sitesinin artık saklanamayacağı anlamına gelir. Mobilde bir kullanıcının tipik yolculuğu kategori filtreleme, varyant seçme, sepete ekleme ve form doldurma gibi onlarca dokunuştan oluştuğu için, INP esasen "bu sitede gezinmek pürüzsüz mü" sorusunun nicel cevabıdır.

Mobilde INP'yi Ne Bozar, Nasıl Düzeltilir?

INP'nin tek numaralı düşmanı ağır JavaScript'tir. JavaScript, tarayıcının ana iş parçacığını (main thread) bloke eder; kullanıcı bir butona dokunduğunda ana iş parçacığı uzun bir görevle meşgulse, tarayıcı dokunuşa yanıt veremez ve arayüz "takılmış" gibi hisseder. Mobil işlemciler masaüstüne göre kat kat yavaş olduğu için, masaüstünde 50 ms süren bir görev mobilde 200-300 ms'yi rahatlıkla aşar. Çözümler doğrudan teknik kararlardır:

• Az JavaScript gönderin. Her kütüphane, her üçüncü taraf script (canlı sohbet, analitik, A/B test, reklam) ana iş parçacığına yük bindirir. Kullanılmayanı tamamen kaldırın. Pratikte sitelerin INP sorununun büyük kısmı kendi kodlarında değil, sonradan eklenen pazarlama/izleme etiketlerindedir.
• Kod bölme (code splitting) yapın. Sayfanın ilk açılışında gerekmeyen JavaScript'i parçalara ayırıp gerektiğinde yükleyin; ilk etkileşim anında ana iş parçacığını boş tutun. Bir ürün sayfasında "yorumlar" veya "benzer ürünler" modülünün kodu, kullanıcı oraya kaydırana kadar yüklenmemelidir.
• Uzun görevleri parçalayın. 50 ms'yi aşan görevleri küçük parçalara bölün ki tarayıcı aralarda kullanıcı etkileşimine yanıt verebilsin. Büyük bir listeyi tek seferde işlemek yerine parçalı işlemek, dokunma anında "nefes alma" boşluğu bırakır.
• Üçüncü taraf script'leri erteleyin. Pazarlama/analitik script'lerini sayfa etkileşime hazır olduktan sonra, kullanıcı etkileşimini bloke etmeyecek şekilde yükleyin. Mümkünse bu script'leri ayrı bir iş parçacığında veya boşta kalma anında çalıştırın.

Tasarım tarafında da bir sorumluluk var: kullanıcıya dokunduğu anda görsel geri bildirim verin (buton durumu, yükleniyor göstergesi). Bu, INP süresini matematiksel olarak kısaltmasa da algılanan hızı iyileştirir ve "sistem dinliyor" hissi verir. Sürtünmeyi azaltan bu tür işlevsel mikro etkileşimler ve UI/UX ilkeleri, mobil deneyimin algısını doğrudan yükseltir. Bir noktayı vurgulamakta fayda var: görsel geri bildirim asla "işi gizlemek" için kullanılmamalı; gerçek gecikmeyi düşürmeden sadece spinner göstermek, kullanıcıyı bir süre oyalar ama tekrarlanan yavaşlıkta güveni daha da yıpratır. Doğru sıra önce gecikmeyi teknik olarak düşürmek, sonra kalan kısa beklemeyi geri bildirimle yumuşatmaktır.

LCP'yi Mobilde Hızlandırmak: Görsel ve Font

LCP, ekranda görünen en büyük içeriğin (genelde hero görseli, hero videosu veya büyük başlık metni) yüklenme süresidir ve mobilde en sık darboğaz görsel ağırlığı ile yazı tipi yüklemesidir. Mobil şebekeler değişken olduğu için ağır bir hero görseli LCP'yi tek başına 2,5 saniyenin üstüne taşır. Somut müdahaleler:

• LCP görselini preload edin. Sayfanın en büyük görselini tarayıcıya erkenden bildirin ki keşfedilmeyi beklemeden indirilmeye başlasın. Tarayıcı normalde görseli ancak HTML'i ayrıştırıp ilgili satıra geldiğinde keşfeder; preload bu keşfi öne çeker.
• Modern görsel formatları ve doğru boyut kullanın. WebP/AVIF gibi sıkıştırması yüksek formatlar, mobil ekran genişliğine göre responsive boyutlandırma ile sunulmalı; mobil cihaza 2000px genişliğinde bir görsel göndermek saf israftır. Aynı görselin telefon, tablet ve masaüstü için farklı çözünürlük varyantlarını sunmak, mobilde indirilen baytı belirgin biçimde azaltır.
• Kritik CSS'i satır içi (inline) verin. İlk ekranı boyamak için gereken stilleri HTML içine gömerek ekstra bir CSS isteğini beklemeden ilk boyamayı hızlandırın. Geri kalan stil daha sonra yüklenebilir.
• Fontu preload + font-display: swap ile yükleyin. Yazı tipini erkenden indirin ve metnin font gelene kadar görünür kalmasını sağlayın; LCP metin tabanlıysa bu doğrudan belirleyicidir.
• Sunucu yanıt süresini iyileştirin. LCP'nin görünmez yarısı sunucu yanıtıdır; edge/CDN üzerinden sunum (örneğin Cloudflare, Vercel, Netlify gibi modern barındırma) TR ziyaretçiye gecikmeyi düşürür. İlk baytın geç gelmesi, sonrasında ne kadar optimize ederseniz edin LCP'ye tavan koyar.

Görseller ve geç yükleme (lazy-load) mobilde özellikle değerlidir: ekranın altındaki görselleri geciktirip yalnızca LCP görselini önceliklendirmek, hem ilk yükü hem veri tüketimini azaltır. Burada sık yapılan bir hata da LCP görselini yanlışlıkla lazy-load etmektir; ilk ekrandaki ana görseli geciktirmek, çözüm sanırken metriği bozar. Kural nettir: ilk ekrandaki en büyük öğeyi önceliklendirin, ekranın altındaki her şeyi erteleyin. Bu optimizasyonları somut adımlarla ölçmek ve doğrulamak için PageSpeed Insights'ı nasıl okuyup iyileştireceğinizi anlatan rehberi kullanabilirsiniz; saha verisini ("Field Data") mutlaka mobil sekmesinden okuyun.

CLS: Mobilde "Zıplayan Sayfa" Sorununu Bitirmek

CLS (Cumulative Layout Shift), sayfa yüklenirken içeriğin beklenmedik şekilde kaymasını ölçer; iyi eşik ≤ 0,1'dir. Mobilde bu metrik özellikle can sıkıcıdır çünkü dar ekranda bir görsel veya banner sonradan yer kapladığında, kullanıcının basmak üzere olduğu buton aniden aşağı kayar ve yanlış yere dokunur. En yaygın kök neden basittir: görsellere önceden yer ayrılmaması. Çözümler nettir:

• Her img, video, iframe ve reklam alanına açık genişlik ve yükseklik verin (veya modern CSS'te aspect-ratio). Böylece tarayıcı görsel inmeden önce o alanı rezerve eder ve içerik zıplamaz.
• Dinamik içeriğe yer rezerve edin. Sonradan yüklenen banner, çerez bandı, reklam veya bildirim çubuğu için önceden boşluk bırakın; tepeye sonradan eklenen bir bant tüm sayfayı aşağı iter. Türkiye'de yasal olarak gereken çerez bandının sayfanın üstüne sonradan binmesi, CLS'nin en sık görülen ve en kolay gözden kaçan sebeplerinden biridir; bu bandı yer kaplayacak şekilde baştan konumlandırın.
• Font kaynaklı kaymayı önleyin. Web fontu yüklenince metin yeniden akarsa CLS yükselir. @font-face üzerinde size-adjust tanımlayıcısı, yedek font ile web fontu arasındaki boyut farkını eşitleyerek CLS'yi örneğin 0,15'ten 0,02'ye kadar düşürebilir.
• Yeni içeriği görünür alana enjekte etmeyin. "Daha fazla yükle" veya canlı güncellemeler, kullanıcının okuduğu bölümün üstüne değil altına eklenmeli; üstte yapılan ekleme okunan yeri kaydırır.

Türkçe içerikte font seçimi bu noktada güvenlikle değil ama doğrulukla da kesişir: seçtiğiniz yazı tipi Türkçe karakterleri (ç, ğ, ı, İ, ö, ş, ü) ve özellikle noktalı/noktasız I ayrımını düzgün desteklemeli; aksi halde font-display: swap ile metin önce yedek fontla, sonra doğru fontla görününce hem kayma hem karakter sorunu birlikte yaşanır. Bu yüzden web fontu seçerken hem size-adjust ile yakın metrikli bir yedek font tanımlayın hem de fontun Türkçe glif setini gerçek cihazda test edin; sayfanızda lang="tr" ve UTF-8 tanımının doğru olması da büyük/küçük harf dönüşümlerinin (İstanbul/istanbul gibi) bozulmamasını sağlar. Mobil tasarımı en baştan küçük ekrana göre kurmak (mobil öncelikli yaklaşım) bu kaymaların büyük kısmını baştan engeller; ayrıntıyı responsive tasarım rehberinin ilgili bölümlerinde bulabilirsiniz.

Mobilde Dokunmatik Hedefler ve Performans Birlikte Çalışır

Hız ölçümü tek başına yetmez; mobilde etkileşimin isabetli olması da CWV'ye dolaylı yansır. WCAG 2.2'nin SC 2.5.8 başarı kriteri (AA seviyesi) dokunmatik hedefler için minimum 24x24 CSS piksel ister; Apple'ın yönergeleri 44x44 pt, Google Material 48x48 dp önerir. WCAG 2.5.5 (AAA) ise 44x44 piksel ister. Pratik tavsiyemiz en az 44-48px'lik dokunma alanıdır. Bunun INP ile bağı şudur: çok küçük veya birbirine yapışık butonlar yanlış dokunmalara, yanlış dokunmalar da gereksiz ek etkileşimlere ve "tekrar deneme" trafiğine yol açar; her ek etkileşim ana iş parçacığında yeni iş demektir. Yeterince büyük ve aralıklı hedefler hem erişilebilirliği hem ölçülen yanıt kalitesini iyileştirir. Aşağıdaki tablo başlıca yönergeleri tek yerde toplar:

Bir diğer pratik kazanç mobil form akışıdır: doğru klavye tiplerini (e-posta alanı için e-posta klavyesi, telefon için numerik klavye), otomatik doldurma desteğini ve tek elle erişilebilir buton konumlarını sağlamak, hem dönüşümü artırır hem gereksiz etkileşim/yeniden giriş yükünü azaltır. Mobilde dönüşüm masaüstünden düşük olabildiği için bu akışı ayrıca optimize etmek gerekir. Tek elle kullanımı düşünün: ekranın alt yarısı baş parmakla en rahat erişilen bölgedir, bu yüzden birincil eylem butonunu (örneğin "Sepete ekle" veya "Teklif al") sayfanın üst köşesine değil, baş parmağın doğal yörüngesine yerleştirmek hem isabeti hem dönüşümü yükseltir.

Mobil Hızı Doğru Ölçmek: Saha Verisi vs Laboratuvar Verisi

Mobil performansı tartışmadan önce neyin ölçüldüğünü doğru anlamak gerekir, çünkü en sık yapılan hata yanlış veriye bakmaktır. İki tür veri vardır ve aralarındaki fark, bütün kararları etkiler:

• Saha verisi (Field Data / gerçek kullanıcı verisi). Sitenizi gerçekten ziyaret eden kullanıcıların cihaz ve şebekelerinden toplanan veridir. Sıralama bu veriye dayanır. PageSpeed Insights'ın üst kısmı ve Search Console'un Core Web Vitals raporu bu veriyi gösterir; 28 günlük pencerede 75. yüzdelik üzerinden hesaplanır.
• Laboratuvar verisi (Lab Data). Standart bir test cihazı ve şebeke simülasyonuyla, tek seferlik kontrollü ölçümdür (örneğin PageSpeed Insights'ın alt yarısındaki Lighthouse skoru). Sorunu teşhis etmek ve düzeltmeyi doğrulamak için harikadır ama sıralamayı belirlemez.

Pratik kural: bir metriğin başarısız olup olmadığına saha verisinin mobil sekmesinden karar verin, neyi düzelteceğinize laboratuvar verisinin teşhislerinden karar verin. Sık karşılaştığımız bir kafa karışıklığı, Lighthouse skorunun 90+ çıktığı bir sitenin sahada hâlâ kırmızı olmasıdır; sebep genellikle gerçek kullanıcıların test cihazından daha eski telefonlar ve daha zayıf şebeke kullanmasıdır. Bu yüzden "skorum yüksek ama sıralamam düzelmedi" diyorsanız, neredeyse her zaman laboratuvar verisine bakıp saha verisini gözden kaçırmışsınızdır.

Nereden Başlamalı? Mobil Hız İçin Önceliklendirme

CWV'yi mobilde toparlamak isteyen bir ekip için pratik sıralama şudur: önce sahada hangi metriğin başarısız olduğunu PageSpeed Insights veya Search Console'un Core Web Vitals raporundan mobil sekmesinde tespit edin (mutlaka saha/Field verisine bakın, laboratuvar verisi yön gösterir ama sıralama saha verisine dayanır). Genel kalıp olarak görsel ağırlığı ve sunucu yanıtı LCP'yi, ağır/üçüncü taraf JavaScript INP'yi, ölçü verilmemiş görseller ve sonradan eklenen bantlar CLS'yi bozar. Bu üç eksenden hangisi kırmızıysa oraya yüklenin. Birden fazlası kırmızıysa, kullanıcı algısına en geniş yansıyan sırayla ilerleyin: önce sayfanın açılış hissini belirleyen LCP, sonra gezinmenin pürüzsüzlüğünü belirleyen INP, ardından kararlılığı belirleyen CLS. Çoğu zaman tek bir kök neden (örneğin ağır bir üçüncü taraf script ya da boyutsuz hero görseli) birden fazla metriği aynı anda etkiler; o kök nedeni çözmek tek hamlede iki kazanç verir.

Mobil hız çoğu zaman tek bir ayar değil, altyapı kararıdır: ağır eklenti yükü taşıyan bir kurulumla mı, statik/edge sunulan bir mimariyle mi çalıştığınız sonucu belirler. WordPress gibi eklenti yoğun bir altyapıda her eklenti kendi CSS/JS'ini sayfaya eklediği için INP ve LCP zamanla sessizce bozulurken, statik/edge sunulan bir mimaride (örneğin Next.js veya Astro ile üretilmiş, CDN'den dağıtılan bir site) gönderilen JavaScript baştan asgaride tutulur. Hangi yolun size uygun olduğunu görmek için CMS ve altyapı seçimi rehberine bakabilir; sitenizin mevcut performansını ve dönüşüm kaybını ölçülebilir bir raporla görmek isterseniz ücretsiz analiz ve teklif sihirbazımızı kullanabilir ya da hız-odaklı yeniden tasarım için web ve mobil UI/UX tasarımı hizmetimizi inceleyebilirsiniz. Müşterilerimizde gördüğümüz net örüntü şu: mobilde üç eşiği de geçen siteler, hem aramada daha görünür oluyor hem de ziyaretçiyi daha sık müşteriye dönüştürüyor.

Mobil tasarımı nasıl test edersiniz: gerçek cihaz mı, araç mı?

Kısa cevap: ikisi de gerekli; ama tek başına tarayıcı emülatörüne güvenmek, müşterilerimizde en sık gördüğümüz hatadır. Tarayıcı geliştirici araçlarındaki "responsive görünüm", ekranı yalnızca daraltır; gerçek bir telefonun yavaş CPU'sunu, mobil şebeke gecikmesini, dokunmatik isabet hassasiyetini, iOS Safari'nin kendine özgü davranışlarını veya parmakla kaydırma hissini taklit edemez. Doğru yaklaşım katmanlıdır: önce tarayıcı araçlarıyla hızlı kontrol, sonra otomatik denetim araçları, en sonunda gerçek cihazda elle test. Mobil cihazların küresel web trafiğinin yaklaşık %60'ını oluşturduğu (2026; kaynağa göre %52-64 arası değişir), Türkiye gibi pazarlarda bu oranın %80'e çıktığı bir dünyada, mobil deneyimi "test ettik sayılır" diye geçiştirmek doğrudan gelir kaybıdır. Üstelik Google'ın Mobile-First Indexing (mobil öncelikli indeksleme) varsayılan olduğundan, sitenizin mobil sürümü neyse Google'ın gördüğü ve sıraladığı odur; mobilde eksik veya bozuk içerik doğrudan SEO kaybıdır.

Bu yüzden mobil testi bir "yayın öncesi son kontrol" değil, tasarım sürecinin baştan sona içine yerleştirilmesi gereken bir disiplin olarak ele alıyoruz. Müşterilerimizle çalışırken testi üç düzeyde konumlandırıyoruz: tasarım sırasında (her bileşeni kurarken mobil iskeleti önce çiziyoruz), geliştirme sırasında (her commit'te otomatik denetimi tetikliyoruz) ve yayın öncesi (gerçek cihazda baştan sona elle geziyoruz). Bu üç düzey birbirinin yerine geçmez; geç bulunan bir mobil hatanın düzeltme maliyeti, tasarım aşamasında bulunanın kat kat üzerindedir. Aşağıda hangi araçla neyi test edeceğinizi, gerçek cihaz testinin neden vazgeçilmez olduğunu ve müşterilerimizde tekrar tekrar düzelttiğimiz tipik hataları somut olarak açıklıyoruz. Mobil-öncelikli tasarım yaklaşımının temellerini bu kümede ayrıca işliyoruz; isterseniz mobil uyumlu responsive web tasarım rehberinin önceki bölümlerinde breakpoint mantığını ve dokunmatik hedef boyutlarını da gözden geçirebilirsiniz.

Hangi araçla neyi test edersiniz?

Mobil testi tek bir araçla bitmez; her araç farklı bir katmanı görür. Pratikte kullandığımız ve önerdiğimiz sıralama şöyle: önce hızlı görsel ve responsive kontrol için tarayıcı araçları, ardından performans ve erişilebilirlik için otomatik denetim, en son gerçek cihazda elle deneme. Önemli bir ayrımı baştan netleştirelim: araçlar laboratuvar (lab) ve saha (field) verisi olmak üzere iki tür ölçüm üretir. Lighthouse gibi laboratuvar araçları, kontrollü bir ortamda tek seferlik simülasyon yapar; tekrar üretilebilir ve geliştirme sırasında hızlı geri bildirim verir ama tek bir cihaz/ağ varsayımına dayanır. Search Console'un Core Web Vitals raporu gibi saha araçları ise sitenizi gerçekten ziyaret eden binlerce kullanıcının cihazından toplanan veriyi (75. yüzdelik) gösterir; "gerçek dünyada ne oluyor" sorusunun tek doğru cevabı budur. İkisini birlikte okumak, neredeyse her ciddi mobil teşhisin temelidir. Aşağıdaki tablo hangi aracın neyi yakaladığını ve neyi kaçırdığını özetliyor.

Performans tarafında en çok başvurduğumuz araç PageSpeed Insights ve Lighthouse'tur; çünkü bunlar Core Web Vitals'ın üç temel metriğini doğrudan ölçer: LCP (Largest Contentful Paint) için iyi eşik 2,5 saniye veya altı, INP (Interaction to Next Paint) için 200 milisaniye veya altı, CLS (Cumulative Layout Shift) için 0,1 veya altı. Burada kritik nokta şudur: bu eşikler mobil için ayrı, masaüstü için ayrı raporlanır ve mobil neredeyse her zaman daha zayıf çıkar; çünkü mobil cihazlar daha yavaş CPU ve şebeke kullanır. PageSpeed'in mobil sekmesinde kırmızı bir INP görüp masaüstünde yeşil görmek bizi yanıltmamalı; ziyaretçilerinizin çoğu mobilde olduğu için karar verici olan mobil skordur. Bu konuyu derinlemesine ele aldığımız site hızı ve SEO Core Web Vitals rehberi ile PageSpeed Insights nedir ve nasıl iyileştirilir yazılarımız, her metriği nasıl düzelteceğinizi adım adım anlatıyor.

Search Console'un Sayfa Deneyimi ve Core Web Vitals raporu ise bir adım öteye geçer: laboratuvar simülasyonu değil, sitenizi gerçekten ziyaret eden kullanıcılardan toplanan saha verisini (75. yüzdelik) gösterir. Yani Lighthouse'ta "iyi" görünen bir sayfa, gerçek kullanıcı cihazlarında zayıf çıkabilir; ikisini birlikte okumak gerekir. INP'nin 12 Mart 2024'te FID'in (First Input Delay) yerini alarak resmî bir Core Web Vital olduğunu hatırlatalım; INP yalnızca ilk etkileşimi değil, sayfadaki tüm etkileşimleri ve tam yaşam döngüsünü (giriş gecikmesi + işleme + sunum) ölçtüğü için mobilde ağır JavaScript yükü olan sitelerde en çok bu metrik kırmızıya döner. Pratik bir okuma stratejisi öneriyoruz: bir sayfada saha verisi (Search Console / PageSpeed'in üst kısmındaki gerçek kullanıcı verisi) "iyileştirme gerekiyor" diyorsa ama laboratuvar skoru yeşilse, sorun büyük olasılıkla belirli bir cihaz segmentinde veya belirli bir etkileşimde gizlidir; o segmenti gerçek cihazda yeniden üretmek gerekir. Tersine, laboratuvar kırmızı ama henüz saha verisi yoksa (yeni yayınlanmış sayfa), laboratuvar uyarılarını ciddiye alıp düzeltmek en güvenli yoldur.

Gerçek cihaz testi neden vazgeçilmezdir?

Otomatik araçlar muazzam değerlidir ama hiçbiri insanın baş parmağıyla bir butona dokunmasını, sayfayı kaydırırken takılma olup olmadığını veya formda klavye açılınca alanın gerçekten görünür kalıp kalmadığını gösteremez. Müşterilerimizde gördüğümüz hataların önemli bir kısmı yalnızca gerçek cihazda ortaya çıkar. İşte gerçek cihaz testinde özellikle baktığımız noktalar:

• Dokunma isabeti: Tasarım masaüstünde fareyle mükemmel çalışırken, gerçek telefonda iki buton birbirine o kadar yakındır ki parmak yanlış olana basar. WCAG 2.2 SC 2.5.8 (AA) minimum 24x24 CSS piksel dokunmatik hedef şart koşar; daha katı olan WCAG 2.5.5 (AAA) ise 44x44 px ister. Pratikte Apple HIG'in 44x44 pt, Google Material'in 48x48 dp önerisine yakın, yani en az 44-48px hedef boyutu kullanmanızı öneririz. Bu farkı ancak gerçek parmağınızla denerken hissedersiniz; üstelik baş parmağın ekranın üst köşelerine zor uzanması (tek elle kullanım) gibi ergonomik sorunlar da yalnızca cihazı elinize aldığınızda belli olur.
• iOS Safari'nin tuhaflıkları: Sabit (fixed) konumlu öğeler, 100vh yükseklik hesabı, otomatik zoom yapan form alanları (16px altı yazı tipli input'lara odaklanınca Safari sayfayı yakınlaştırır), alt çubuğun kaydırmada görünüp kaybolması ve bunun viewport yüksekliğini anlık değiştirmesi gibi davranışlar masaüstü tarayıcıda asla görünmez. Apple ekosistemi web standartlarını kendine göre yorumladığı için iPhone'da fiziksel test pazarlık konusu değildir; aynı sitenin Android Chrome'da kusursuz, iOS Safari'de bozuk olması çok yaygındır.
• Gerçek hız hissi: Lighthouse "iyi" dese bile, orta segment bir Android telefonda hero görseli geç yüklenip sayfa zıplıyorsa kullanıcı bunu hisseder. Gerçek cihazda LCP ve CLS'yi gözle görmek, rakamların ötesinde bir teşhis sağlar. Üst segment bir test cihazı yanıltıcıdır; ziyaretçilerinizin çoğu amiral gemisi telefon kullanmaz, bu yüzden mümkünse orta-alt segment bir cihazla test etmek "en yavaş kullanıcı" gerçeğini ortaya çıkarır.
• Form ve klavye davranışı: Mobilde dönüşüm masaüstünden düşük olabilir ve bunun en büyük sebebi formlardır. Doğru klavye tipinin açılması (telefon alanında numerik klavye, e-posta alanında @ içeren klavye), otomatik doldurmanın (autofill) çalışması, tek elle erişim, klavye açıldığında gönder butonunun ekranın dışında kalmaması — bunların hepsi yalnızca gerçek cihazda doğrulanır.
• Kaydırma ve yatay taşma: En sinir bozucu mobil hatalardan biri, sayfanın sağa sola kayması (yatay scroll). Genelde sabit genişlikli bir öğe veya taşan bir görselden kaynaklanır; gerçek cihazda parmakla kaydırırken anında fark edilir, emülatörde kolayca gözden kaçar. Aynı şekilde, momentum/atalet kaydırma hissi ve "scroll-snap" davranışları da yalnızca fiziksel dokunmada doğru değerlendirilir.
• Bağlam koşulları: Güneş altında ekran okunabilirliği (düşük kontrastlı metnin tamamen kaybolması), tek elle ve yürürken kullanım, gelen bir bildirimin akışı bölmesi gibi gerçek dünya koşullarını hiçbir simülasyon üretemez. Mobil kullanıcı, masaüstü kullanıcısının aksine genellikle bölünmüş dikkatle ve elverişsiz ortamda gezinir.

Her telefon modelini satın almanız gerekmez. Pratik bir strateji: elinizde en az bir iOS (iPhone) ve bir Android cihaz bulundurmak, mümkünse biri orta-alt segment olsun ki "en yavaş kullanıcı" deneyimini görün. Bunun yanında tarayıcının cihaz emülasyonunu ağ kısma (network throttling) ile birlikte kullanarak yavaş 4G ve düşük CPU senaryolarını simüle edebilir, gerçek cihaz envanterinizin boşluklarını bulut tabanlı cihaz çiftliği servisleriyle kapatabilirsiniz. Hangi cihazlara öncelik vereceğinizi keyfî seçmeyin: Google Analytics'teki gerçek ziyaretçi cihaz/işletim sistemi dağılımınıza bakın ve trafiğinizin en yoğun olduğu cihaz-sürüm kombinasyonlarını test matrisinizin başına koyun. Yine de altın kural değişmez: yayın öncesi en azından bir gerçek iPhone ve bir gerçek Android'de elle gezinmeden hiçbir mobil tasarımı "tamam" saymıyoruz.

Mobil tasarımda en sık yapılan hatalar nelerdir?

Yıllar içinde devraldığımız ve yenilediğimiz sitelerde aynı hataların tekrar tekrar karşımıza çıktığını söyleyebiliriz. Bu hataların ortak özelliği, masaüstünde fark edilmemeleri ve ancak gerçek mobil kullanımda ortaya çıkmalarıdır. Aşağıda en yaygın olanları, belirtisini ve somut çözümünü bir arada veriyoruz; ardından maddeler hâlinde her birini açıyoruz.

• Yalnızca masaüstünde test etmek: En temel ve en pahalı hata. Tasarımcı 27 inç monitörde harika görünen siteyi onaylar, ama trafiğin yarısından fazlası mobilden gelir. Çözüm: tasarımı önce küçük ekran için kurgulayın (mobil-öncelik, progressive enhancement), masaüstünden küçülterek değil. Tersi yaklaşım neredeyse her zaman kötü bir mobil deneyim üretir; çünkü masaüstü için kurgulanmış çok sütunlu, yoğun bir düzeni küçük ekrana sıkıştırmak ister istemez ezilmiş, taşan bir sonuç doğurur.
• Çok küçük dokunmatik hedefler: 24x24px altı butonlar, birbirine yapışık linkler, küçük "x" kapatma ikonları. Parmak ucu fare imlecinden çok daha kalındır; ortalama bir parmak ucu yaklaşık 1 cm genişliğindedir ve bir pikselin değil bir alanın üstüne basar. En az 44-48px hedef ve hedefler arasında yeterli boşluk bırakın; bu hem kullanılabilirlik hem WCAG 2.2 uyumu meselesidir. Özellikle satır içi metin linkleri, navigasyon menüsündeki yakın öğeler ve form içindeki radyo/onay kutuları en sık ıskalanan hedeflerdir.
• 16px altı gövde metni ve düşük kontrast: Mobilde küçük yazı okunamaz, kullanıcı yakınlaştırmak zorunda kalır; üstelik iOS Safari, 16px altı yazı tipli bir input'a odaklanınca sayfayı otomatik yakınlaştırır ve bu deneyimi bozar. Gövde metni için yaklaşık 16px taban, satır aralığı 1.4-1.6, satır uzunluğu ~50-75 karakter önerilir. Kontrast tarafında WCAG AA gövde metni için en az 4.5:1, büyük metin için 3:1 oranı şarttır; açık gri üstüne açık gri metin estetik görünse de mobilde güneş altında tamamen kaybolur. Renk tek başına bilgi taşımamalı; örneğin sadece kırmızı renkle "hata" demek renk körü kullanıcıyı dışlar.
• Görsele yer ayırmamak (CLS): Cumulative Layout Shift'in en yaygın kök nedeni budur. Görsel geç yüklenince içerik aşağı zıplar, kullanıcı yanlış yere dokunur. Her img/video/iframe/reklam alanına açık width ve height (veya aspect-ratio) verin; banner ve reklam gibi dinamik içeriğe yer rezerve edin. Font kaynaklı kaymayı da göz ardı etmeyin: @font-face üzerinde size-adjust descriptor'ı CLS'yi örneğin 0,15'ten 0,02'ye düşürebilir, gövde metni için font-display: swap metni hemen görünür kılar. Mobilde bu özellikle önemlidir; çünkü yavaş şebekede görseller ve fontlar masaüstünden çok daha geç gelir, dolayısıyla kayma da daha şiddetli olur.
• Ağır JavaScript ile INP'yi öldürmek: Mobil CPU yavaştır; ağır script ana iş parçacığını (main thread) bloke eder ve butona dokununca sayfa donar. INP tüm etkileşimleri ölçtüğü için bu donma doğrudan kırmızı bir Core Web Vital olarak raporlanır. Kod bölme (code splitting), uzun görevleri parçalama, etkileşimi geciktiren işleri tarayıcı boştayken yapma ve özellikle gereksiz üçüncü taraf script'lerini (canlı sohbet widget'ı, ısı haritası, fazla analitik/reklam etiketi) kaldırma mobil INP için belirleyicidir. Müşterilerimizde en hızlı INP kazanımını çoğu zaman gereksiz üçüncü taraf etiketlerini temizleyerek elde ediyoruz.
• Yatay kaydırma / taşan içerik: Sabit genişlikli tablolar, geniş görseller, ekran dışına taşan mutlak konumlu öğeler veya yanlış negatif margin'ler sayfayı yanlara kaydırır. Modern CSS'te container queries ve fluid (clamp) tipografi ile içeriğin bozulduğu noktada kırılım koyarak bunu önleyin; geniş tabloları kaydırılabilir bir kapsayıcı içine alın, görselleri max-width:100% ile sınırlayın. Yatay taşma yalnızca çirkin değil, aynı zamanda dokunmatik kaydırmayı belirsizleştirip kullanıcıyı kaybettiren bir hatadır.
• Mobilde gizlenen kritik içerik: Bazı temalar mobilde önemli bölümleri "display:none" ile gizler. Google mobil sürümü indekslediğinden (Mobile-First Indexing), mobilde olmayan içerik SEO'da yok sayılır. Mobilde içeriği kısaltın, akordeon/sekme ile katlayın ama silmeyin; "akordeon içinde gizli ama DOM'da mevcut" içerik indekslenir, "display:none ile tamamen kaldırılmış" içerik riskli hâle gelir. Aynı içeriğin masaüstü ve mobilde tutarlı olması mobil indekslemenin temel beklentisidir.
• Form ve klavye ihmali: Yanlış klavye tipi, otomatik doldurmanın (autofill) çalışmaması, klavye açılınca "Gönder" butonunun ekranın dışında kalması, doğrulama hatalarının görünmez olması. Mobil form akışını ayrıca optimize etmek, dönüşüm odaklı tasarımın en kârlı adımlarından biridir; alan sayısını azaltın, uygun input türlerini (tel, email, number) kullanın ve hata mesajlarını net ve çözüm önerili verin. Bu konuyu dönüşüm odaklı landing page rehberinde detaylandırıyoruz.
• Dokunmaya bağımlı (hover) etkileşim: Masaüstünde fareyle üzerine gelince açılan menüler veya görünen bilgiler, dokunmatik ekranda hover olmadığı için ya hiç açılmaz ya da iki dokunuş gerektirir. Önemli hiçbir bilgiyi veya gezinmeyi yalnızca hover'a bağlamayın; dokunma ile de erişilebilir olmalı.

Bu hataların çoğu erişilebilirlikle iç içedir: yeterli kontrast, doğru hedef boyutu ve etiketli formlar hem WCAG 2.2 AA uyumu hem daha iyi mobil deneyim demektir. WebAIM'in yıllık taramasında en sık tespit edilen erişilebilirlik hatalarının başında zaten düşük metin kontrastı, alt-metni olmayan görseller, boş bağlantılar, etiketsiz form alanları ve boş butonlar geliyor; bunların hepsi mobilde de doğrudan kullanılabilirlik sorununa dönüşür. Avrupa Erişilebilirlik Yasası'nın (EAA) 28 Haziran 2025'te yürürlüğe girdiğini, EN 301 549 / WCAG 2.1 AA uyumunu zorunlu kıldığını ve AB'ye ürün/hizmet satan firmaları (e-ticaret, bankacılık, e-kitap, ulaşım gibi) kapsayabildiğini düşünürsek, mobil erişilebilirlik artık yalnızca iyi niyet değil, çoğu zaman yasal bir gerekliliktir; ihlal cezaları ülkeye göre yıllık cironun %4'üne kadar çıkabilir. Konunun bütününü web erişilebilirliği nedir ve nasıl sağlanır yazımızda ele alıyoruz.

Yayın öncesi mobil test kontrol listesi

İşte her projede yayına çıkmadan önce uyguladığımız kısa mobil kontrol listesi; bunu kendi sitenize de uygulayabilirsiniz:

1. Gerçek bir iPhone (iOS Safari) ve gerçek bir Android cihazda ana sayfaları elle gezin; mümkünse cihazlardan biri orta-alt segment olsun.
2. Tüm butonların ve linklerin parmakla rahatça basılabildiğini (en az 44-48px, aralarında yeterli boşluk) doğrulayın.
3. PageSpeed Insights'ın mobil sekmesinde LCP, INP, CLS değerlerini ölçün; eşikleri (2,5 sn / 200 ms / 0,1) geçtiğinizi kontrol edin ve hem laboratuvar hem (varsa) saha verisine bakın.
4. Yatay kaydırma (sağa-sola kayma) olmadığını her sayfada test edin.
5. Formları gerçek cihazda doldurun: doğru klavye açılıyor mu, otomatik doldurma çalışıyor mu, klavye açılınca buton görünür mü, hata mesajları okunur mu?
6. Bir erişilebilirlik denetçisi (axe/WAVE/Lighthouse) çalıştırıp kontrast, alt-metin, form etiketi, odak halkası ve dokunmatik hedef uyarılarını giderin.
7. Yavaş 4G ağ kısmayla ve düşük CPU simülasyonuyla sayfanın kabul edilebilir sürede açıldığını doğrulayın.
8. Hover'a bağımlı menü/bilgi olmadığını, dokunmayla her şeye erişilebildiğini kontrol edin.
9. Google'ın canlı URL / mobil uyumluluk testiyle sayfanın mobil indekslemede sorunsuz render edildiğini teyit edin.
10. Yayından sonra Search Console'da mobil CWV raporunu ve indeksleme durumunu birkaç hafta takip edin; ilk haftalardaki dalgalanma normaldir.

Mobil test bir defalık iş değil, süreklilik isteyen bir bakım disiplinidir; yeni içerik, yeni eklenti veya tasarım güncellemesi her seferinde mobil deneyimi yeniden bozabilir. Bir eklenti güncellemesinin kendi script'iyle INP'yi düşürmesi ya da yeni eklenen bir hero görselinin yer ayrılmadığı için CLS'yi bozması müşterilerimizde sık gördüğümüz senaryolardır; bu yüzden düzenli aralıklarla mobil denetimi tekrarlamayı öneriyoruz. Sitenizin mobil hızını ve altyapısını hızlıca görmek isterseniz e-ticaret altyapı tespit aracımızı kullanabilir, daha kapsamlı bir teşhis için ücretsiz site analizimizi talep edebilirsiniz. Mobil-öncelikli, hızlı ve erişilebilir bir tasarımı sıfırdan kurmak ya da mevcut sitenizi bu standartlara yükseltmek için web ve mobil UI/UX tasarımı hizmetimizle yanınızdayız. Tasarımı tamamen yeniden ele almayı düşünüyorsanız, SEO'yu kaybetmeden ilerlemenin yolunu web sitesi yenileme (redesign) rehberinde bulabilirsiniz.