Web Performansı 2026: Sürdürülebilir Optimizasyon ve İzleme Disiplini

1. Core Web Vitals 2026: LCP, INP, CLS

Google'ın Core Web Vitals seti 2026 itibarıyla üç ana metrik üzerinde kararlı kaldı: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) ve Cumulative Layout Shift (CLS). Mart 2024'te First Input Delay (FID) yerine geçen INP, kullanıcının siteyle kurduğu tüm etkileşimleri kapsayan ve gerçek tepkiselliği ölçen bir metriktir. 2025-2026 döneminde Google, INP'yi sıralama sinyali olarak FID'den daha güçlü konuma yerleştirdi.

Üç metriğin 2026 hedef eşikleri şu şekildedir:

• LCP: 2.5 saniye altı iyi, 4 saniyenin üzeri zayıf. Mobil cihazda 4G hat üzerinden ölçülür.
• INP: 200 ms altı iyi, 500 ms üzeri zayıf. Tüm tıklama, dokunma ve tuş etkileşimlerinin 75. yüzdelik dilimi temel alınır.
• CLS: 0.1 altı iyi, 0.25 üzeri zayıf. Sayfa yaşam döngüsü boyunca beklenmeyen düzen kaymalarının toplamıdır.

Bu metrikler tek başına yetmiyor. Google Search Console, Chrome User Experience Report (CrUX) verilerini sıralama girdisinin temel kaynağı olarak kullanır. Yani size laboratuvar testlerinde mükemmel sonuçlar veren bir sayfanın, gerçek kullanıcı verisinde "Needs Improvement" görünmesi mümkündür. Bu açığı kapatmak ancak saha verisi toplamakla mümkündür.

Fatih Web Tasarım olarak müşterilerimizin sitelerinde önce sayfa türüne göre ayrı ayrı LCP, INP ve CLS hedefleri tanımlarız. Anasayfa, kategori sayfası, ürün detay sayfası ve blog yazısı için farklı bütçeler kurarız. Tek bir global eşik tüm sayfa tiplerine adil davranmaz.

2026'da gözlemlediğimiz önemli bir eğilim: Time to First Byte (TTFB) sıralama sinyali olmadığı için göz ardı edilen ancak LCP'nin alt sınırını belirleyen bir metriktir. TTFB 800 ms'nin üzerine çıkan sayfaların LCP eşiğini tutturması teknik olarak imkânsız hale gelir. Edge mimari ve doğru cache stratejisi bu noktada hayat kurtarır.

2. Sentetik Testler ile RUM Arasındaki Fark

Performans ölçümünde iki farklı dünya vardır: sentetik testler (synthetic monitoring) ve gerçek kullanıcı izleme (Real User Monitoring, RUM). İkisi de gereklidir, ancak farklı sorulara cevap verirler.

Sentetik testler kontrollü bir laboratuvar ortamında çalışır. Belirlenen bir ağ profili (örneğin Slow 4G), belirlenen bir cihaz (Moto G4 emülasyonu) ve belirlenen bir konumdan sayfa açılır, metrikler ölçülür. Avantajı tekrarlanabilir olmasıdır. Aynı testi her gün aynı koşullarda çalıştırarak regresyon yakalayabilirsiniz. Dezavantajı ise gerçek kullanıcının nasıl deneyimlediğini yansıtmamasıdır.

RUM ise gerçek ziyaretçilerin tarayıcısında JavaScript ile ölçüm yapar. Bir kullanıcı sitenize girer, gerçek cihazı, gerçek ağ koşulu ve gerçek davranışıyla metrik üretir. Avantajı saha gerçeğini yansıtmasıdır. Google'ın CrUX verisi tam olarak budur. Dezavantajı ise kontrol edilemez gürültü içermesidir: bir kullanıcının metro trafiğinden 3G'ye düşmesi ölçümünüzü dramatik şekilde bozar.

İki yaklaşımı şu şekilde dengelersiniz:

• Sentetik testler her PR (pull request) öncesi CI'da çalışır — regresyon önleme için
• Sentetik testler ayrıca her saat başı bir cron işiyle çalışır — uptime ve sürüklenme tespiti için
• RUM 7/24 üretim ortamında çalışır — gerçek kullanıcı eğilimini izlemek için
• İki kaynağı tek bir dashboard'da birleştirin — Datadog, New Relic, Sentry Performance veya Grafana

