Core Web Vitals & Performans

Core Web Vitals Denetimi: LCP, INP ve CLS Sorunları Nasıl Teşhis Edilir?

Core Web Vitals denetimi saha verisiyle başlar, ardından zayıf LCP, INP ve CLS sonuçlarını laboratuvar testleriyle yeniden üretip teşhis eder. Template seviyesindeki pattern'leri tekil sayfa sorunlarından ayırın ve düzeltmeyi field-data penceresinde doğrulayın.

Yayınlandı: 6 Eylül 2026 · Güncellendi: 6 Eylül 2026

Core Web Vitals Denetimi: LCP, INP ve CLS Sorunları Nasıl Teşhis Edilir?

Kısa bakış

Özet

Core Web Vitals denetimi saha verisiyle başlar, ardından zayıf LCP, INP ve CLS sonuçlarını laboratuvar testleriyle yeniden üretip teşhis eder.
Template seviyesindeki pattern'leri tekil sayfa sorunlarından ayırın ve düzeltmeyi field-data penceresinde doğrulayın.
Core Web Vitals denetimi, PageSpeed skorunu mümkün olduğunca yükseltme çalışması değildir.

Murat tarafından hazırlandı · Teknik SEO Uzmanı

Core Web Vitals denetimi, PageSpeed skorunu mümkün olduğunca yükseltme çalışması değildir. Bir sayfa tek bir Lighthouse testinde iyi görünürken gerçek kullanıcılar yavaş yükleme, gecikmiş etkileşim veya layout shift yaşayabilir.

Denetim saha verisiyle başlamalı, hangi metrik ve sayfa gruplarının başarısız olduğunu belirlemeli ve ardından lab araçlarıyla kök nedeni yeniden üretmelidir.

Core Web Vitals Denetimi Nedir?

Core Web Vitals denetimi, Largest Contentful Paint (LCP), Interaction to Next Paint (INP) ve Cumulative Layout Shift (CLS) için gerçek kullanıcı ve laboratuvar performansını değerlendirir. Amaç sadece skoru raporlamak değil, sayfa grubunun neden başarısız olduğunu açıklamaktır. Ayrıntılı değerlendirme için organik trafik düşüşü analizi rehberini inceleyin.

Yalnızca Lighthouse Değil, Saha Verisiyle Başlayın

Mümkün olduğunda Chrome UX Report, PageSpeed Insights field data ve Search Console Core Web Vitals gruplarını kullanın. Saha verisi gerçek kullanıcılardan gelir ve hareketli bir zaman penceresinde değerlendirilir. Ardından Lighthouse ile sorunu kontrollü koşullarda yeniden üretin.

LCP Sorunlarını Teşhis Edin: Yükleme ve En Büyük İçerik

LCP elementini bulun ve neyin geciktirdiğini belirleyin. Yaygın nedenler yavaş TTFB, render-blocking CSS, geç keşfedilen görsel, ağır hero medya, font davranışı ve client-side rendering'dir. İlgisiz asset'ler yerine gerçek LCP bottleneck'ini çözün.

INP Sorunlarını Teşhis Edin: Etkileşim ve Main Thread

INP, interaction responsiveness'ını ölçer. Uzun main-thread task'leri, ağır JavaScript, pahalı event handler'ları, üçüncü taraf script'leri, hydration ve kullanıcı input'u sonrası çalışan UI işlemlerini inceleyin. Sayfa hızlı yüklenebilir ama click veya tap'e geç cevap veriyorsa kullanıcı yine yavaşlık hisseder.

CLS Sorunlarını Teşhis Edin: Görsel Kararlılık

CLS sorunları çoğu zaman alanı önceden ayrılmamış görseller, reklam, embed, banner, font, sonradan eklenen içerik ve geç yüklenen UI elementlerinden çıkar. Hangi elementin neden hareket ettiğini gözlemleyin ve alan/yerleşim davranışını düzeltin.

Şablon Düzeyi ve Sayfa Düzeyi Sorunlarını Ayırın

URL'leri template gruplarına ayırın. Tüm ürün sayfaları INP'de başarısız olurken blog yazıları geçiyorsa kök neden muhtemelen template veya component seviyesindedir. Sadece tek URL başarısızsa o sayfanın özel asset veya embed'lerini kontrol edin.

Sunucu Yanıtı, Görseller, Fontlar, CSS ve JavaScript'i Kontrol Edin

