Front-End Nedir? Ön Yüz Kodlamada Dikkat Edilen Noktalar

Front-end, bir web sitesinin tarayıcıda gördüğünüz ve dokunduğunuz her parçasıdır. 2012'den beri kurumsal siteler ve e-ticaret projeleri üzerinde çalışıyorum; bu sürede şunu net gördüm: tasarım ne kadar güzel olursa olsun, front-end kodu özensizse ziyaretçi bunu yavaşlık, kayan butonlar ve okunmayan metinler olarak hisseder.

Bu yazıda kariyer yol haritası çizmiyorum ve sunucu tarafına girmiyorum. Onun yerine ön yüz kodlamanın ne olduğunu, hangi katmanlardan oluştuğunu ve bir projeyi teslim alırken hangi noktalara bakmanız gerektiğini anlatıyorum.

Front-end nedir, ne işe yarar?

Front-end, bir web sitesinin veya uygulamanın kullanıcının tarayıcısında çalışan ön yüz katmanıdır. HTML ile içerik iskeletini, CSS ile görünümü, JavaScript ile etkileşimi kurar. Kısacası ziyaretçinin gördüğü, tıkladığı, okuduğu ve form doldurduğu her şey front-end kodunun işidir; sunucudaki veriyi anlaşılır bir arayüze çevirir.

Türkçede "ön yüz" veya "istemci tarafı" da denir. İngilizcede "client-side" ifadesi aynı şeyi anlatır. Yani kod sizin sunucunuzda değil, ziyaretçinin cihazında çalışır. Bu ayrım önemlidir, çünkü ziyaretçinin telefonu, internet hızı ve tarayıcısı sizin kontrolünüzde değildir.

Front-end ayrıca işin tasarım ile yazılım arasındaki köprüsüdür. Figma'daki bir ekranı gerçek, tıklanabilir ve her ekran boyutunda düzgün duran bir sayfaya dönüştüren katman budur. Tasarım sürecinin kendisini merak ediyorsanız Figma ile web arayüz tasarımı yazıma göz atabilirsiniz.

Front-end ile back-end arasındaki sınır nerede başlar?

Basit bir kural kullanıyorum: kod ziyaretçinin tarayıcısında çalışıyorsa front-end, sunucuda çalışıyorsa back-end tarafındadır. Örneğin bir iletişim formunun alanları, hata mesajları ve gönder butonu ön yüzdür. Ancak formun e-postaya dönüşmesi ve veritabanına yazılması arka yüzün işidir.

Günümüzde bu sınır biraz bulanıklaştı. Sunucu tarafında sayfa üreten framework'ler, aynı projede hem ön hem arka yüz kodu barındırıyor. Yine de sorumluluk ayrımı değişmiyor: ön yüz, kullanıcıya ne gösterildiğinden ve nasıl hissettirdiğinden sorumludur.

Bu yüzden bir ajansla veya yazılımcıyla konuşurken "hız sorunu nerede?" sorusunu iki ayrı başlıkta sormanızı öneririm. Sunucu yanıt süresi arka yüzün, görsellerin ve script'lerin yüklenmesi ise ön yüzün alanıdır. Bu ayrım, yanlış kişiyi suçlamanızı engeller.

Örneğin sunucu yanıtı hızlı olduğu halde sayfa geç açılıyorsa sorun büyük ihtimalle ön yüzdedir. Tersine, ilk bayt bile geç geliyorsa ön yüzde yapacağınız iyileştirmenin etkisi sınırlı kalır. Bu teşhis, bütçeyi doğru yere harcamanızı sağlıyor.

HTML neden front-end'in temelidir?

HTML, sayfanın anlamını tanımlar. Başlık, paragraf, liste, buton ve form gibi öğeleri doğru etiketle yazdığınızda tarayıcı, ekran okuyucu ve arama motoru içeriğinizi doğru anlar. Dolayısıyla HTML sadece bir iskelet değil, sayfanın dilidir.

Sahada en sık gördüğüm hata "div çorbası"dır: her şeyin div ile yazıldığı, butonların aslında tıklanabilir kutu olduğu sayfalar. Görsel olarak aynı durur, ancak klavyeyle gezilemez ve ekran okuyucu bu kutuları buton olarak tanımaz. Üstelik arama motoru hangi metnin başlık olduğunu anlamakta zorlanır.