2026'nın trendi her iki kaynaktan veriyi tek bir veri ambarına (BigQuery, ClickHouse) akıtmak ve görselleştirme katmanını ayırmaktır. Bu, performans verisini diğer ürün metrikleri (dönüşüm, sepet terk oranı) ile çapraz analiz etmeyi sağlar.

3. Lighthouse, PageSpeed Insights ve WebPageTest Karşılaştırması

Performans ölçüm araçları içinde üç araç ekosistemin kalbini oluşturur. Her birinin güçlü ve zayıf yönleri vardır; doğru aracı doğru iş için seçmek profesyonel bir disiplindir.

Lighthouse

Chrome DevTools içinde gelen Lighthouse, geliştiricinin lokal makinesinde tek tıkla rapor üretir. Performans, erişilebilirlik, SEO, PWA ve best practices alanlarında puan verir. CLI versiyonu (lighthouse-ci) CI/CD pipeline'a entegre edilebilir. En büyük avantajı sahip olduğunuz her makinede aynı şekilde çalışmasıdır. Dezavantajı, lokal makinenin CPU yüküne göre puanların değişkenlik göstermesidir.

PageSpeed Insights

PageSpeed Insights (PSI), Lighthouse'un Google sunucularında çalışan versiyonudur. Tek farkla: CrUX saha verisini sentetik laboratuvar verisinin yanında gösterir. Bir sayfanın gerçek kullanıcılarının deneyimi (eğer yeterli trafik varsa) ile laboratuvar simülasyonu yan yana karşılaştırılır. SEO açısından PSI'nın "Origin Summary" bölümü kritik öneme sahiptir; çünkü Google'ın sıralama sinyali bu veriden beslenir.

WebPageTest

WebPageTest, profesyonel performans denetiminin altın standardıdır. 40'tan fazla coğrafi konumdan, gerçek mobil cihazlarda ve çeşitli ağ koşullarında test yapabilirsiniz. Waterfall görselleştirmesi, request-by-request analiz ve film şeridi (filmstrip) çıktıları ile darboğazları tespit etmek için eşsizdir. Ücretsiz versiyonu sınırlıdır, kurumsal hesaplar (WebPageTest Pro) aylık 300-1500 USD aralığında ücretlendirilir.

Hangisini ne zaman kullanmalı:

• Lighthouse: Geliştirme sırasında hızlı kontrol, PR review öncesi
• PageSpeed Insights: Aylık denetim raporu, müşteri sunumu, CrUX bağlamı için
• WebPageTest: Derinlemesine darboğaz analizi, çoklu konum karşılaştırması, video kaydı

Üç aracı paralel kullanmak bilinçli bir tercihtir. Tek bir araca bağımlılık ölçüm körlüğüne yol açar.

4. RUM Kurulumu: web-vitals.js ile Saha Verisi

Saha verisi toplamak için Google'ın açık kaynak kütüphanesi web-vitals.js, 2026'da fiilî standarttır. Sadece 1.5 KB boyutunda, Core Web Vitals metriklerini gerçek kullanıcı tarayıcısında ölçer ve istediğiniz endpoint'e gönderir.

Tipik bir RUM kurulumu şu bileşenlerden oluşur:

• İstemci tarafı: web-vitals.js sayfa açılışında yüklenir, metrikleri toplar
• Beacon endpoint: Metrikler navigator.sendBeacon() ile sunucuya gönderilir
• Toplama servisi: Cloudflare Workers, Vercel Edge Function veya FastAPI mikro servisi
• Veri ambarı: ClickHouse, BigQuery veya PostgreSQL TimescaleDB
• Görselleştirme: Grafana, Metabase, Datadog veya özel React dashboard

Veri toplarken dikkat edilmesi gereken metriklerin yanı sıra boyutlandırma alanları da kritiktir:

• Sayfa URL'i (anasayfa, kategori, detay ayrımı için)
• Cihaz tipi (mobil, tablet, masaüstü)
• Tarayıcı ve versiyon
• Bağlantı tipi (4G, 5G, WiFi)
• Coğrafi konum (ülke, şehir bazında)
• Trafik kaynağı (organik, direkt, reklam)

