04 Mar 2025·8 dk
Mobil‑Uyumlu ve Yıldırım Hızında Bir Web Sitesi Nasıl Kurulur
Mobil dostu, hızlı yüklenen bir site nasıl yapılır: duyarlı düzen, görsel optimizasyonu, hafif kod, önbellekleme, test etme ve sürekli izleme.
Mobil dostu, hızlı yüklenen bir site nasıl yapılır: duyarlı düzen, görsel optimizasyonu, hafif kod, önbellekleme, test etme ve sürekli izleme.
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.
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.
Google’ın Core Web Vitals performans sinyalleri, kullanıcıların hissettikleriyle yakından eşleşir:
Bu metrikler muhteşem içeriklerin yerini tutmaz, ama içeriğinizin telefonda gerçekten kullanılabilir olmasını sağlamaya yardımcı olur.
Kararlar daha kolay olsun diye net hedefler koyun:
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.
Genellikle tek bir büyük sorun değil—birkaç küçük sorun bir araya gelir:
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.
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:
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.
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:
Ö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, “hız”ı kullanıcı deneyimine çevirir:
Bu metrikleri en önemli sayfalarınız için izleyin. Bu, sizin “önce” anlık görüntünüz olur.
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.
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.
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.
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.
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.
Beklenmedik hareketler güven kaybettirir.
Aşağıya yer ayırın:
Bu, sayfanın yüklenirken stabil kalmasını sağlar ve Core Web Vitals, özellikle CLS üzerinde olumlu etki yapar.
Mobil navigasyon tahmin edilebilir olmalı:
Sadece ana sayfayı duyarlı yapmak yetmez—mobil kullanıcılara sonuç getiren sayfaları tasarlayın:
Sayfa yapısı için kontrol listesine ihtiyacınız varsa, bakın: /blog/mobile-first-checklist.
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.
Kolay ölçülebilir ve tartışması zor birkaç hedef seçin:
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.
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:
Bu akışları mobilde ölçün ve önce onları optimize edin.
Her ana sayfa için varlıkları sınıflandırın:
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.
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ö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.
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.
Modern formatlar dosya boyutunu görünür bir fark olmadan ciddi şekilde azaltabilir.
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
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.
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.
width ve height ayarlayınBeklenmedik 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, 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.
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.
Birçok site "olursa diye" stiller ve script’ler yükler. Bu maliyet her sayfa görüntülemede görünür.
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.
İlk ekranın çabuk etkileşimli olması için:
defer kullanı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.
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.
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;
}
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.
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).
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.
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:
app.v3.css) ve uzun bir cache süresi ayarlayın (30 gün ile 1 yıl arası)Tekrar ziyaretleri anında daha hızlı hissettirmek için bu en basit yollardan biridir.
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:
Birçok CDN ayrıca otomatik sıkıştırma ve modern protokoller sunar, bu da Core Web Vitals’a yardımcı olabilir.
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.
Hızlı ön uç bile hala yavaş hissedebilir eğer sunucu yanıtı yavaşsa. Hedefleyin:
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.
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.
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önlendirme zincirleri mobilde özellikle acıdır; her adım DNS, TLS ve istek/yanıt süresi ekler.
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.
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ınKritik 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.
Sunucunuzun sıkıştırılmış varlıklar gönderdiğinden emin olun:
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ı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.
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.
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.
Birincil eylem kolayca görülebilmeli ve kolayca basılabilmeli:
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 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 geliştirmeleri genelde tamamlamayı artırır:
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.
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 (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.
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:
Hızlı sayfaların da net alaka sinyallerine ihtiyacı var:
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.
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.
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.
Performansı bir özellik gibi ele alın ve geç/giriş kriterleri koyun.
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.
Laboratuvar testleri işe yarar, ama ziyaretçilerinizin telefonları ve ağları gerçektir.
Analitik, sohbet widget’ları, A/B testleri ve reklam pikselleri genelde mobil deneyimin en ağır kısmı olur.
İçerik güncellemeleri için basit bir performans kontrol listesi oluşturun:
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.
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.
Mobil uyumlu ve hızlı bir site, hemen terk etme oranını düşürür ve dönüşümleri artırır çünkü mobil ziyaretçilerin dikkat süresi sınırlıdır, ekranları küçüktür ve bağlantıları zayıf olabilir. Sayfalar yavaş, tepki vermeyen veya görsel olarak “sallanıyorsa”, kullanıcılar okumadan veya satın almadan ayrılır.
Bunlar kullanıcı deneyimini yansıtan metriklerdir ve insanların hissettikleriyle doğrudan ilişkilidir:
Bunları sadece bir puan peşinde koşmak yerine “yeterince hızlı” hedefleri olarak kullanın.
Masaüstü testleri mobil sorunları gizleyebilir. Şunları yapın:
Sık görülen nedenler şunlardır:
Gerçekten küçük ekran ve dokunma için tasarlamak demektir:
İçerik yüklenmeden önce alan ayırın:
width/height (veya CSS aspect-ratio) verinBu, CLS’yi doğrudan iyileştirir ve düğmelerin kaymasıyla yanlış tıklamaları engeller.
Duyarlı bir yaklaşımla:
srcset ile birden fazla boyut sağlayın ve tarayıcının doğru olanı seçmesine izin verin\u003cpicture\u003e kullanın)Amaç daha az kod göndermek ve bunu akıllıca yapmak:
defer, kod ayırma ve tembel yükleme kullanınPerformans bütçesi, sayfaların zaman içinde ağırlaşmasını engelleyen sert sınırlar koyar. İzlenecek birkaç sayı:
Önce 1–2 kritik kullanıcı akışını optimize edin (ör. landing → ürün → ödeme) ve her yeni bileşeni bir "maliyet" olarak değerlendirin.
Laboratuvar testleriyle gerçek kullanıcı verilerini birleştirin:
Ayrıca boyutları ekleyin ki CLS oluşmasın.