Mobil‑Uyumlu ve Yıldırım Hızında Bir Web Sitesi Nasıl Kurulur

Neden Mobil + Hız Önemli (ve Ne Hedeflemeli)

Ziyaretçilerin çoğu sitenizi telefonda deneyimliyor—çoğunlukla zayıf bir bağlantıda veya çoklu görev yaparken. Sayfa yavaş veya titrek hissediyorsa, kullanıcılar "beklemez"—ayrılır. Bu yüzden mobil uyumlu bir site ve web sitesi hız optimizasyonu sadece teknik bir lüks değil: hemen terk etme oranını, güveni ve dönüşümleri (kayıtlar, satın almalar, aramalar, rezervasyonlar) doğrudan etkiler.

Hız + kullanılabilirlik = daha az terk

Mobilden her ekstra saniye sürtünme yaratır: düğmeler zor dokunulur, metin taraması zorlaşır ve sayfa yüklenirken “bozuk” görünebilir. Hızlı ve stabil bir sayfa, insanların hareket etmesini sağlar—kaydırma, okuma ve işlem tamamlama; terk etme yerine.

Core Web Vitals: Google’ın kullanıcı deneyimi ölçüleri

Google’ın Core Web Vitals performans sinyalleri, kullanıcıların hissettikleriyle yakından eşleşir:

• LCP (Largest Contentful Paint): ana içeriğin ne kadar hızlı göründüğü.
• INP (Interaction to Next Paint): birine dokunulduğunda, yazıldığında veya menü açıldığında sayfanın ne kadar duyarlı hissettirdiği.
• CLS (Cumulative Layout Shift): yüklenme sırasında düzenin ne kadar kaydığı.

Bu metrikler muhteşem içeriklerin yerini tutmaz, ama içeriğinizin telefonda gerçekten kullanılabilir olmasını sağlamaya yardımcı olur.

"Yeterince hızlı" ne demek (pratik hedefler)

Kararlar daha kolay olsun diye net hedefler koyun:

• LCP: tipik mobil bağlantılarda ≤ 2.5s hedefleyin.
• INP: hedef ≤ 200ms.
• CLS: hedef ≤ 0.1.

Ayrıca sayfanın pürüzsüz hissetmesini hedefleyin: görünür içerik hızlı gelsin, etkileşimler anında cevap versin ve kullanıcı parmağının altındaki hiçbir şey kaymasın.

Sitelerin mobilde yavaş hissetmesinin yaygın nedenleri

Genellikle tek bir büyük sorun değil—birkaç küçük sorun bir araya gelir:

• Çok büyük görseller ve tembel yükleme eksikliği
• Çok fazla JavaScript (ağır slider’lar, açılır pencereler, takipçiler)
• Metin render’ını geciktiren özel fontlar
• Boyut belirtilmemiş görseller, reklamlar veya gömüler yüzünden düzen kaymaları
• Yavaş barındırma, zayıf önbellekleme veya çok fazla üçüncü taraf script

Mevcut Sitenizi Gerçek Cihazlarda Denetleyin

Herhangi bir yeniden tasarım yapmadan önce, sitenizin gerçek ziyaretçiler için nasıl davrandığına dair net bir fotoğraf çekin. Hızlı bir bağlantıda masaüstü Chrome penceresi, mobil kullanıcıların hissettiği gerçek problemleri gizleyebilir: yavaş yükleme, titrek düzenler ve gecikmeli dokunmalar.

Gerçek telefonlarda test edin (sadece masaüstü önizlemesi değil)

Ana sayfa, popüler bir blog yazısı, fiyat/ürün sayfası, checkout/iletişim gibi önemli sayfalarınızı mümkünse en az bir iPhone ve bir Android cihazda açın. "Sorun aramadan" fark ettiklerinize dikkat edin:

• Sayfa kullanılabilir olmadan önce yavaş mı hissediliyor?
• Düğmeler anında yanıt veriyor mu yoksa dokunuşlar gecikiyor mu?
• İçerik yüklenirken düzen kayıyor mu?
• Metin çok küçük, sıkışık veya okunması zor mu?

Ayrıca farklı tarayıcılarda (Safari + Chrome) test edin. Özellikle Mobile Safari, yazı tipleri, yapışkan başlıklar ve viewport ile ilgili sorunları ortaya çıkarabilir.

Lighthouse denetimi ve PageSpeed Insights çalıştırın