Bu boyutlarla zenginleştirilmiş veri, "Antalya'dan mobil kullanıcıların ürün sayfasındaki INP'si nedir?" gibi spesifik soruların cevabını verir. Genel ortalamalar yanıltıcıdır; segment bazlı analiz gerçek sorunu açığa çıkarır.

2026'nın bir başka eğilimi Long Animation Frames (LoAF) API'sinin yaygınlaşmasıdır. INP'yi yavaşlatan uzun JavaScript görevlerinin (Long Tasks) hangi script'ten geldiğini saniyenin %5'inden küçük doğrulukla raporlar. Sentry ve Datadog gibi APM platformları LoAF entegrasyonunu standart paketlerine ekledi.

5. Performans Bütçesi Belirleme ve Yönetme

Performans bütçesi (performance budget), bir sayfanın aşmaması gereken eşik değerleri tanımlayan ölçülebilir bir sözleşmedir. Tıpkı finansal bütçe gibi: aşıldığı anda sürüm durur, geri dönüş gerekir. Bütçesiz takımlar her sürümde yavaşça bozulma yaşar; çünkü her yeni özellik biraz daha JavaScript, biraz daha network çağrısı, biraz daha render maliyeti getirir.

İyi bir performans bütçesi şu kategorilerde tanımlanır:

• Boyut bütçeleri: Toplam JS < 200 KB (gzipped), CSS < 50 KB, görsel < 500 KB/sayfa
• Sayı bütçeleri: Üçüncü taraf script < 8, network request < 50
• Zaman bütçeleri: LCP < 2.5 s, INP < 200 ms, TTFB < 600 ms
• Skor bütçeleri: Lighthouse Performance Score > 85

Bu bütçeler ekipler arasında müzakere edilerek belirlenir. Pazarlama tarafı yeni bir analitik script eklemek isterse, mevcut bir script'i kaldırarak yer açılmalıdır. Bu disiplin "sustainability by constraint" felsefesinin temelidir.

Bütçeleri otomatik denetlemek için lighthouse-ci'nın budget.json dosyası kullanılır. Webpack Bundle Analyzer ve Vite'ın build.rollupOptions ayarları da bundle boyutunu sürüm öncesi yakalar. CI pipeline'ında bütçe ihlalinde build başarısız olur, sürüm durur.

Müşterilerimizde gördüğümüz tipik senaryo: bütçe konulduktan sonra ilk hafta 3-4 sürüm bütçe ihlali nedeniyle durur. İkinci haftadan itibaren ekip alışır ve yeni özellikleri bütçe içinde tasarlamayı öğrenir. Üç ay sonra bütçeler kemikleşir ve sıralı performans iyileştirme başlar.

6. CI/CD Pipeline'a Lighthouse CI Entegrasyonu

Performans bütçelerinin uygulanabilir olması için CI/CD pipeline'a sıkı entegrasyon gerekir. Lighthouse CI bu görevin endüstri standardı çözümüdür. GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines — hangisini kullanırsanız kullanın, Lighthouse CI eklenmeden bir sürüm üretime çıkmamalıdır.

Tipik bir GitHub Actions adımı şu şekilde yapılandırılır:

• PR açıldığında preview deploy oluşturulur (Vercel, Netlify, Cloudflare Pages)
• Preview URL üzerinde Lighthouse CI 3-5 kez çalışır (medyan alınır)
• Sonuçlar Lighthouse CI Server'a gönderilir veya GitHub Check olarak yorumlanır
• Bütçe ihlali varsa PR check başarısız olur, merge engellenir
• Geliştirici raporu inceler, düzeltir veya bütçe revize edilir

3-5 kez çalıştırmanın sebebi sentetik ölçümün doğal varyansıdır. Tek bir çalışma ±%5-8 dalgalanma içerir. Medyan almak gürültüyü filtreler. Lighthouse CI'nın numberOfRuns parametresi bunu yönetir.

2026'da CI'da sıkça gözlemlenen bir tuzak: GitHub Actions runner'larının CPU yükü değişken olduğu için Lighthouse skorları gün boyu salınır. Çözüm, dedicated runner kullanmak veya Treosh Lighthouse CI Action gibi optimize edilmiş aksiyonlar tercih etmektir.