TTFB, cache, CDN davranışı, image format/dimensions, font loading, render-blocking CSS, JavaScript payload, main-thread work ve üçüncü taraf script'leri inceleyin. Gerçekten başarısız metriğe katkıda bulunan kaynağı önceliklendirin.

PageSpeed Insights, CrUX ve Search Console'u Birlikte Kullanın

Her aracın rolü farklıdır. Search Console grup seviyesinde field issue gösterir, CrUX gerçek kullanıcı ölçümleri sağlar, PageSpeed Insights ise field ve lab teşhisini birleştirir. Tek bir Lighthouse skorunu nihai karar olarak kullanmayın.

Düzeltmeleri Etkilenen Sayfa Gruplarına Göre Önceliklendirin

Yüksek değerli template ve büyük URL gruplarını önce düzeltin. Ürün sayfalarını site genelinde etkileyen LCP sorunu, düşük trafikli tek bir makaleden daha önceliklidir. Platform bağlamı için WordPress teknik SEO veya Shopify teknik SEO rehberlerine bakın.

İyileşmeyi Saha Verisi Penceresinde Doğrulayın

Lab düzeltmeleri hemen test edilebilir; saha verisinin yeni kullanıcı deneyimini yansıtması zaman alır. Etkilenen URL gruplarını izleyin ve yeterli yeni veri biriktikten sonra field metrics'i karşılaştırın. Sorun launch sonrasında başladıysa site taşıma sonrası SEO denetimi ile birlikte değerlendirin.

Sonuç

Faydalı bir Core Web Vitals denetimi hangi metriğin başarısız olduğunu, hangi template'lerin etkilendiğini ve hangi resource veya component'in problemi yarattığını açıklar. Saha verisiyle başlayın, lab testlerini teşhis için kullanın ve sonucu gerçek kullanıcı verisiyle doğrulayın.

The approved query map explicitly defines all 10 EN/TR pairs as true equivalents with reciprocal hreflang when both are published with equivalent intent/coverage. Because the English and Turkish blueprints now cover both sides, the recommended release is paired publication.

Each EN/TR pair self-canonicals to its own language URL.
On both pages add reciprocal `hreflang="en"` and `hreflang="tr"`; retain English as `x-default` if that remains the site-wide convention.
Language switcher on each new article should go directly to its paired equivalent, not merely to /blog/ or /tr/blog/.
If one language page is intentionally delayed, do not publish a dead hreflang target; add the pair only when both URLs are live.
Keep /blog/ ↔ /tr/blog/ reciprocal hub alternates unchanged during hub redesign.
Do not hreflang merely related articles.

Files / routing

Create each article as `/tr/blog/<slug>/index.html` following V43 static folder convention.
Update `/tr/blog/index.html` to the lean hub structure and preserve /blog/ language-switch relationship.
Use existing `/assets/css/styles-v41.css` and `/assets/js/main-v41.js` architecture unless the actual latest production version has newer bundles. Add only the CSS/JS necessary for search/filter and reused article components.
Add the 10 exact WebP files to `/assets/images/` using Part D filenames.
Update sitemap.xml with all 10 new Turkish canonical URLs. If EN counterparts are released simultaneously, include all 20 new URLs. Do not remove unrelated existing URLs.
No filter/search/category URLs enter sitemap, robots, canonical logic, hreflang or schema.

Preserve existing V43 GTM bootstrap and consent gating.
Do not fire analytics before existing consent rules permit it.
CTA buttons should use existing Turkish button classes/taxonomy so CTA tracking remains compatible.
Hub search/filter event tracking is optional; do not add URL parameters just for analytics.

Performance

Convert source PNGs to WebP; never serve multi-megabyte PNG source artwork in production.
Use explicit dimensions/aspect-ratio to prevent CLS.
Lazy-load below-the-fold hub/related images; prioritize article hero image.
Use lightweight vanilla JS for ~30 items; no external filtering/search library required.
Do not create duplicate card-image derivatives unless performance testing proves a need.

Automated / file-level QA