Sonra Chrome DevTools’ta (Mobil modu) Lighthouse denetimi çalıştırın ve PageSpeed Insights’u kontrol edin. Sadece puana odaklanmayın—raporu büyük yük noktalarını bulmak için kullanın, örn:

• Büyük görseller ve optimize edilmemiş medya
• Çok fazla JavaScript (yavaş etkileşim)
• Render’ı engelleyen CSS
• Yüklemeyi geciktiren üçüncü taraf script’ler (sohbet widget’ları, takipçiler)

Önemli sayfalar boyunca tekrar eden ilk 5 fırsatı yazın. Tekrarlayan maddeler genelde web sitesi hız optimizasyonu için en iyi ilk düzeltmelerdir.

Core Web Vitals’ı kontrol edin: LCP, INP, CLS

Core Web Vitals, “hız”ı kullanıcı deneyimine çevirir:

• LCP: ana içeriğin ne kadar hızlı göründüğü. Yüksek LCP genelde ağır görseller, yavaş sunucu yanıtı veya render’ı engelleyen kaynaklara işaret eder.
• INP: kullanıcı dokunma/yazma/tıklama yaptığında sayfanın ne kadar duyarlı hissettirdiği. Kötü INP genelde çok fazla JavaScript veya main thread’de uzun görevler olduğunu gösterir.
• CLS: yüklenme sırasında sayfanın ne kadar stabil olduğu. Yüksek CLS genelde boyutsuz görseller, geç yüklenen gömüler veya font değişimleri yüzündendir.

Bu metrikleri en önemli sayfalarınız için izleyin. Bu, sizin “önce” anlık görüntünüz olur.

Yavaş ağlar ve düşük özellikli cihazlarda ölçün

Birçok kullanıcı mükemmel Wi‑Fi’da değil. Chrome DevTools’ta daha yavaş bağlantıları (3G/4G) simüle edin ve önce neyin bozulduğuna bakın. Mümkünse daha eski veya düşük özellikli bir Android cihazda da test edin—CPU sınırlamaları, modern telefonların gizleyebildiği INP sorunlarını ortaya çıkarabilir.

Basit bir temel raporu oluşturun

Ağırlaştırmayın: sayfa başına mevcut LCP/INP/CLS, toplam sayfa ağırlığı ve birkaç not içeren tek sayfalık bir doküman veya spreadsheet yeterlidir (ör. “hero görsel 1.8MB”, “sohbet widget’ı yüklemeyi engelliyor”). Bu temel raporu, her değişikliğin gerçek performansı iyileştirip iyileştirmediğini kanıtlamak için kullanacaksınız.

Mobil‑Öncelikli Düzen ve UX Temelleri

Hızlı bir site bile mobilde okunamıyor, dokunulamıyor veya isteneni bulamıyorsa “yavaş” hissedilebilir. Mobil‑öncelikli UX, ilk önce en küçük ekran ve dokunma girdisi için tasarlamak, sonra daha büyük ekranlar için geliştirmek demektir.

Gerçekten duyarlı bir düzenle başlayın

Düzenin her ekran boyutuna temizce uyum sağlaması için duyarlı bir grid ve akışkan elemanlar kullanın. Sabit genişlikli container’lardan ve taşan bileşenlerden kaçının. Ortak kırılma noktalarını (360–430px telefonlar, küçük tabletler) test edin ve ana bölümlerin sıkıştırma gerektirmediğinden emin olun.

Okumayı ve dokunmayı kolaylaştırın

Okunabilirliği önceliklendirin: rahat font boyutları, güçlü kontrast ve geniş satır aralığı. Dokunma için, dokunma hedeflerinin (düğmeler, linkler, form girişleri) yeterince büyük ve aralıklı olması gerekir; özellikle menüler, filtreler ve checkout/iletişim formlarında.

Düzen kaymalarını önleyin (ve kullanıcı hayal kırıklığını)

Beklenmedik hareketler güven kaybettirir.

Aşağıya yer ayırın:

• Görseller (width/height veya aspect ratio belirtin)
• Reklamlar, gömüler ve video oynatıcılar
• Yapışkan UI elemanları (başlıklar, çerez banner’ları)

Bu, sayfanın yüklenirken stabil kalmasını sağlar ve Core Web Vitals, özellikle CLS üzerinde olumlu etki yapar.

Gezinmeyi basit ve başparmak dostu tutun

Mobil navigasyon tahmin edilebilir olmalı:

• Ana eylemler için yapışkan bir başlık (menü, sepet, iletişim)
• Kısa ve net bir menü yapısı (derin iç içe yapıdan kaçının)
• Gerçekten faydalıysa arama alanı (mağazalar, çok içerikli siteler için)

Kilit sayfaları mobil‑öncelikli tasarlayın

Sadece ana sayfayı duyarlı yapmak yetmez—mobil kullanıcılara sonuç getiren sayfaları tasarlayın:

• Ana sayfa: net değer önerisi + katılım çağrısı üstte
• Ürün/hizmet sayfası: taranabilir bölümler, öne çıkan fiyat/sonraki adım
• Checkout/iletişim: minimum alan, uygun input türleri, net hata mesajları

Sayfa yapısı için kontrol listesine ihtiyacınız varsa, bakın: /blog/mobile-first-checklist.

Bir Performans Bütçesi ve Öncelikler Belirleyin

Performans çalışmaları, performansı bir bütçe olarak ele aldığınızda daha kolay ilerler. Bir performans bütçesi, sayfalarınızın “harcama” yapmasına izin verilen sınırları (bayt, istek sayısı, süre) belirler, böylece yeni özellikler sitenin yavaşlamasına neden olmaz.

Performans bütçenizi tanımlayın

Kolay ölçülebilir ve tartışması zor birkaç hedef seçin:

• Sayfa ağırlığı: başlangıç görünümü için toplam bayt (HTML + CSS + JS + görseller + fontlar)
• İstek sayısı: ilk yükte yapılan ağ çağrıları
• Core Web Vitals: LCP, INP, CLS

Bunları geç/kal sayılar olarak yazın. Örnek hedefler (hedef kitlenize göre ayarlayın): LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 ve ilk görünüm için bir maksimum transfer boyutu.

İlk önce 1–2 kullanıcı yolculuğu seçin

Her şeyi aynı anda hızlandırmak genelde hiçbir şeyin yayınlanmamasına yol açar. İş için en kritik akışları seçin, örn:

• Açılış sayfası → ürün sayfası → ödeme
• Açılış sayfası → kayıt

Bu akışları mobilde ölçün ve önce onları optimize edin.

Hemen yüklenmesi gereken ile bekleyebilecekleri ayırın

Her ana sayfa için varlıkları sınıflandırın:

• Hemen yüklenmeli: üst alan içeriği, kritik CSS, ana hero görsel, temel UI script’leri
• Bekleyebilir: ekranın altında kalan görseller, kritik olmayan widget’lar, analiz ekstra’ları, ikincil carousel’ler

Bu zihniyet, tembel yükleme, kritik olmayan JavaScript’i erteleme ve üçüncü taraf araçları yalnızca kullanıcı etkileşiminden sonra yükleme gibi taktiklere doğal olarak götürür.

Hedefleri ortak bir yerde belgeleyin

Bütçenizi ve Core Web Vitals hedeflerinizi paylaşılan bir dokümana veya proje panosuna ekleyin ve geliştirme sürecinde linkleyin. Yeni bileşenler bir maliyetse—bütçeyi aşarsa bir şeyler kırpılmalı.

Görselleri Kaliteden Ödün Vermeden Optimize Edin

Görseller genelde bir sayfanın en büyük dosyalarıdır ve mobil bağlantılarda saniyeler kazanmanın en kolay yeri olabilir. Amaç her şeyin "mini" olması değil. Doğru görseli, doğru formatta, doğru anda sunmak ve beklenmedik kaymaları önlemektir.

Doğru boyutlarda görseller sunun (responsive srcset kullanın)

Yaygın hata: 2000px genişliğinde masaüstü görselini 375px genişliğindeki telefona göndermek. Bunun yerine birkaç mantıklı boyut dışa aktarın ve tarayıcının en uygunu seçmesine izin verin.

\u003cimg
  src=\"/images/hero-800.jpg\"
  srcset=\"/images/hero-400.jpg 400w,
          /images/hero-800.jpg 800w,
          /images/hero-1200.jpg 1200w\"
  sizes=\"(max-width: 600px) 92vw, 1200px\"
  alt=\"Your product in use\"
  width=\"1200\"
  height=\"675\"
/\u003e

Bu, mobil indirmelerini küçük tutarken daha büyük ekranlarda keskin görseller sağlar.

Mümkünse modern formatlar (WebP/AVIF) kullanın

Modern formatlar dosya boyutunu görünür bir fark olmadan ciddi şekilde azaltabilir.