Anlamlı HTML için dikkat ettiğim temel noktalar şunlar:

• Her sayfada tek bir H1 ve mantıklı sırayla ilerleyen alt başlıklar kullanın.
• Tıklanan her öğe gerçek bir button veya a etiketi olsun.
• Form alanlarını label etiketiyle bağlayın.
• Header, nav, main ve footer gibi bölüm etiketlerini atlamayın.
• Görsellere içeriği anlatan alt metin yazın.

Yapısal veriyi de HTML katmanına siz eklersiniz. Bu konuyu schema markup rehberimde ayrıca ele aldım.

CSS görünümü nasıl yönetir?

CSS, HTML'in nasıl göründüğünü belirler: renk, yazı tipi, boşluk, yerleşim ve animasyon. Modern CSS artık eski dönemin hilelerine ihtiyaç duymuyor. Flexbox ve Grid ile karmaşık yerleşimleri birkaç satırda kurabilirsiniz.

Öte yandan CSS'in en büyük tuzağı kontrolsüz büyümesidir. Her geliştirici kendi sınıfını eklediğinde birkaç ay içinde kimsenin silmeye cesaret edemediği bir stil dosyası oluşur. Bu nedenle projeye başlarken renkleri, yazı boyutlarını ve boşlukları değişken olarak tanımlamanızı öneririm.

Renk kodlarını tutarlı seçmek için HTML renk kodları aracını kullanabilirsiniz. Böylece marka renkleri her sayfada aynı değerle kalır ve tasarımcıyla geliştirici arasında "bu mavi hangi mavi?" tartışması biter.

Bir de kullanılmayan CSS sorunu var. Hazır tema veya büyük bir CSS kütüphanesiyle başlayan projelerde, sayfaların kullandığı stil oranı çoğu zaman küçük kalıyor. Yine de tarayıcı tüm dosyayı indirip işlemek zorunda. Bu yüzden teslimden önce gereksiz stilleri temizletmenizi öneririm.

Duyarlı tasarım da CSS'in işidir. Medya sorguları ve esnek birimler sayesinde aynı sayfa telefonda tek sütun, masaüstünde üç sütun olarak görünür. Mobil öncelikli yaklaşımı mobil öncelikli tasarım yazımda detaylandırdım.

JavaScript ön yüze ne katar?

JavaScript, sayfaya davranış kazandırır. Açılır menü, sekme, form doğrulama, sepet güncelleme ve canlı arama gibi özellikler JavaScript ile çalışır. Kısacası statik bir belgeyi etkileşimli bir uygulamaya çeviren katmandır.

Ancak JavaScript aynı zamanda en pahalı kaynaktır. Tarayıcı bir görseli indirip gösterir; JavaScript'i ise indirir, ayrıştırır, derler ve çalıştırır. Özellikle orta segment telefonlarda bu süreç ekranı donduran uzun görevlere dönüşür.

Benim kuralım şudur: HTML ve CSS ile çözebildiğiniz bir işi JavaScript'e yüklemeyin. Örneğin basit bir akordeon için native details etiketi yeter. Üstelik bu yaklaşım, JavaScript yüklenemediğinde bile içeriğin görünür kalmasını sağlar.

Bir diğer önemli nokta, script'lerin yüklenme sırasıdır. Sayfanın görünmesi için gerekmeyen kodları ertelediğinizde tarayıcı önce içeriği çiziyor, ardından etkileşimi ekliyor. Böylece ziyaretçi boş bir beyaz ekran yerine okunabilir bir sayfa görüyor. Bu küçük ayar, çoğu projede hissedilir bir fark yaratıyor.

Front-end framework seçerken nelere bakmalısınız?

React, Vue, Angular ve Svelte gibi framework'ler, büyük arayüzleri bileşenlere bölerek yönetmenizi sağlar. Her bileşen kendi görünümünü ve davranışını taşır. Bu sayede aynı butonu yüz sayfada tek bir yerden güncellersiniz.