Lighthouse CI Server kurmak isteyenler için Docker image hazırdır. Ekibimiz bir Docker Compose yapılandırması ile 30 dakikada self-hosted bir Lighthouse CI Server kurar. Sonuç: takımdaki tüm geliştiriciler PR'lerinin performans grafiğini tarihsel bağlamda görür.

7. Edge-First Mimari ve CDN Stratejisi

Edge-first mimari, performans optimizasyonunun 2026'daki en güçlü kaldıracıdır. Geleneksel "tek bir AWS bölgesinde origin" modeli, Türkiye'den gelen kullanıcılar için 100-200 ms gereksiz gecikme üretir. Bu gecikmenin tamamı TTFB'ye yansır ve LCP eşiğini doğrudan tehdit eder.

Modern edge stratejisi şu katmanlardan oluşur:

• Statik içerik: CDN edge'de cache'lenir (Cloudflare, Fastly, Bunny.net)
• Dinamik içerik: Edge function veya origin (cache HIT/MISS karması)
• API yanıtları: Edge cache + stale-while-revalidate
• Kullanıcı bazlı içerik: Edge cookie ile bölünür

Türkiye'de servis veren bir e-ticaret sitesi için Cloudflare İstanbul edge node'u, kullanıcıdan 5-15 ms uzakta yer alır. Karşılaştırıldığında AWS eu-central-1 (Frankfurt) konumu 30-45 ms uzaktadır. Bu fark çarpma etkisiyle (HTML, CSS, JS, font, görsel her biri ayrı request) toplamda 200 ms'ye ulaşabilir.

Edge function'lar JavaScript'in V8 izolatlarında milisaniyeler içinde çalışır. Geleneksel serverless function'ların cold start sorunu (200-1000 ms) edge function'larda neredeyse yoktur. Cloudflare Workers, Vercel Edge Functions, Deno Deploy ve AWS Lambda@Edge bu kategorinin önde gelen sağlayıcılarıdır.

Edge mimarisinin getirdiği bir başka avantaj DDoS koruması ve WAF (Web Application Firewall) entegrasyonudur. Saldırı geldiğinde origin sunucu hiç bilmez, edge'de filtrelenir. Bu hem performansı hem güvenliği güçlendirir.

8. JavaScript Yönetimi ve Üçüncü Taraf Script Kontrolü

2026'da en büyük performans katili hâlâ JavaScript'tir. Tipik bir kurumsal sitenin 1.5-3 MB ham JavaScript taşıdığını görüyoruz; bunun büyük kısmı üçüncü taraf scriptler (analitik, reklam, chat, A/B test, ısı haritası) tarafından getirilir. Her bir script ana thread'i bloke ederek INP'yi düşürür.

JavaScript yönetimi için 2026'da uyguladığımız stratejiler:

• Code splitting: Sayfa bazlı bundle, route-level lazy loading
• Tree shaking: Kullanılmayan kodun bundle'dan çıkarılması
• Dynamic import: Etkileşim bekleyen bileşenlerin ihtiyaç anında yüklenmesi
• Partytown: Üçüncü taraf scriptlerin web worker'da çalışması
• defer/async: Ana thread'i bloke etmeyen yüklemeler

Partytown, 2026'da üçüncü taraf script yönetiminde devrim yarattı. Google Tag Manager, GA4, Facebook Pixel, Hotjar gibi scriptler ana thread'den web worker'a taşınır. Sonuç: INP %40-60 oranında iyileşir. Kurulumu birkaç satır kod ile mümkündür ancak bazı scriptlerin web worker'da çalışmaması gibi uyumsuzluk durumları test gerektirir.

Üçüncü taraf script audit'i her ay yapılmalıdır. Pazarlama ekibinin eklediği ama unutulan A/B test scriptleri, eski reklam pikselleri ve ölü heat-map araçları sıkça karşımıza çıkar. Bir denetim tipik olarak 5-12 ölü script ortaya çıkarır. Bunları kaldırmak çoğu zaman tek bir gün içinde Lighthouse Performance Score'u 15-25 puan artırır.

9. Görsel, Font ve Medya Optimizasyonu

Görseller bir sayfanın toplam ağırlığının %60-75'ini oluşturur. Doğru yönetildiğinde performansa en büyük katkıyı yapan, yanlış yönetildiğinde en büyük problem alanıdır.