• AVIF: en iyi sıkıştırma, bazen kodlama daha yavaş
• WebP: geniş destek ve güçlü bir varsayılan seçenek

Uyumlu tarayıcıların modern versiyonu alması, diğerlerinin sorunsuzca yedeğe geçmesi için bir \u003cpicture\u003e elementi kullanın:

\u003cpicture\u003e
  \u003csource type=\"image/avif\" srcset=\"/images/hero-800.avif 800w\" /\u003e
  \u003csource type=\"image/webp\" srcset=\"/images/hero-800.webp 800w\" /\u003e
  \u003cimg src=\"/images/hero-800.jpg\" alt=\"Your product in use\" width=\"1200\" height=\"675\" /\u003e
\u003c/picture\u003e

Görselleri sıkıştırın ve gereksiz meta verileri kaldırın

Sıkıştırma iş akışınızın (veya build pipeline’ın) bir parçası olmalı. "Normal izleme mesafesinde aynı görünen" ayarları hedefleyin, piksel takıntısı yapmayın.

Ayrıca kamera bilgisi gibi meta verileri yalnızca gerçekten ihtiyaç varsa tutun—bu dosya boyutunu düşürür ve gizlilik açısından iyidir.

Ekranın altında kalan görselleri tembel yükleyin (UX’i bozmadan)

Tembel yükleme, kullanıcıların hemen görmediği görseller için idealdir. Üst alan görsellerinin normal yüklenmesi, sayfanın boş görünmemesini sağlar.

\u003cimg src=\"/images/gallery-1.webp\" loading=\"lazy\" alt=\"Gallery item\" width=\"800\" height=\"600\" /\u003e

Tembel yüklenen bir görsel algılanan hız için önemliyse (ör. bir bölümdeki ilk görünür görsel), tembel yüklemeye almak yerine önceden yüklemeyi düşünün.

Düzen kaymalarını önlemek için width ve height ayarlayın

Beklenmedik düzen hareketleri mobilde sinir bozucudur ve Core Web Vitals’a zarar verebilir. Tarayıcının görsel gelmeden önce doğru alanı ayırabilmesi için her zaman boyutlar ekleyin (veya CSS ile yer ayırın).

Duyarlı boyutlandırma, modern formatlar, sıkıştırma ve dikkatli tembel yüklemeyi birleştirdiğinizde genelde hem hızlı hem de net görseller elde edersiniz.

CSS ve JavaScript’i Hafif Hale Getirin

CSS ve JavaScript, bir mobil uyumlu web sitesinin yavaş hissetmesinin sık gizli nedenlerindendir. Amaç basit: daha az kod gönderin ve daha akıllıca gönderin.

Gönderdiğiniz şeyleri küçültün ve sıkıştırın

Temelden başlayın: CSS/JS’i minify edin (gereksiz boşluk ve karakterleri kaldırın) ve sunucuda sıkıştırmayı etkinleştirin. Modern altyapılar dosyaları Brotli (en iyi) veya gzip (iyi) ile sunabilir; bu, özellikle mobil ağlarda transfer boyutunu dramatik şekilde düşürür.

Kullanılmayanları kaldırın

Birçok site "olursa diye" stiller ve script’ler yükler. Bu maliyet her sayfa görüntülemede görünür.

• Kullanılmayan CSS: Bir framework (Bootstrap veya Tailwind) kullanıyorsanız, build’in sadece kullandığınız sınıfları dışa aktardığından emin olun.
• Kullanılmayan JavaScript: Küçük bir özellik için bir kütüphanenin tamamını içe aktarıyorsanız, her yerde bunun bedelini ödersiniz. Küçük yardımcılar veya tarayıcı yerel özelliklerini tercih edin.

Ağır kütüphanelerden kaçının

Slider, animasyon kütüphanesi veya UI kiti eklemeden önce sorun: "Bunu temel CSS veya küçük bir script ile yapabilir miyiz?" Büyük bir bağımlılığı değiştirmek, website speed optimization’da en hızlı kazanımlardan biri olabilir.

Önemli kodu önce yükleyin

İlk ekranın çabuk etkileşimli olması için:

• Kritik olmayan script’leri erteleyin (defer kullanın)
• Kod ayırma yapın, böylece her sayfa sadece ihtiyaç duyduğu şeyi yükler
• Haritalar, carousel’ler, widget’lar gibi özellikleri tembel yükleyin

Üçüncü taraf etiketlerini azaltın