Yine de her proje framework istemez. Beş sayfalık bir kurumsal site için ağır bir tek sayfa uygulaması kurmak, ziyaretçiye gereksiz JavaScript yüklemek demektir. Seçim yaparken şu sorulara cevap vermenizi öneririm:

1. Sayfalar çoğunlukla okunan içerik mi, yoksa sürekli etkileşim mi?
2. Ekibiniz bu teknolojiyi uzun vadede sürdürebilir mi?
3. Framework sunucu tarafında HTML üretebiliyor mu?
4. Topluluk ve dokümantasyon yeterince olgun mu?
5. Yıllık güncelleme yükünü kim üstlenecek?

Çok büyük ve birden fazla ekibin çalıştığı yapılarda ön yüzü parçalara ayırmak gündeme gelir. Bu mimariyi micro frontend yazımda anlattım; burada tekrar etmiyorum.

Framework mü, sade kod mu: hangisi ne zaman mantıklı?

Aşağıdaki tablo, sahada karar verirken kullandığım kaba bir çerçevedir. Kesin kural değil, başlangıç noktasıdır.

Görüldüğü gibi belirleyici soru "hangi teknoloji popüler?" değil, "ziyaretçi bu sayfada ne yapacak?" sorusudur. Bu yüzden teknoloji kararını tasarım ve içerik planından sonra vermenizi öneririm.

Front-end kodunda erişilebilirlik neden ertelenmemeli?

Erişilebilirlik, sitenizi görme, işitme, motor veya bilişsel engeli olan kişilerin de kullanabilmesidir. Ayrıca yaşlı kullanıcılar, güneş altında telefona bakanlar ve tek eliyle gezinenler de bundan faydalanır.

Bazı pazarlarda bu konu artık yasal bir yükümlülük. Örneğin Avrupa Birliği'nde Avrupa Erişilebilirlik Yasası, belirli dijital ürün ve hizmetler için 28 Haziran 2025 itibarıyla uygulanmaya başladı. Avrupa'ya satış yapan bir e-ticaret siteniz varsa, bu başlığı hukuk danışmanınızla birlikte değerlendirmenizi öneririm.

Durum sanıldığından kötü. WebAIM Million 2026 raporuna göre incelenen bir milyon ana sayfanın %95,9'unda otomatik olarak tespit edilen WCAG hataları var. Aynı raporda düşük kontrastlı metin ana sayfaların %83,9'unda, eksik görsel alt metni ise %53,1'inde görünüyor.

İşin iyi tarafı, bu hataların çoğu front-end katmanında ve düşük maliyetle düzelir. Örneğin kontrast oranı bir renk değişikliğidir, alt metin bir özellik eklemektir. Dolayısıyla erişilebilirliği sonradan yapılacak bir "ek iş" olarak değil, kodlamanın parçası olarak görmelisiniz.

Erişilebilir ön yüz için hangi kontrolleri yapmalısınız?

Referans standart W3C'nin WCAG 2.2 yönergeleridir. AA seviyesinde normal metin için en az 4,5:1, büyük metin için 3:1 kontrast oranı gerekiyor. Bunun yanında her projede elle yaptığım kısa bir kontrol listesi var:

• Fareyi bırakın ve sayfayı yalnız Tab tuşuyla gezin.
• Odak halkası her öğede görünür mü, kontrol edin.
• Formu yanlış doldurun ve hata mesajının neyi düzelteceğinizi söyleyip söylemediğine bakın.
• Sayfayı %200 yakınlaştırın; metin taşıyor mu, bakın.
• Telefonun ekran okuyucusunu açıp menüyü dinleyin.

Bu beş adım otomatik araçların kaçırdığı pek çok sorunu yakalar. Üstelik bu testleri yaparken kullanıcı deneyimi hatalarını da fark edersiniz. Satışı düşüren arayüz hatalarını UX hataları yazımda topladım.

Performans ön yüzde nasıl ölçülür?

Google, sayfa deneyimini Core Web Vitals adlı üç metrikle ölçer. web.dev dokümantasyonuna göre iyi eşikler şunlardır: LCP 2,5 saniye veya altı, INP 200 milisaniye veya altı, CLS 0,1 veya altı. Google, ziyaretlerin %75'inde bu eşiklerin tutturulmasını hedef olarak gösterir.