All 10 Turkish article folders and all 10 production WebP files exist.
All 10 new Turkish URLs appear exactly once in sitemap.xml; if paired EN release is same build, verify all 20.
No existing sitemap URL is accidentally removed.
All 30 Turkish article URLs exist as normal href links in initial /tr/blog/ HTML.
No `?category=`, `/page/2/`, search-result or filter URLs are generated.
No broken links among new pages, 30 inbound placements, related cards, hub library and /tr/#iletisim CTAs.
Exactly one H1 per new article and exactly one H1 on /tr/blog/.
Absolute HTTPS self-canonicals.
OG/Twitter mapped images resolve.
FAQPage schema matches visible FAQ copy.
Hub ItemList count/members match 30 Turkish article URLs.
For paired release, reciprocal en/tr/x-default and article language switchers validate across all 10 pairs.

Rendered / browser QA

Viewport / check	Acceptance
Desktop ≥1280px	Compact hero; search + six chips fit/wrap cleanly; 2 featured; 3 recent; 3×3 guide grid; readable compact links; CTA band balanced.
Tablet ~768–1024px	Chips wrap or horizontally scroll accessibly; cards collapse appropriately; no overflow.
Mobile 320–430px	H1s wrap cleanly; search full-width; chips touch-friendly; cards stack; images/text are not cropped; CTA remains clear.
Contrast	Eyebrows, descriptions, inactive chips and metadata remain readable on cream/ivory backgrounds.
No-JS check	Full Turkish library remains visible/crawlable. Search/filter enhancement may be unavailable but core navigation works.
JS check	Search + chip filtering combine correctly; Tümü resets; empty search restores; zero-results message works; URL never mutates.
Image check	All 10 new images render at 1200×630 aspect ratio without distortion/overflow/layout shift.
Schema	Validate representative BlogPosting/FAQ/Breadcrumb + hub CollectionPage/ItemList; no duplicate conflicting entities.
Consent/analytics	Cookie consent, GTM and existing CTA/lead instrumentation match V43 behavior.

SEO acceptance checks

Every new page owns its approved diagnostic intent; excluded queries are not promoted into title/H1/primary headings.
Hub functions as a curated knowledge library, not a chronological wall of cards.
Every article remains directly discoverable without JavaScript or search.
Inbound links are contextual; no full-mesh link network is created among all 10 new pages.
AI Search cluster, Shopify cluster, indexing cluster and Technical SEO expert content remain intact and are not displaced by the new audit pages.
Turkish terminology follows the query-map rules: official GSC status wording where exact-status intent exists, natural professional sector terms elsewhere.

1. Confirm the latest production package. If newer than V43, diff/merge; do not overwrite newer approved work.

2. Convert the 10 supplied Turkish PNGs to the exact 1200×630 WebP filenames.

3. Create 10 `/tr/blog/<slug>/index.html` pages by adapting the actual current Turkish article template; insert approved copy, metadata, schema, images, breadcrumbs, links, FAQs, related cards and CTAs.

4. Implement the 30 mapped contextual inbound links from existing Turkish content.

5. Redesign /tr/blog/ with compact hero, search, six chips, featured/recent/9-card/compact-link hierarchy and 3-card CTA band.

6. Populate the hub library with all 30 Turkish articles and update CollectionPage/ItemList schema.

7. If EN equivalents are released in the same build, add reciprocal en/tr/x-default and direct language-switch links for all 10 pairs. If not, omit dead hreflang targets until EN pages are live.

8. Update sitemap.xml and site inventories without removing existing URLs.

9. Run full-site broken-link, canonical, hreflang, schema, image, metadata, H1, sitemap, route, analytics/consent and no-JS QA.

10. Run desktop/tablet/mobile visual QA and hub search/filter regression.

11. Only after all QA passes: version final production folder/ZIP according to active project version and hand off to normal commit/push/merge/deploy workflow.

Sık Sorulan Sorular

PageSpeed 100 hedeflemeli miyim?

Hayır. Amaç gerçek kullanıcı performansını ve başarısız metriği iyileştirmektir; kusursuz laboratuvar skoru garantisi değildir.

Saha verisi neden Lighthouse'tan farklı?

Field data farklı cihaz ve ağlardaki gerçek kullanıcılardan gelir; Lighthouse kontrollü lab testidir. Koşullar farklı olduğu için sonuçlar da farklı olabilir.

Core Web Vitals saha verisi ne kadar sürede değişir?

Field metrics hareketli gerçek kullanıcı verisine dayanır ve anında güncellenmez. Lab düzeltmesini hemen doğrulayın, field sonucu zaman içinde izleyin.