Sohbet widget’ları, takipçiler ve reklam script’leri Core Web Vitals’ı yavaşlatabilir ve performansı öngörülemez kılabilir. Gerçekten ihtiyaç duymuyorsanız kaldırın, kalanları sonra yükleyin (kullanıcı etkileşiminden sonra veya sayfa kullanılabilir olduktan sonra).

Daha net bir kontrol listesi isterseniz, bu çalışmayı /blog/lighthouse-audit çalışmasıyla eşleştirin ve hangi dosyaların gerçekten yüklemeyi zorlaştırdığını görün.

Fontlar, Medya ve UI Öğeleri (Sizi Yavaşlatmayacak Şekilde)

Düzen temiz ve görseller optimize olsa bile, fontlar ve “olsa iyi olur” UI efektleri mobil yükleme süresine gizlice saniyeler ekleyebilir. Amaç okunabilir içeriği hemen göstermek, sonra sayfayı engellemeden geliştirmektir.

Fontlar: hızlı, okunabilir ve marka‑uyumlu

Daha az font dosyası yükleyerek başlayın. Her ağırlık (300/400/700) ve stil (italik) genelde ayrı bir indirme demektir—tasarımınızın gerçekten ihtiyaç duyduğu minimumu seçin.

Marka kuralları izin veriyorsa, sistem fontları en hızlı seçenektir çünkü cihazda zaten mevcutturlar. Modern bir sistem kombinasyonu yine de şık görünebilir.

Üst alan metnini etkileyen fontları yalnızca preload ile önden getirin ki tarayıcı bunları geç keşfetmesin.

\u003clink rel=\"preload\" href=\"/fonts/Inter-400.woff2\" as=\"font\" type=\"font/woff2\" crossorigin\u003e

Görünmez metni önlemek için font-display: swap kullanın, böylece özel font yüklenirken ziyaretçiler hemen okuyabilir.