LCP, sayfadaki en büyük içerik öğesinin ne zaman göründüğünü ölçer. INP, tıklama ve dokunmalara sayfanın ne kadar hızlı tepki verdiğini gösterir; Mart 2024'te FID'nin yerini aldı. CLS ise yükleme sırasında öğelerin ne kadar kaydığını ölçer.

Üç metriğin de büyük kısmı front-end kararlarına bağlıdır. Ölçümü nasıl yaptığımı Google Lighthouse ile performans testi yazımda adım adım anlattım.

Burada önemli bir ayrım var: laboratuvar verisi ile saha verisi. Lighthouse, tek bir test ortamında ölçüm yapıyor. Search Console ise gerçek ziyaretçilerin tarayıcılarından gelen verileri gösteriyor. İkisi farklı sonuç verebilir; kararı verirken saha verisini esas almanızı öneririm.

Front-end tarafında hızı en çok ne düşürür?

Sahada gördüğüm yavaş sitelerin neredeyse hepsinde aynı birkaç sebep çıkıyor. Bu liste bir sıralama değil, saha tecrübesine dayalı bir gözlemdir:

• Sıkıştırılmamış, boyutu belirtilmemiş büyük görseller.
• Her sayfaya yüklenen ama çoğu sayfada kullanılmayan JavaScript paketleri.
• Birden fazla analitik, sohbet ve reklam script'i.
• Geç yüklenen web fontları yüzünden metnin zıplaması.
• Kaydırıcı ve animasyon eklentileri.

Görselleri yüklemeden önce küçültmek en ucuz kazançtır; bunun için resim küçültme aracını kullanabilirsiniz. Ayrıca görsellere genişlik ve yükseklik vermek, CLS'yi doğrudan düşürür. Hızın sıralamaya etkisini ise site hızı ve SEO yazımda ayrıca inceledim.

Tarayıcı uyumluluğu hâlâ bir sorun mu?

Eskisi kadar değil, ama bitmedi. Internet Explorer döneminde her sayfa için ayrı hileler yazıyorduk. Bugün Chrome, Safari, Firefox ve Edge standartlara büyük ölçüde uyuyor. Yine de özellikle iOS Safari, yeni CSS ve JavaScript özelliklerini bazen geç destekliyor.

Benim yaklaşımım "aşamalı geliştirme"dir. Önce her tarayıcıda çalışan temel deneyimi kurarsınız, ardından yeni özellikleri destekleyen tarayıcılara ek iyileştirmeler sunarsınız. Böylece eski bir telefon kullanan ziyaretçi de formu gönderebilir.

Bir özelliği kullanmadan önce MDN Web Docs üzerindeki uyumluluk tablosuna bakmayı alışkanlık haline getirin. Ayrıca teslimden önce sayfayı en az bir iPhone ve bir Android cihazda gerçekten açın; emülatör her şeyi yakalamaz.

Ayrıca tarayıcı eklentilerini de hesaba katın. Reklam engelleyiciler bazen sınıf adı "banner" veya "ad" olan öğeleri gizliyor. Örneğin kampanya kutunuzun adını "ad-box" koyarsanız, ziyaretçilerin bir kısmı onu hiç görmeyebilir. Bu tür sürprizler yalnız gerçek cihaz testinde ortaya çıkıyor.

Mobil cihazlarda ön yüzü neden ayrı düşünmelisiniz?

Google, siteleri artık mobil sürümlerine göre dizine ekliyor. Yani Google'ın gördüğü ana sürüm telefon ekranındaki sayfanızdır. Bu nedenle mobilde gizlediğiniz içerik, arama motoru açısından da zayıf kalır.

Mobilde front-end hataları daha görünürdür. Parmakla basılamayacak kadar küçük butonlar, ekrana sığmayan tablolar ve açılır pencerelerin kapatma düğmesinin görünmemesi en sık karşılaştığım sorunlardır. Üstelik mobil işlemciler JavaScript'i masaüstüne göre daha yavaş çalıştırır.

Mobil kontrolü nasıl yaptığımı mobil uyumluluk testi yazımda listeledim. Kısacası tasarımı önce telefon için düşünün, sonra geniş ekrana genişletin.