2026'da görsel optimizasyon için uyguladığımız standartlar:

• WebP/AVIF: JPG/PNG yerine modern formatlar, %30-60 daha küçük
• Responsive images: srcset ve sizes ile cihaza özel boyut
• Lazy loading: loading="lazy" attribute (above-the-fold hariç)
• Fetchpriority: LCP görseline fetchpriority="high" verilir
• Width/height attribute: CLS önlemek için boyutlar HTML'de tanımlı
• Image CDN: Cloudinary, Bunny Optimizer, ImageKit gibi servisler

Image CDN kullanımı 2026'nın en yaygın eğilimidir. Cloudinary veya Bunny Optimizer, görseli kullanıcı cihazına göre dinamik olarak optimize eder, WebP/AVIF formatına çevirir ve CDN edge'inde cache'ler. Geliştirici hiçbir manuel optimizasyon yapmaz; URL parametreleriyle kontrol edilir.

Font yükleme stratejisi de kritiktir. Web fontları yanlış yüklendiğinde FOIT (Flash of Invisible Text) veya FOUT (Flash of Unstyled Text) sorunlarına neden olur. 2026 best practice:

• font-display: swap kullanın
• Critical fontları <link rel="preload"> ile öne çekin
• Subset fontlar kullanın (Türkçe karakter destekli ama Latin Extended değil)
• System font stack fallback hazır olsun
• Variable font tercih edin (tek dosya, birden çok ağırlık)

Video içerik için <video> elementinde preload="metadata" kullanılır, otomatik oynatılan hero video varsa poster attribute kritik LCP içeriğidir. YouTube veya Vimeo embed yerine lite-youtube-embed veya Cloudflare Stream tercih edilmesi 2026 standardıdır.

10. Cache Stratejileri ve Service Worker

Cache, performansın en güçlü silahıdır. Doğru cache stratejisi olmayan bir site, ne kadar optimize edilmiş olursa olsun tekrarlayan ziyaretçilere ilk ziyaret kadar yavaş gelir. Cache katmanları üç seviyede yönetilir: tarayıcı cache, CDN cache ve service worker cache.

Tarayıcı cache HTTP başlıklarıyla yönetilir:

• Statik asset'ler: Cache-Control: public, max-age=31536000, immutable
• HTML dosyaları: Cache-Control: no-cache veya max-age=0, must-revalidate
• API yanıtları: Cache-Control: private, max-age=60, stale-while-revalidate=300

Versiyonlama için dosya isminde hash kullanmak (örneğin app.4f8a2c.js) cache invalidation problemini çözer. Bu, modern bundler'ların (Vite, Webpack, esbuild) varsayılan davranışıdır.

CDN cache, Cloudflare veya Fastly üzerinde origin-shield mimarisi ile yönetilir. Origin'e gelen yük %95-99 oranında azalır. Cache HIT oranınız %85 altındaysa, Page Rules veya Cache Rules ile derinlemesine yapılandırma yapmanız gerekir.

Service worker ise üçüncü ve en güçlü cache katmanıdır. Workbox kütüphanesiyle yönetilen bir service worker:

• Offline çalışma sağlar
• Network-first, cache-first, stale-while-revalidate stratejileri uygular
• Push bildirim ve arka plan senkronizasyonu sunar
• Önbelleğe alınmış sayfalar tekrar ziyaretlerde anında açılır

Service worker kurulumu 2026'da PWA standardının vazgeçilmez parçasıdır. Tekrar ziyaretlerde LCP'yi 200-400 ms'ye düşürür. Bu, dönüşüm oranlarında %15-30 artışla doğrudan ilişkilidir.

11. Uyarı Sistemleri ve Performans SLO'ları

Bir performans sorununu üretimde fark etmek için müşteri şikâyetini beklemek 2010'ların yaklaşımıdır. 2026'da modern bir site, performans metriklerini SLO (Service Level Objective) çerçevesinde izler ve eşik aşıldığında otomatik uyarı üretir.

Tipik SLO örnekleri:

• "Mobil kullanıcıların %75'inin LCP değeri 2.5 saniye altında olacak"
• "INP P75 değeri 200 ms'yi 7 günden uzun süre aşmayacak"
• "TTFB P95 değeri 800 ms altında kalacak"
• "Hata oranı %0.5'in altında olacak"