@font-face {
  font-family: \"Inter\";
  src: url(\"/fonts/Inter-400.woff2\") format(\"woff2\");
  font-display: swap;
}

Medya: varsayılan olarak ağır tasarımlardan kaçının

Büyük hero slider’lar, otomatik oynayan videolar ve karmaşık animasyonlar mobil bant genişliğini ve CPU’yu domine edebilir. Tek bir statik hero görseli tercih edin (veya dokununca oynayan hafif bir video). Hareket gerekiyorsa, büyük animasyon kütüphaneleri yerine ince CSS geçişlerini tercih edin.

UI öğeleri: bileşenleri basit ve erişilebilir tutun

Hızlı render olan UI bileşenleri seçin: native input’lar, basit navigasyon ve hafif modal’lar. Bu aynı zamanda erişilebilirliği de artırır (net focus durumları, daha büyük dokunma hedefleri, daha az hareket).

Üçüncü taraf widget’lar kullanıyorsanız (sohbet, gömüler, sosyal akışlar), yalnızca gerektiğinde yükleyin (izin sonrası veya etkileşimde).

Önbellekleme, CDN ve Barındırma Temelleri

Hız yalnızca tarayıcıda yaptıklarınızla ilgili değildir—aynı zamanda sunucunuzun dosyaları ne kadar hızlı teslim ettiğine de bağlıdır. Birkaç pratik altyapı seçimi, tasarımınızı değiştirmeden bekleme süresini saniyelerce azaltabilir.

Statik varlıklar için tarayıcı önbelleklemesini etkinleştirin

Ziyaretçiler aynı logo, CSS veya JavaScript’i her sayfada yeniden indirmemelidir. Cache-Control başlıklarıyla statik varlıkların yerel olarak saklanmasını sağlayın.

Tipik yaklaşım:

• Dosyalarınızı versiyonlayın (örn. app.v3.css) ve uzun bir cache süresi ayarlayın (30 gün ile 1 yıl arası)
• HTML için daha kısa önbellekleme, çünkü içerik daha sık değişir

Tekrar ziyaretleri anında daha hızlı hissettirmek için bu en basit yollardan biridir.

Dosyaları kullanıcılara yakın sunmak için CDN kullanın

CDN (Content Delivery Network) statik dosyalarınızı dünya çapında sunuculara kopyalar; böylece mobil kullanıcılar dosyaları yakın bir sunucudan indirir. Bu, mobil kullanıcılar için özellikle faydalıdır:

• Görseller ve videolar
• CSS/JS paketleri
• Fontlar (zorunluysa)

Birçok CDN ayrıca otomatik sıkıştırma ve modern protokoller sunar, bu da Core Web Vitals’a yardımcı olabilir.

HTTP/2 veya HTTP/3’ü etkinleştirin

Barındırma destekliyorsa HTTP/2 (veya HTTP/3) kullanın; bu, dosyaların tek bir bağlantı üzerinden daha hızlı teslim edilmesini sağlar. Mobilde gecikme genelde darboğaz olduğu için önemlidir.

HTTPS ile genelde HTTP/2 otomatik gelir. HTTP/3 desteği sağlayıcınıza ve CDN’e bağlıdır.

Sunucu yanıt süresini düşük tutun

Hızlı ön uç bile hala yavaş hissedebilir eğer sunucu yanıtı yavaşsa. Hedefleyin:

• Aşırı yüklenmemiş barındırma
• Veritabanı sorgularında verimlilik ve minimum eklenti
• Sayfaların her istekte yeniden oluşturulmadığı sunucu tarafı önbellekleme

Lighthouse raporlarında Time to First Byte (TTFB) sorunlarına dikkat edin—yavaş TTFB genelde barındırma veya backend darboğazlarına işaret eder.

Tam sayfa veya parça önbellekleme kullanın (anlamlıysa)

Sayfalar kullanıcıya göre değişmiyorsa, tam sayfa önbellekleme büyük kazanç sağlar. Sadece bazı parçalar dinamikse (örn. sepet sayısı), parça önbellekleme kullanarak sayfanın çoğunu yine de hızlı sunabilirsiniz.

Kural: mümkün olduğunca önbellekle, sonra gerçekten dinamik içerik için dikkatli "deliği" açın.

Ağ ve Sunucu Optimizasyonları

Hızlı bir mobil deneyim, yalnızca HTML/CSS/JS göndermekle ilgili değil—aynı zamanda ilk byte’ın ne kadar hızlı geldiği ve isteklerin ağ üzerinden ne kadar verimli taşındığı ile ilgilidir.

Yönlendirmeleri ve tur sayısını azaltın

Yönlendirme zincirleri mobilde özellikle acıdır; her adım DNS, TLS ve istek/yanıt süresi ekler.

• “http → https → www → /home” tarzı zincirleri kaldırın. En fazla tek bir yönlendirme hedefleyin.
• Dahili linkleri doğrudan nihai URL’ye güncelleyin (kanonik eğik çizgi kurallarına dikkat).

Kilit sayfaları sunucuda render edin (uygun olduğunda)

Kritik içerik için (ana sayfa, ürün/hizmet sayfaları, popüler blog yazıları) sunucu tarafı render veya statik üretimi tercih edin. Boş bir HTML kabuğu gönderip içeriği JavaScript ile getirmek LCP’yi geciktirebilir.

JS çerçevesi kullanıyorsanız, ana içeriğin başlangıç HTML’sinde var olduğundan ve kademeli olarak hydrate edildiğinden emin olun.

Üçüncü taraf bağlantıları daha ucuz hale getirin

Analitik, sohbet widget’ları, video gömüleri ve A/B araçları genelde ek origin’ler oluşturur. Önemli olanlar için bağlantı ipuçları ekleyin ki tarayıcı daha erken hazırlık yapsın:

\u003clink rel=\"dns-prefetch\" href=\"//example-third-party.com\"\u003e
\u003clink rel=\"preconnect\" href=\"https://example-third-party.com\" crossorigin\u003e

Bunları seyrek kullanın—çok fazla origin’e preconnect yapmak mobil bant genişliğini boşa harcayabilir.

head içinde engelleyen isteklerden kaçının

Kritik CSS’i küçük tutun, kritik olmayan script’leri erteleyin ve büyük üçüncü taraf tag’leri sayfa render edilmeden önce yüklemekten kaçının. Mümkünse script’leri belgenin sonuna taşıyın veya defer kullanın.

Sıkıştırma ve modern protokolleri etkinleştirin

Sunucunuzun sıkıştırılmış varlıklar gönderdiğinden emin olun:

• HTTPS için Brotli (metin varlıkları için en iyi)
• Yedek olarak Gzip

Ayrıca HTTP/2 (veya mümkünse HTTP/3) etkin olduğundan emin olun; bu mobil ağlarda bağlantı yükünü azaltır ve paralel yüklemeyi iyileştirir.

Hız‑Dostu Mobil Dönüşümler

Hızlı sayfalar otomatik olarak dönüşüm sağlamaz—arayüzün küçük ekranda zahmetsiz hissetmesi gerekir. Hile, sayfayı yavaşlatmadan sürtünmeyi kaldırmaktır.

Formları basitleştirin (daha kısa hissettirin)

Mobilde her ekstra alan vazgeçme sebebidir. Sadece sonraki adım için gerçekten gerekli olanı tutun.

Mümkünse akıllı varsayılanlar kullanın (ülke, miktar, kargo yöntemi) ve doğru input türleri (email, tel, name) ve autocomplete öznitelikleri ile autofill’den yararlanın.

Daha fazla veri toplamanız gerekiyorsa, adımlara bölün—ama gezinmeyi anında tutun ve ekstra sayfa yükleri zorlamayın.

Engellemeyen doğrulama

Doğrulama rehber olmalı, engelleyici değil. Yazma sırasında donma veya düzenin kaymasına neden olan "her tuşta doğrula" desenlerinden kaçının.

İnce istemci tarafı kontrollerini blur (alan kaybettiğinde) veya gönderimde çalıştırın ve mesajları alanın yanında gösterin. Hata metninin kısa, spesifik ve sabit boyutta olmasına dikkat edin ki sayfa kaymasın.

Başparmak dostu, belirgin düğmeler

Birincil eylem kolayca görülebilmeli ve kolayca basılabilmeli:

• Düğmeleri başparmaklar için yeterince büyük yapın, bol padding ile
• Açık etiketler kullanın ("Devam et: Kargo" "İleri" yerine)
• Birincil düğmeyi net tutun, hassas kaydırma gerektirmesin

Ayrıca yanlış dokunuşları azaltmak için yıkıcı eylemleri ("Kaldır") "Öde" veya "Gönder" yakınından uzak tutun.

Pop‑up’lar: minimal, mobil‑güvenli ve hızlı

Pop‑up’lar hem kullanıcı güvenini hem de mobil akışı zedeleyebilir. Kullanıyorsanız nadir, küçük ve kolay kapatılabilir olsunlar.

Ağır üçüncü taraf script’leri sadece indirim modal’ı göstermek için yüklemeyin. Satır içi banner veya küçük, engellemez bir slide‑in gibi daha hafif alternatifleri düşünün.

Erişilebilirlik temelleri dönüşümleri de iyileştirir

Erişilebilirlik geliştirmeleri genelde tamamlamayı artırır:

• Metin ve düğmeler için okunabilir kontrast
• Yer tutucu değil, net etiketler
• Harici klavye veya yardımcı teknoloji kullananlar için klavye desteğini unutmayın

Dönüşüm arayüzünüz basit, stabil ve dokunmaya uygun olduğunda daha iyi sonuç alırsınız ve sayfayı gerçek mobil ağlarda hızlı tutabilirsiniz.

Mobil ve Hızlı Sayfalar için SEO Düşünceleri

Google, sitenizi öncelikle bir mobil kullanıcı gibi değerlendirir—yani mobil kullanılabilirlik ve hız görünürlüğü doğrudan etkiler. İyi haber: birçok "SEO iyileştirmesi" aynı zamanda kullanıcı deneyimi iyileştirmesidir.

Core Web Vitals’ı SEO hijyeni olarak görün

Core Web Vitals (LCP, INP, CLS) sadece teknik metrikler değildir—ana içeriğinizin ne kadar hızlı göründüğünü, sayfanın ne kadar duyarlı hissettirdiğini ve düzenin ne kadar stabil olduğunu yansıtır.

• LCP: ana içerik (genellikle hero başlık + görsel) hızlı yüklenmeli.
• INP: ağır JavaScript’i sınırlayarak etkileşimleri hızlı tutun.
• CLS: kullanıcıları sinirlendiren düzen kaymalarından kaçının.

Önemli içeriği ağır script’ler olmadan görünür yapın

SEO için ana sayfa içeriğinin hemen erişilebilir olmasını sağlayın; client-side rendering veya büyük paketlerin arkasında gizlemeyin.

Pratik kontroller:

• Ana başlıklar, ürün/hizmet özeti ve fiyat ipuçları JavaScript gecikse bile görünür olmalı.
• Anlamlı metinleri script gerektiren “Daha fazla yükle” widget’larının arkasına gizlemeyin.
• Kritik sayfalar için sunucu-render veya statik üretim kullanın.

Başlıklar, meta açıklamalar ve yapılandırılmış bloklar

Hızlı sayfaların da net alaka sinyallerine ihtiyacı var:

• Benzersiz başlıklar yazın, mobil SERP’lere uygun olarak öne konu başlığını koyun.
• Meta açıklamalar beklentiyi belirlesin (hızlı sayfalar terkleri azaltır, ama netlik önlemleri gerekir).
• İçeriği taranabilir bloklara ayırın: bir net H1, açıklayıcı H2’ler ve kısa paragraflar.

Dahili bağlantılar: net, tutarlı, taranabilir

Mobil kullanıcılar farklı gezinir; dahili linkleri görünür ve hafif tutun.

Örnek: yüksek trafikli sayfalardan /pricing, /contact ve ana hizmet sayfalarına açıklayıcı bağlantı metniyle bağlayın—"buraya tıkla" yerine açıklayıcı ifadeler kullanın.

Promo barlar ve çerez bildirimleri CLS’ye neden olmasın

Geç yüklenen çerez bildirimleri, promo barlar ve sohbet widget’ları genelde CLS zirvelerine neden olur.

Onlara baştan yer ayırın (veya içeriği itmeyen overlay’ler kullanın) ve sayfa zaten görünür olduktan sonra üstte büyük banner’lar eklemekten kaçının.

Test, İzleme ve Hızlı Tutma

Hız bir kez "biter" diyebileceğiniz bir şey değil—birkaç yeni görsel, bir pazarlama etiketi veya bir widget haftalarca süren optimizasyonu geri alabilir. Amaç performans kontrollerini normal iş akışınızın parçası yapmak.

Her sürümden önce performans kontrolleri ekleyin

Performansı bir özellik gibi ele alın ve geç/giriş kriterleri koyun.

• CI veya yayın öncesinde Lighthouse eşiklerini kullanarak süreklilik kontrolleri ekleyin (örneğin minimum puanlar ve Core Web Vitals ile ilgili geç koşulları)
• Ana şablonlarda (home, ürün/hizmet, blog, checkout/lead form) denetimler çalıştırın, sadece ana sayfada değil

Performans bütçeniz varsa, build aşamasında paketler, görseller veya üçüncü taraf script’ler limitleri aştığında uyarı veya başarısızlık verin.

Üretimde gerçek kullanıcı metriklerini (RUM) izleyin

Laboratuvar testleri işe yarar, ama ziyaretçilerinizin telefonları ve ağları gerçektir.

• RUM ile üretimde metrikleri takip edin; özellikle LCP, INP ve CLS’deki ani artışları yakalayın.
• Cihaz tipi ve bağlantı hızına göre segmentleyin ki "sadece orta seviye Android’de yavaş" sorunlarını görebilesiniz.

Üçüncü taraf script’lere kısa tasma takın

Analitik, sohbet widget’ları, A/B testleri ve reklam pikselleri genelde mobil deneyimin en ağır kısmı olur.

• Üçüncü taraf script etkisini zaman içinde izleyin (yükleme süresi, uzun görevler, toplam bayt)
• Çoğaltmaları kaldırın, kritik olmayan etiketleri geciktirin ve her bir script’in kimin sorumluluğunda olduğunu belgeleyin

İçerik güncellemelerini performans‑dostu yapın

İçerik güncellemeleri için basit bir performans kontrol listesi oluşturun:

• Yeni görseller sıkıştırılmış ve doğru boyutlandırılmış mı?
• Gömüler (video, harita) sadece gerektiğinde mi yükleniyor?
• Yeni fontlar veya slider’lar eklenerek JavaScript artışı oldu mu?

Başından itibaren hızlı inşa edin

Sıfırdan başlıyorsanız, responsive web tasarımı ve iyi varsayılanları teşvik eden bir stack seçmek önemlidir. Örneğin, Koder.ai ekiplerin sohbet aracılığıyla web uygulamaları oluşturmasını sağlarken gerçek kaynak kodu da dışa aktarır—böylece hızlı iterasyon yapıp performans bütçelerini, SSR/statik üretimi ve dikkatli bağımlılık seçimlerini büyürken zorunlu kılabilirsiniz.

Düzenli incelemeler planlayın

Sayfalar ve varlıklar büyüdükçe düzenli incelemeler planlayın. Öne çıkan sayfalar için aylık 30 dakikalık kısa bir kontrol, yavaşlamaların tam bir yeniden yapıyı gerektirmesini önleyebilir.