Front-end SEO'yu nasıl etkiler?

Arama motoru, sayfanızı front-end kodunun ürettiği HTML üzerinden anlar. Dolayısıyla başlık hiyerarşisi, bağlantı yapısı, meta etiketler ve içeriğin ne zaman göründüğü doğrudan ön yüz kararlarıdır.

En riskli durum, içeriğin tamamen tarayıcıda JavaScript ile üretildiği sayfalardır. Google JavaScript'i işleyebilir, ancak bu ek bir adım ve gecikmedir. Ayrıca bazı yapay zeka tarayıcıları JavaScript çalıştırmadan yalnız ham HTML'i okur. Bu yüzden kritik içeriği sunucudan gelen HTML'de tutmanızı öneririm.

Bağlantıların gerçek a etiketi ve href ile yazılması da önemlidir. Tıklama olayına bağlı "sahte linkleri" arama motoru takip etmez. Meta etiketleri hızlıca hazırlamak için meta etiket oluşturucuyu kullanabilirsiniz.

Bir de sonsuz kaydırma meselesi var. Ürün listelerini yalnız kaydırdıkça yükleyen sayfalarda arama motoru ilk birkaç ürünün ötesini göremeyebilir. Bu yüzden sonsuz kaydırmanın yanında sayfalı bağlantılar da sunmanızı öneririm. Böylece hem kullanıcı rahat gezer hem de tarayıcı botu tüm ürünlere ulaşır.

Front-end kod kalitesini nasıl anlarsınız?

Kod okumuyorsanız bile kaliteyi dışarıdan anlayabilirsiniz. Örneğin sayfayı JavaScript kapalıyken açın: içerik hiç görünmüyorsa, sayfa tamamen istemci tarafında üretiliyordur. Tarayıcının geliştirici araçlarındaki konsolda sürekli kırmızı hatalar varsa, bakım disiplini zayıftır.

Ayrıca şu işaretlere bakın: aynı bileşen farklı sayfalarda farklı görünüyor mu, butonların hover ve odak halleri tutarlı mı, form hataları anlaşılır mı? Bunlar küçük detaylar gibi görünür, ancak tutarsızlık genelde ortak bir bileşen yapısı olmadığını gösterir.

Son olarak sürüm kontrolü ve belgeleme sorun. Kodun bir depoda tutulması, değişikliklerin kaydedilmesi ve kurulumun yazılı olması, ileride başka biriyle çalıştığınızda sizi kurtarır.

Kısacası kaliteli front-end kodu, sizin için şeffaf olan koddur. Ne yaptığını açıklayan bir geliştirici, sorularınızdan çekinmez ve değişikliklerin nedenini anlatabilir. Bu tavır, kodun kendisi kadar önemli bir kalite işaretidir.

Tasarımcı ile front-end geliştirici nasıl birlikte çalışmalı?

En çok zaman kaybını tasarım ve kod arasındaki kopukluk yaratıyor. Tasarımcı yalnız masaüstü ekranı çizdiğinde geliştirici mobil hali tahmin etmek zorunda kalır. Böylece ortaya iki kişinin de beğenmediği bir ara çözüm çıkar.

Bunu önlemek için tasarım aşamasında şu durumların çizilmesini isteyin: boş durum, hata durumu, yükleniyor durumu, uzun metin ve mobil görünüm. Ayrıca renk, yazı ve boşluk değerlerinin bir tasarım sistemi olarak paylaşılması, geliştiricinin her ekranı sıfırdan ölçmesini engeller.

Benim projelerimde tasarım ile kodlama aynı çatı altında ilerliyor; web tasarım hizmetimde bu süreci nasıl yürüttüğümü görebilirsiniz.

Bir front-end işini teslim alırken nelere bakmalısınız?

Projeyi kapatmadan önce kullandığım kısa teslim listesi şöyle. Her maddeyi kendiniz de kontrol edebilirsiniz:

1. Lighthouse ile mobil ve masaüstü ölçümü alın, sonuçları kaydedin.
2. Sayfayı klavyeyle baştan sona gezin.
3. Her formu hem doğru hem yanlış verilerle gönderin.
4. En az iki gerçek telefonda ve iki farklı tarayıcıda açın.
5. Konsolda hata kalmadığını doğrulayın.
6. Görsellerin boyut ve alt metinlerini kontrol edin.
7. Kaynak kodun ve kurulum notlarının size teslim edildiğinden emin olun.

Bu liste kapsamlı bir denetim değil, ancak en pahalı hataları canlıya çıkmadan yakalar. Ayrıca bir sonraki geliştiriciye temiz bir başlangıç noktası bırakırsınız.

Front-end geliştirici bir projede tam olarak ne yapar?

Front-end geliştirici, tasarım dosyasını alıp tarayıcıda çalışan sayfaya çeviren kişidir. Ancak işi yalnız ekranı çizmekle bitmiyor. Bileşenleri kuruyor, farklı ekran boyutlarını tek tek deniyor, formların davranışını yazıyor ve arka yüzden gelen veriyi arayüze bağlıyor.

Bir projede genelde şu sırayla ilerliyorum: önce ortak parçaları çıkarıyorum; buton, kart, başlık, form alanı. Ardından sayfaları bu parçalarla birleştiriyorum. Son olarak hız, erişilebilirlik ve tarayıcı testlerini yapıyorum.

Bu sıralama size de fikir verebilir. Örneğin geliştiriciniz "önce tüm sayfaları yapıp sonra düzelteceğim" diyorsa, projenin sonunda tutarsız bileşenlerle karşılaşma ihtimaliniz yüksektir. Ortak parçalarla başlamak, değişiklik geldiğinde de işinizi kolaylaştırıyor.

Yazı tipleri ve tipografi ön yüzde neden önemlidir?

Tipografi, sitenizin okunabilirliğini ve marka hissini aynı anda belirliyor. Çok ince bir yazı tipi masaüstünde şık dursa da telefonda zor okunuyor. Satır uzunluğu ve satır aralığı da okuma rahatlığını doğrudan etkiliyor.

Teknik tarafta ise web fontları dikkat istiyor. Her ağırlık ve stil ayrı bir dosya demek. Dört farklı ağırlık yüklediğinizde ziyaretçi, metni görmeden önce bu dosyaları beklemek zorunda kalabiliyor. Bu yüzden genelde iki ağırlıkla yetinmenizi ve fontları kendi sunucunuzdan sunmanızı öneririm.

Ayrıca font yüklenene kadar yedek yazı tipinin görünmesini sağlarsanız metin hemen okunur hale gelir. Yedek fontun ölçülerini asıl fonta yakın seçmek ise yükleme sonrası zıplamayı azaltıyor. Metinlerinizin okunabilirliğini kontrol etmek için okunabilirlik analizi aracını da deneyebilirsiniz.

Formlar front-end kodlamada neden ayrı özen ister?

Form, ziyaretçinin size bir şey verdiği andır: adı, telefonu, siparişi veya sorusu. Bu yüzden sitedeki en değerli ön yüz parçası genelde formdur. Öte yandan en çok hata da burada çıkıyor.

İyi bir formda dikkat ettiğim noktalar şunlar:

• Telefon alanında mobil klavyenin rakam olarak açılması.
• Hata mesajının alanın hemen yanında ve anlaşılır bir dille çıkması.
• Gönderim sırasında butonun tekrar tıklanmasının engellenmesi.
• Başarılı gönderimden sonra net bir teşekkür mesajı.
• Otomatik doldurma özelliğinin çalışması.

Bu detaylar küçük görünüyor, ancak her biri formu yarıda bırakan ziyaretçi sayısını etkiliyor. Ayrıca form gönderimini analitik aracınıza doğru olay olarak aktarmak da front-end kodunun işi. Aksi halde hangi kampanyanın talep getirdiğini göremezsiniz.

Front-end güvenliğinde nelere dikkat etmelisiniz?

Güvenlik çoğu zaman arka yüzün konusu gibi görünüyor, ancak tarayıcı tarafında da ciddi riskler var. En bilineni, kullanıcıdan gelen metnin sayfaya kontrolsüz basılmasıyla oluşan XSS açığıdır. Bu durumda saldırgan, sayfanıza kendi script'ini yerleştirebiliyor.