SLO'nun aşılma riski yaklaştığında (örneğin "error budget" %80 tüketildiğinde) ekibe uyarı gönderilir. Bu uyarılar PagerDuty, Slack, Opsgenie veya basit bir Discord webhook üzerinden iletilebilir. Önemli olan, ölçüm-uyarı-aksiyon döngüsünü 30 dakika içinde kapatmaktır.

Sentry Performance, Datadog RUM, New Relic Browser, Grafana Cloud — bu araçların hepsi SLO ve alert tanımlamayı destekler. Self-hosted çözüm tercih edenler için Prometheus + Alertmanager + Grafana kombinasyonu fiilî standarttır.

2026'nın bir başka eğilimi anomaly detection tabanlı uyarılardır. Sabit eşik (LCP > 2.5 s) yerine, makine öğrenmesi modeli "bu saat ve gün için normal LCP dağılımı" üretir ve sapma tespit eder. Datadog Watchdog ve Dynatrace Davis bu yaklaşımın önde gelen örnekleridir.

Uyarı yorgunluğunu önlemek için iki kural: birincisi, "actionable" olmayan uyarı tanımlama. Aksi takdirde ekip uyarıları görmezden gelir. İkincisi, uyarı sayısını ayda 5-10 ile sınırlayın. Bu, ölçüm sisteminizin disiplinini test eder.

12. Sürekli İyileştirme: Ayda Bir Performans Sprintleri

Performans iyileştirme bir kerelik proje değil, sürekli devam eden bir süreçtir. Müşterilerimize önerdiğimiz model: ayda bir gün özel performans sprinti. Tüm ürün geliştirme durur, sadece performansa odaklanılır.

Bir performans sprinti şu adımlardan oluşur:

• Veri inceleme (1-2 saat): Geçen ay metriklerin trend grafiği analiz edilir
• Regresyon analizi (1-2 saat): Hangi sürüm hangi metriği bozdu
• Darboğaz tespiti (2-3 saat): WebPageTest ile detaylı analiz
• Düzeltme uygulaması (3-4 saat): Tespit edilen 2-3 sorunun çözümü
• Doğrulama (1 saat): Sonuçların ölçülmesi ve raporlanması

Bu yaklaşım kümülatif kazanım sağlar. Yılda 12 sprint sonunda Lighthouse Performance Score 30-50 puan iyileşir; CrUX saha verisinde "Good" oranı %40'tan %85'e çıkar. Tek bir büyük performans projesi yerine sürekli küçük iyileştirmeler daha sürdürülebilir ve risk düşüktür.

Performans sprintlerinin yıllık planında bazı sabit ajanda başlıkları olmalı:

• Üçüncü taraf script audit (her çeyrek)
• Bundle boyutu trend analizi (her ay)
• Image CDN kullanım raporu (her ay)
• Cache HIT oranı incelemesi (her ay)
• Geliştirici eğitim oturumu (her çeyrek)

2026'da performans, bir takımın olgunluğunun en güvenilir göstergesidir. Performans bütçesine sahip, CI'da denetleyen, RUM kuran, ayda bir sprint yapan bir takım — sektörün üst %10'unda yer alır.

Sonuç: Performans Bir Kültürdür

Web performansının etkin izlenmesi ve sürekli optimize edilmesi, tek bir araç veya tek bir mühendisin sorumluluğu değildir. Tasarımcısından geliştiricisine, pazarlama ekibinden ürün yöneticisine kadar tüm takımın paylaştığı bir kültürdür. Bu kültür ancak ölçülebilir hedefler (SLO), şeffaf izleme sistemleri (RUM + sentetik), katı kurallar (performans bütçesi) ve sürekli iyileştirme ritmi (aylık sprintler) ile yerleşir.

Fatih Web Tasarım olarak Antalya merkezimizden Türkiye genelindeki kurumsal müşterilerimize bu disiplini kurmaktayız. Yeni site projelerinde performans birinci günden itibaren mimari kararların parçasıdır. Mevcut site müşterilerimizde önce mevcut durum denetimi yapılır, ardından 3 aylık iyileştirme yol haritası uygulanır. Sitenizin performansını profesyonel bir gözle değerlendirmek için bizimle iletişime geçin; ücretsiz teknik denetim ile başlayalım.