Bunun yanında dışarıdan yüklediğiniz her script, sitenizde sizinle aynı yetkiye sahip oluyor. Örneğin bir sohbet aracının sunucusu ele geçirilirse, o script üzerinden sayfanızdaki form verisine erişilebilir. Dolayısıyla eklediğiniz her üçüncü taraf kodunu gerçekten ihtiyaç olup olmadığına göre değerlendirin.

Son olarak şu kuralı unutmayın: tarayıcıdaki doğrulama kullanıcı deneyimi içindir, güvenlik için değildir. Fiyat, stok veya yetki kontrolünü yalnız ön yüzde yaparsanız, bunu atlatmak bir geliştirici aracıyla mümkün olur. Kritik kontroller her zaman sunucuda da tekrar etmelidir.

Ayrıca API anahtarlarını ön yüz koduna gömmeyin. Tarayıcıya giden her satırı, sayfa kaynağını açan herkes okuyabiliyor. Yani gizli kalması gereken bir bilgi, front-end kodunda asla gizli kalmaz.

Front-end testlerini nasıl kurgulamalısınız?

Test, değişiklik yaptığınızda eski özelliklerin bozulmadığını garanti etmenin yoludur. Küçük sitelerde elle kontrol çoğu zaman yeterli oluyor. Yine de sayfa ve bileşen sayısı arttıkça otomatik testler zaman kazandırıyor.

Ön yüz testlerini kabaca üç katmanda düşünebilirsiniz. Birim testleri tek bir fonksiyonu veya bileşeni kontrol ediyor. Uçtan uca testler ise gerçek bir tarayıcı açıp formu dolduruyor, sepete ürün ekliyor ve sonucu kontrol ediyor. Görsel karşılaştırma testleri de sayfanın önceki haliyle piksel düzeyinde farkını gösteriyor.

Benim önerim, en az kritik akışlar için uçtan uca test yazmanız. Örneğin iletişim formu, sepete ekleme ve ödeme adımı. Bu üç akış bozulduğunda doğrudan para kaybedersiniz; bu nedenle önce onları korumaya alın.

Front-end projesinin maliyetini neler belirler?

Ön yüz maliyetini sayfa sayısından çok, benzersiz şablon sayısı ve etkileşim düzeyi belirliyor. On sayfalık bir sitede yalnız üç farklı şablon varsa, iş sanıldığından hızlı ilerler. Öte yandan tek bir ürün yapılandırıcısı, bütün siteden daha fazla emek isteyebilir.

Maliyeti artıran diğer kalemler şunlar: özel animasyonlar, çok dilli yapı, üçüncü taraf entegrasyonları ve yüksek erişilebilirlik hedefi. Ayrıca tasarımın mobil ve hata durumlarını kapsamaması, geliştirmede tahmin ve revizyon süresini uzatıyor.

Kısacası teklif karşılaştırırken yalnız toplam rakama değil, kapsamın ne kadar net yazıldığına bakın. Hangi tarayıcılarda test edileceği, performans hedefi ve kaynak kodun teslimi teklif metninde açıkça geçmelidir.

Front-end bakımı neden bir kerelik iş değildir?

Ön yüz kodu, bağımlı olduğu kütüphaneler ve tarayıcılar değiştikçe eskir. Bir framework sürümü desteğini kaybettiğinde güvenlik yamaları gelmez. Tarayıcı bir özelliği değiştirdiğinde ise dün düzgün olan bir menü bugün bozulabilir.

Bu nedenle yılda en az bir kez bağımlılıkları güncellemenizi, performans ve erişilebilirlik ölçümünü tekrarlamanızı öneririm. Ayrıca yeni eklenen her pazarlama script'ini sorgulayın; yavaşlığın büyük kısmı zamanla birikir.

Özetle front-end, sitenizin ziyaretçiyle konuşan yüzüdür. Anlamlı HTML, düzenli CSS, ölçülü JavaScript, erişilebilirlik ve performans bir arada düşünüldüğünde site hem kullanıcıya hem arama motoruna aynı netlikte konuşur. Bir projeniz varsa bu başlıkları birlikte gözden geçirebiliriz.