Anında sayfada gezinme için Chrome'da sayfaları önceden oluştur

Barry Pollard

Yayınlanma tarihi: 2 Aralık 2022, Son güncelleme tarihi: 29 Ekim 2026

Chrome ekibi, kullanıcının gelecekte gitme olasılığı yüksek olan sayfaların tam önceden işleme özelliğini geri getirdi.

Önceden işleme özelliğinin kısa geçmişi

Chrome geçmişte <link rel="prerender" href="/next-page"> kaynak ipucunu destekliyordu ancak bu ipucu Chrome dışında yaygın olarak desteklenmiyordu ve çok açıklayıcı bir API değildi.

rel=prerender bağlantı ipucunu kullanan bu eski önceden işleme yöntemi, NoState Prefetch lehine kullanımdan kaldırıldı. NoState Prefetch, gelecekteki sayfanın ihtiyaç duyduğu kaynakları getirir ancak sayfayı tam olarak önceden işlemez veya JavaScript'i yürütmez. NoState Prefetch, kaynak yüklemeyi iyileştirerek sayfa performansını artırmaya yardımcı olur ancak tam bir önceden işleme gibi anında sayfa yükleme sağlamaz.

Chrome ekibi, tam önceden işlemeyi Chrome'a yeniden ekledi. Mevcut kullanımla ilgili sorunları önlemek ve gelecekte önceden işlemenin kapsamını genişletmek için bu yeni önceden işleme mekanizması, <link rel="prerender"...> söz dizimini kullanmayacaktır. Bu söz dizimi, NoState Prefetch için kullanılmaya devam edecek ve gelecekte bir noktada kullanımdan kaldırılacaktır.

Sayfalar nasıl önceden işlenir?

Bir sayfa, gezinmeyi hızlandırmayı amaçlayan dört yöntemden biriyle önceden oluşturulabilir:

1. Chrome adres çubuğuna ("çok amaçlı adres çubuğu" olarak da bilinir) bir URL yazdığınızda Chrome, önceki tarama geçmişinize dayanarak o sayfayı ziyaret edeceğinizden emin olursa sayfayı sizin için otomatik olarak önceden işleyebilir.
2. Yer işaretleri çubuğunu kullandığınızda Chrome, işaretçiyi yer işareti düğmelerinden birinin üzerinde tuttuğunuzda sayfayı sizin için otomatik olarak önceden işleyebilir.
3. Chrome adres çubuğuna bir arama terimi yazdığınızda Chrome, arama motoru tarafından talimat verildiğinde arama sonuçları sayfasını otomatik olarak önceden işleyebilir.
4. Siteler, Chrome'a hangi sayfaların önceden işleneceğini programatik olarak bildirmek için Speculation Rules API'yi kullanabilir. Bu, <link rel="prerender"...> özelliğinin daha önce yaptığı işlemin yerini alır ve sitelerin, sayfadaki tahmin kurallarına göre bir sayfayı proaktif olarak önceden işlemesine olanak tanır. Bunlar sayfalarda statik olarak bulunabilir veya sayfa sahibinin uygun gördüğü şekilde JavaScript tarafından dinamik olarak eklenebilir.

Bu durumların her birinde önceden işleme, sayfa görünmez bir arka plan sekmesinde açılmış gibi davranır ve ardından ön plandaki sekme, önceden işlenmiş sayfayla değiştirilerek "etkinleştirilir". Bir sayfa, önceden işleme işlemi tamamen tamamlanmadan etkinleştirilirse mevcut durumu "ön plana alınmış" olur ve yüklenmeye devam eder. Bu da yine de iyi bir başlangıç yapabileceğiniz anlamına gelir.

Önceden işlenen sayfa gizli bir durumda açıldığından, müdahaleci davranışlara neden olan bir dizi API (ör. istemler) bu durumda etkinleştirilmez ve sayfa etkinleştirilene kadar ertelenir. Bunun henüz mümkün olmadığı az sayıda durumda önceden oluşturma işlemi iptal edilir. Chrome ekibi, önceden işleme iptal nedenlerini API olarak göstermek ve bu tür uç durumları tespit etmeyi kolaylaştırmak için Geliştirici Araçları özelliklerini geliştirmek üzerinde çalışıyor.

Önceden işlemenin etkisi

Önceden işleme, aşağıdaki videoda gösterildiği gibi sayfanın neredeyse anında yüklenmesini sağlar:

Örnek site zaten hızlı bir site olsa da önceden işlemenin kullanıcı deneyimini nasıl iyileştirdiğini görebilirsiniz. Bu nedenle, sitenin Core Web Vitals değerleri üzerinde de doğrudan bir etkisi olabilir. LCP neredeyse sıfıra iner, CLS azalır (yükleme CLS'si ilk görüntülemeden önce gerçekleştiği için) ve INP iyileşir (yükleme, kullanıcı etkileşimde bulunmadan önce tamamlanması gerektiği için).

Bir sayfa tamamen yüklenmeden önce etkinleştirilse bile sayfa yükleme işlemine erken başlamak, yükleme deneyimini iyileştirir. Önceden işleme devam ederken bir bağlantı etkinleştirildiğinde önceden işleme sayfası ana çerçeveye taşınır ve yüklenmeye devam eder.

Ancak önceden işleme, ek bellek ve ağ bant genişliği kullanır. Kullanıcı kaynaklarını harcayarak aşırı önceden işleme yapmamaya dikkat edin. Yalnızca sayfaya gidilme olasılığı yüksek olduğunda önceden işleme yapın.

Analizlerinizde gerçek performans etkisini nasıl ölçeceğiniz hakkında daha fazla bilgi için Performansı ölçme bölümüne bakın.

Chrome'un adres çubuğu tahminlerini görüntüleme

İlk kullanım alanında, Chrome'un URL'lerle ilgili tahminlerini chrome://predictors sayfasında görüntüleyebilirsiniz:

Yeşil çizgiler, önceden işlemeyi tetiklemek için yeterli güven olduğunu gösterir. Bu örnekte "s" yazıldığında makul bir güven (sarı) oluşur ancak "sh" yazdığınızda Chrome, neredeyse her zaman https://sheets.google.com adresine gittiğinizden emin olur.

Bu ekran görüntüsü, nispeten yeni bir Chrome yüklemesinde alınmış ve sıfır güven tahminleri filtrelenmiştir. Ancak kendi tahminlerinizi görüntülerseniz muhtemelen çok daha fazla giriş ve yeterince yüksek bir güven düzeyine ulaşmak için daha fazla karakter gerektiğini görürsünüz.

Bu tahmin araçları, adres çubuğunda önerilen seçenekleri de belirler:

Chrome, tahmin araçlarını yazdıklarınıza ve seçimlerinize göre sürekli olarak günceller.

• %30'dan yüksek bir güven düzeyi için (sarı renkte gösterilir) Chrome, proaktif olarak alan adına önceden bağlanır ancak sayfayı önceden işlemez.
• Güven düzeyi %50'den yüksekse (yeşil renkle gösterilir) Chrome, URL'yi önceden işler.

Speculation Rules API

Speculation Rules API önceden işleme seçeneği için web geliştiricileri, tarayıcıya hangi URL'lerin önceden işleneceğini bildirmek üzere sayfalarına JSON talimatları ekleyebilir.

URL listeleri

Spekülasyon kuralları, URL listelerine dayalı olabilir:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Belge kuralları

Spekülasyon kuralları, where söz dizimini kullanan "doküman kuralları" da olabilir. Bu, href seçicilere (URL Kalıbı API'ye dayalı) veya CSS seçicilere dayalı olarak dokümanda bulunan bağlantıları tahmin eder:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

İsteklilik

Tahminlerin ne zaman etkinleşeceğini belirtmek için eagerness ayarı kullanılır. Bu ayar özellikle belge kuralları için kullanışlıdır:

• conservative: Bu, işaretçi veya dokunma üzerine tahminde bulunur.
• moderate: Masaüstünde, işaretçiyi bir bağlantının üzerinde 200 milisaniye boyunca tutarsanız (veya daha önce gerçekleşirse pointerdown etkinliğinde ve hover etkinliğinin olmadığı mobil cihazlarda) bu işlem spekülasyonları gerçekleştirir. Mobil cihazlarda, Ağustos 2025'ten itibaren bunu karmaşık görüntü alanı sezgisel analizlerine dayalı olacak şekilde değiştirdik. Karmaşık görüntü alanı sezgisel yöntemleri, kullanıcı kaydırmayı bıraktıktan 500 ms sonra, önceki işaretçi aşağı hareketinden dikey mesafenin %30'u içindeki sabitleyiciler için tetiklenir.Bu sabitleyiciler, görüntü alanındaki en büyük sabitleyicinin en az 0,5 katı büyüklüktedir. Bu belgede açıklandığı şekilde.
• eager: Bu istek, daha önce immediate ile aynı şekilde davranıyordu ancak Chrome 143'ten itibaren değişti. Masaüstünde, fareyle bir bağlantının üzerine 10 milisaniye boyunca gelirseniz spekülasyonlar gerçekleştirilir. Mobil cihazlarda ise Ocak 2026'dan itibaren basit görüntü alanı sezgisel analizlerini temel alacak şekilde değişiklik yaptık. Basit görüntü alanı sezgisel yöntemleri, sabitleyici görüntü alanına girdikten 50 ms sonra tetiklenir.
• immediate: Bu, mümkün olan en kısa sürede, yani spekülasyon kuralları gözlemlenir gözlemlenmez spekülasyon yapmak için kullanılır.

list kuralları için varsayılan eagerness, immediate şeklindedir. eager, moderate ve conservative seçenekleri, list kurallarını kullanıcının etkileşimde bulunduğu URL'lerle sınırlamak için kullanılabilir. Ancak çoğu durumda, uygun bir where koşuluna sahip document kuralları daha uygun olabilir.

document kuralları için varsayılan eagerness, conservative şeklindedir. Bir doküman birçok URL'den oluşabileceğinden document kuralları için immediate kullanımı dikkatli bir şekilde yapılmalıdır (sonraki Chrome sınırları bölümüne de bakın).

Hangi eagerness ayarının kullanılacağı sitenize bağlıdır. Hafif ve statik bir site için daha istekli bir şekilde tahminde bulunmanın maliyeti düşük olabilir ve kullanıcılara fayda sağlayabilir. Daha karmaşık mimarilere ve daha ağır sayfa yüklerine sahip siteler, israfı sınırlamak için kullanıcılardan daha olumlu niyet sinyalleri alana kadar daha az tahminde bulunarak israfı azaltmayı tercih edebilir.

moderate seçeneği bir orta yoldur ve birçok site, işaretçiyi 200 milisaniye boyunca bağlantının üzerinde tuttuğunda veya pointerdown etkinliğinde bir bağlantıyı önceden işleyecek olan aşağıdaki spekülasyon kuralından yararlanabilir. Bu kural, spekülasyon kurallarının temel ancak güçlü bir uygulamasıdır:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Ön getirme

Tahmin kuralları, sayfaları tam olarak önceden işlemeden yalnızca önceden getirmek için de kullanılabilir. Bu, önceden işleme yolunda genellikle iyi bir ilk adım olabilir:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

Chrome ekibi, Speculation Rules API'ye prerender_until_script eklemek için de çalışıyor (bkz. uygulama hatası). Bu, önceden getirme ile önceden işleme arasında bir adım olur ve benzer şekilde kullanılır:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

NoState prefetch öğesine benzer şekilde bu, hem HTML belgesini hem de bu HTML'de bulunan alt kaynakları önceden getirir. Ancak bununla kalmayıp sayfayı önceden işlemeye de başlar ve ilk komut dosyasıyla karşılaşıldığında durur.

Bu, JavaScript içermeyen veya yalnızca altbilgide JavaScript içeren sayfaların neredeyse tamamen önceden işlenebileceği anlamına gelir. <head> içinde komut dosyaları bulunan sayfalar önceden işlenemez ancak alt kaynak getirme özelliğinden yararlanmaya devam eder.

Bu sayede, JavaScript yürütülmesinden kaynaklanan istenmeyen yan etki riskleri önlenir ancak yalnızca prefetch'e kıyasla çok daha büyük bir performans artışı elde edilir.

Chrome sınırları

Chrome, Speculation Rules API'nin aşırı kullanımını önlemek için sınırlamalar uygular:

Kullanıcı etkileşimine bağlı olan eager, moderate ve conservative ayarları, ilk giren ilk çıkar (FIFO) mantığıyla çalışır: Sınıra ulaşıldıktan sonra yeni bir spekülasyon, en eski spekülasyonun iptal edilmesine ve belleği korumak için yeni spekülasyonla değiştirilmesine neden olur.

İptal edilen bir spekülasyon tekrar tetiklenebilir (ör. fareyle ilgili bağlantının üzerine tekrar gelerek). Bu durumda ilgili URL yeniden spekülasyona tabi tutulur ve en eski spekülasyon kaldırılır. Bu durumda, önceki spekülasyon, söz konusu URL için HTTP önbelleğindeki önbelleğe alınabilir tüm kaynakları önbelleğe alır. Bu nedenle, daha sonraki bir spekülasyonun maliyeti daha düşük olur. Bu nedenle, sınır varsayılan olarak 2 gibi mütevazı bir eşiğe ayarlanmıştır. Mobil cihazlarda "fareyle üzerine gelme" işlemi olmadığından, alternatif mobil görüntü alanı buluşsal yöntemleri daha az doğru olduğundan ve önceden getirme işlemi önceden işlemeye göre daha az maliyetli olduğundan mobil cihazlarda önceden getirme için daha yüksek bir eşik (6) kullanırız (mobil cihazlarda önceden işleme için 2 sınırını koruruz).

Statik liste kuralları bir kullanıcı işlemiyle tetiklenmez. Bu nedenle, tarayıcının hangi kurallara ne zaman ihtiyaç duyulduğunu bilmesi mümkün olmadığından daha yüksek bir sınıra sahiptir.

Chrome, daha az hassas bir buluşsal yöntem olduğu için eager ve moderate için mobil cihazlarda sınırı en azından önceden getirme için 5'e çıkarmayı da düşünüyor. eager kullanan geliştiriciler, görüntü alanında birden fazla bağlantı olduğunda ilk iki bağlantıdan biri olarak seçilmese bile tahminde bulunabilmek için conservative kurallarını da kullanmayı düşünebilir.

immediate sınırı da dinamiktir. Bu nedenle, bir list URL komut dosyası öğesinin kaldırılması, kaldırılan spekülasyonları iptal ederek kapasite oluşturur.

Chrome, aşağıdakiler de dahil olmak üzere belirli koşullarda tahmini yüklemelerin kullanılmasını da engeller:

• Save-Data.
• Etkinleştirildiğinde ve pil seviyesi düşük olduğunda Enerji Tasarrufu.
• Bellek kısıtlamaları.
• "Sayfaları önceden yükle" ayarı kapalı olduğunda (uBlock Origin gibi Chrome uzantıları tarafından da açıkça kapatılır).
• Arka plan sekmelerinde açılan sayfalar.

Chrome, önceden oluşturulmuş sayfalardaki çapraz kaynak iframe'leri de etkinleştirilene kadar oluşturmaz.

Tüm bu koşullar, kullanıcılara zarar verebilecek aşırı spekülasyonun etkisini azaltmayı amaçlar.

Bir sayfaya spekülasyon kuralları ekleme

Tahmin kuralları, sayfanın HTML'sine statik olarak dahil edilebilir veya JavaScript tarafından sayfaya dinamik olarak eklenebilir:

• Statik olarak dahil edilen spekülasyon kuralları: Örneğin, bir haber sitesi veya blog, kullanıcıların büyük bir kısmı için genellikle bir sonraki gezinme işlemi buysa en yeni makaleyi önceden oluşturabilir. Alternatif olarak, kullanıcılar bağlantılarla etkileşimde bulunurken spekülasyon yapmak için moderate veya conservative içeren belge kuralları kullanılabilir.
• Dinamik olarak eklenen spekülasyon kuralları: Bu, uygulama mantığına dayalı, kullanıcıya göre kişiselleştirilmiş veya diğer sezgisel yöntemlere dayalı olabilir.

Bir bağlantının üzerine gelme veya bağlantıyı tıklama gibi işlemlere dayalı dinamik eklemeyi tercih edenlerin (geçmişte birçok kitaplığın <link rel=prefetch> ile yaptığı gibi) belge kurallarına bakması önerilir. Bu kurallar, tarayıcının kullanım alanlarınızın çoğunu işlemesine olanak tanır.

Tahmin kuralları, ana çerçevedeki <head> veya <body> öğesine eklenebilir. Alt çerçevelerdeki tahmin kuralları uygulanmaz ve önceden işlenmiş sayfalardaki tahmin kuralları yalnızca ilgili sayfa etkinleştirildiğinde uygulanır.

Speculation-Rules HTTP üstbilgisi

Tahmin kuralları, doğrudan belgenin HTML'sine eklenmek yerine Speculation-Rules HTTP üstbilgisi kullanılarak da yayınlanabilir. Bu sayede, CDN'ler doküman içeriklerini değiştirmeye gerek kalmadan daha kolay dağıtım yapabilir.

Speculation-Rules HTTP üstbilgisi, dokümanla birlikte döndürülür ve spekülasyon kurallarını içeren bir JSON dosyasının konumunu gösterir:

Speculation-Rules: "/speculationrules.json"

Bu kaynak, doğru MIME türünü kullanmalı ve çapraz kaynaksa CORS kontrolünden geçmelidir.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Göreceli URL'ler kullanmak istiyorsanız spekülasyon kurallarınıza "relative_to": "document" anahtarını ekleyebilirsiniz. Aksi takdirde, göreceli URL'ler, spekülasyon kuralları JSON dosyasının URL'sine göre belirlenir. Bu, özellikle aynı kaynaklı bağlantıların bir kısmını veya tamamını seçmeniz gerektiğinde yararlı olabilir.

Spekülasyon kuralları etiket alanı

Tahmin kuralları JSON söz dizimine, bir kural kümesindeki tüm tahmin kuralları için genel düzeyde "etiketler" eklemek de mümkündür:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Alternatif olarak, tek tek kural düzeyinde:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Bu etiket daha sonra Sec-Speculation-Tags HTTP üstbilgisine yansıtılır. Bu üstbilgi, sunucudaki spekülasyon kurallarını filtrelemek için kullanılabilir. Tahmin birden fazla kural kapsamındaysa Sec-Speculation-Tags HTTP üstbilgisi, aşağıdaki örnekte gösterildiği gibi birden fazla etiket içerebilir:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Bazı CDN'ler, spekülasyon kurallarını otomatik olarak ekler ancak bu özelliğin kaynak sunucu kullanımını artırmasını önlemek için uç önbelleğe alınmamış sayfalarla ilgili spekülasyonları engeller. Etiketler, varsayılan kural grubu tarafından başlatılan spekülasyonları tanımlamalarına olanak tanır ancak site tarafından eklenen kuralların kaynağa geçmesine izin verir.

Kural grubu etiketleri Chrome Geliştirici Araçları'nda da gösterilir.

Spekülasyon kuralları target_hint alanı

Tahmin kuralları, sayfanın önceden işlenmiş içeriğin nerede etkinleştirilmesini beklediğini gösteren geçerli bir tarama bağlamı adı veya anahtar kelime içeren bir target_hint alanı da içerebilir:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Bu ipucu, önceden işleme tahminlerinin target="_blank" bağlantıları için işlenmesine olanak tanır:

<a target="_blank" href="next.html">Open this link in a new tab</a>

Şu anda Chrome'da yalnızca "target_hint": "_blank" ve "target_hint": "_self" (belirtilmemişse varsayılan) desteklenmektedir ve yalnızca önceden işleme için desteklenmektedir. Önceden getirme desteklenmez.

target_hint yalnızca urls spekülasyon kuralları için gereklidir. Doküman kuralları için target, bağlantının kendisinden bilinir.

Spekülasyon kuralları ve SPA'lar

Tahmin kuralları yalnızca tarayıcı tarafından yönetilen tam sayfa gezinmeler için desteklenir. Tek Sayfalı Uygulamalar (SPA) veya uygulama kabuğu sayfaları için desteklenmez. Bu mimariler, belge getirme işlemlerini kullanmaz. Bunun yerine, verilerin veya sayfaların API ya da kısmi getirme işlemlerini yapar. Bunlar daha sonra işlenir ve mevcut sayfada sunulur. "Dinamik sayfa geçişleri" için gereken veriler, uygulama tarafından spekülasyon kuralları dışında önceden getirilebilir ancak önceden oluşturulamaz.

Tahmin kuralları, uygulamanın kendisini önceki bir sayfadan önceden işlemek için kullanılabilir. Bu, bazı tek sayfalık uygulamaların sahip olduğu ek ilk yükleme maliyetlerinin bir kısmını dengelemeye yardımcı olabilir. Ancak uygulama içindeki rota değişiklikleri önceden işlenemez.

Spekülasyon kurallarında hata ayıklama

Bu yeni API'yi görüntülemeye ve hata ayıklamaya yardımcı olacak yeni Chrome Geliştirici Araçları özellikleri için spekülasyon kurallarında hata ayıklama ile ilgili özel yayına bakın.

Birden fazla spekülasyon kuralı

Aynı sayfaya birden fazla spekülasyon kuralı da eklenebilir ve bunlar mevcut kurallara eklenir. Bu nedenle, aşağıdaki farklı yöntemlerin tümü hem one.html hem de two.html önceden işleme ile sonuçlanır:

URL listesi:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Birden fazla speculationrules komut dosyası:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Tek bir speculationrules grubunda birden fazla liste

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

No-Vary-Search desteği

Bir sayfa önceden getirilirken veya önceden işlenirken belirli URL parametreleri (teknik olarak arama parametreleri olarak bilinir) sunucu tarafından yayınlanan sayfa için önemsiz olabilir ve yalnızca istemci tarafı JavaScript tarafından kullanılabilir.

Örneğin, UTM parametreleri Google Analytics tarafından kampanya ölçümü için kullanılır ancak genellikle sunucudan farklı sayfaların yayınlanmasına neden olmaz. Bu, page1.html?utm_content=123 ve page1.html?utm_content=456 ifadelerinin sunucudan aynı sayfayı yayınlayacağı ve böylece aynı sayfanın önbellekten yeniden kullanılabileceği anlamına gelir.

Benzer şekilde, uygulamalar yalnızca istemci tarafında işlenen diğer URL parametrelerini kullanabilir.

No-Vary-Search teklifi, sunucunun, sunulan kaynakta farklılığa neden olmayan parametreleri belirtmesine olanak tanır. Bu sayede tarayıcı, bir dokümanın yalnızca bu parametrelerle farklılık gösteren, daha önce önbelleğe alınmış sürümlerini yeniden kullanabilir. Bu, hem önceden getirme hem de önceden işleme için gezinme tahminleri amacıyla Chrome'da (ve Chromium tabanlı tarayıcılarda) desteklenir.

Tahmin kuralları, No-Vary-Search HTTP üstbilgisinin döndürülmesinin beklendiği yeri belirtmek için expects_no_vary_search kullanımını destekler. Bu sayede, yanıtlar görülmeden önce gereksiz indirmeleri daha da önleyebilirsiniz.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

Bu örnekte, /products ilk sayfa HTML'si hem 123 hem de 124 ürün kimlikleri için aynıdır. Ancak sayfa içerikleri, id arama parametresini kullanarak ürün verilerini getirmek için JavaScript kullanan istemci tarafı oluşturmaya göre farklılık gösterir. Bu nedenle, bu URL'yi önceden getiririz. Bu URL, sayfanın herhangi bir id arama parametresi için kullanılabileceğini gösteren bir No-Vary-Search HTTP üstbilgisi döndürmelidir.

Ancak kullanıcı, önceden getirme işlemi tamamlanmadan önce bağlantılardan birini tıklarsa tarayıcı /products sayfasını almamış olabilir. Bu durumda tarayıcı, No-Vary-Search HTTP üstbilgisini içerip içermeyeceğini bilmez. Ardından tarayıcı, bağlantıyı tekrar getirme veya No-Vary-Search HTTP üstbilgisi içerip içermediğini görmek için önceden getirmenin tamamlanmasını bekleme seçeneklerinden birini tercih eder. expects_no_vary_search ayarı, tarayıcının sayfa yanıtının bir No-Vary-Search HTTP üstbilgisi içermesinin beklendiğini bilmesini ve bu önceden getirmenin tamamlanmasını beklemesini sağlar.

expects_no_vary_search parametresine, aralarında boşluk bırakarak birden fazla parametre de ekleyebilirsiniz (No-Vary-Search, HTTP yapılandırılmış üstbilgisi olduğundan):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Spekülasyon kuralları kısıtlamaları ve gelecekteki geliştirmeler

Tahmin kuralları, aynı sekmede açılan sayfalarla sınırlıdır ancak bu kısıtlamayı azaltmak için çalışıyoruz.

Varsayılan olarak, önceden işleme aynı kaynaklı sayfalarla sınırlıdır. Aynı sitenin çapraz kaynak sayfalarının (ör. https://a.example.com, https://b.example.com üzerindeki bir sayfayı önceden işleyebilir) önceden işlenmesi etkinleştirilebilir. Bu özelliği kullanmak için tahmini sayfanın (bu örnekte https://b.example.com) bir Supports-Loading-Mode: credentialed-prerender HTTP üstbilgisi ekleyerek etkinleştirilmesi gerekir. Aksi takdirde Chrome, tahmini iptal eder.

Gelecekteki sürümlerde, önceden işlenen sayfa için çerezler mevcut olmadığı ve önceden işlenen sayfa benzer bir Supports-Loading-Mode: uncredentialed-prerender HTTP üstbilgisiyle etkinleştirildiği sürece aynı sitede olmayan, çapraz kaynak sayfalar için önceden işlemeye de izin verilebilir.

Tahmin kuralları, çapraz kaynak önceden getirme işlemlerini zaten destekler. Aynı site, çapraz kaynak önceden getirme işlemleri için herhangi bir kısıtlama yoktur. Farklı sitelerdeki çapraz kaynak önceden getirme işlemleri yalnızca çapraz kaynak alan için çerezler mevcut olmadığında desteklenir. Kullanıcının daha önce o siteyi ziyaret etmesinden kaynaklanan çerezler varsa tahmin kullanılmaz ve Geliştirici Araçları'nda hata gösterilir.

Mevcut sınırlamalar göz önüne alındığında, mümkün olduğunda hem dahili hem de harici bağlantılar için kullanıcı deneyimini iyileştirebilecek bir yöntem, aynı kaynak URL'leri önceden işlemek ve çapraz kaynak URL'leri önceden getirmeye çalışmaktır:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }],
    "prefetch": [{
      "where": { "not": { "href_matches": "/*" } },
      "eagerness": "moderate"
    }]
  }
</script>

Çapraz kaynak bağlantıları için varsayılan olarak çapraz kaynak spekülasyonlarını önleme kısıtlaması güvenlik açısından gereklidir. Çerez göndermeyecek ancak önceden getirme işlemini deneyecek olan çapraz kaynak hedefler için <link rel="prefetch">'e göre bir iyileştirmedir. Bu durum, yeniden gönderilmesi gereken boşa harcanmış bir önceden getirme işlemine veya daha da kötüsü yanlış sayfanın yüklenmesine neden olur.

Speculation Rules API desteğini algılama

Standart HTML kontrolleriyle Spekülasyon Kuralları API'si desteğini algılayabilirsiniz:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

JavaScript aracılığıyla dinamik olarak spekülasyon kuralları ekleme

JavaScript kullanarak prerender spekülasyon kuralı eklemeyle ilgili bir örneği aşağıda bulabilirsiniz:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

JavaScript ekleme özelliğini kullanan Speculation Rules API önceden işleme özelliğinin demosunu bu önceden işleme demo sayfasında görüntüleyebilirsiniz.

innerHTML kullanarak doğrudan DOM'a <script type = "speculationrules"> öğesi eklemek, güvenlik nedeniyle spekülasyon kurallarını kaydetmez. Bu nedenle, daha önce gösterildiği gibi eklenmelidir. Ancak innerHTML kullanılarak dinamik olarak eklenen ve yeni bağlantılar içeren içerikler, sayfadaki mevcut kurallar tarafından alınır.

Benzer şekilde, <script type = "speculationrules"> öğesini eklemek için Chrome Geliştirici Araçları'ndaki Öğeler panelini doğrudan düzenlemek, spekülasyon kurallarını kaydetmez. Bunun yerine, kuralları eklemek için bu öğeyi DOM'a dinamik olarak ekleyecek komut dosyasının Konsol'dan çalıştırılması gerekir.

Etiket yöneticisi aracılığıyla spekülasyon kuralları ekleme

Google Etiket Yöneticisi (GTM) gibi bir etiket yöneticisi kullanarak spekülasyon kuralları eklemek için, daha önce belirtilen nedenlerle <script type = "speculationrules"> öğesini doğrudan GTM üzerinden eklemek yerine JavaScript aracılığıyla eklemeniz gerekir:

GTM, const'i desteklemediğinden bu örnekte var kullanılmıştır.

Tahmin kurallarını iptal etme

Spekülasyon kuralları kaldırıldığında önceden işleme iptal edilir. Ancak bu gerçekleştiğinde, önceden işlemeyi başlatmak için kaynaklar muhtemelen harcanmış olacaktır. Bu nedenle, önceden işlemeyi iptal etme olasılığı varsa önceden işleme yapmamanız önerilir. Öte yandan, önbelleğe alınan kaynaklar yeniden kullanılabilir. Bu nedenle, iptaller tamamen boşa gitmeyebilir ve gelecekteki tahminlere ve gezinmelere fayda sağlayabilir.

Tahminler, prefetchCache ve prerenderCache yönergeleriyle birlikte Clear-Site-Data HTTP üstbilgisi kullanılarak da iptal edilebilir.

Bu, sunucuda durum değiştiğinde yararlı olabilir. Örneğin, "sepete ekle" API'si veya giriş ya da çıkış API'si çağrılırken.

İdeal olarak bu durum güncellemeleri, Broadcast Channel API gibi API'ler kullanılarak önceden işlenmiş sayfalara yayılır. Ancak bunun mümkün olmadığı durumlarda veya bu tür bir mantık uygulanana kadar spekülasyonu iptal etmek daha kolay olabilir.

Tahmin kuralları ve İçerik Güvenliği Politikası

Spekülasyon kuralları, yalnızca JSON içermelerine rağmen <script> öğesi kullandığından, site bunu kullanıyorsa (karma veya tek seferlik rastgele sayı kullanarak) script-src Content-Security-Policy'ye dahil edilmeleri gerekir.

script-src öğesine yeni bir inline-speculation-rules eklenebilir. Böylece, karma veya tek seferlik rastgele sayı içeren komut dosyalarından eklenen <script type="speculationrules"> öğeleri desteklenebilir. Bu, ilk HTML'de bulunan kuralları desteklemez. Bu nedenle, katı bir CSP kullanan siteler için kuralların JavaScript tarafından eklenmesi gerekir.

Önceden işlemeyi algılama ve devre dışı bırakma

Önceden işleme, hızlı (genellikle anında) sayfa oluşturmaya olanak tanıdığı için kullanıcılar açısından genellikle olumlu bir deneyimdir. Önceden işlenen sayfalar, başka türlü elde edilmesi zor olabilecek daha iyi bir kullanıcı deneyimi sağladığından bu durum hem kullanıcı hem de site sahibi için faydalıdır.

Ancak sayfaların önceden işlenmesini istemediğiniz durumlar olabilir. Örneğin, sayfaların durumu ilk isteğe veya sayfada yürütülen JavaScript'e göre değiştiğinde.

Chrome'da önceden işlemeyi etkinleştirme ve devre dışı bırakma

Önceden işleme, yalnızca chrome://settings/performance/ bölümünde "Sayfaları önceden yükle" ayarı etkin olan Chrome kullanıcıları için etkinleştirilir. Ayrıca, önceden işleme özelliği düşük bellekli cihazlarda veya işletim sistemi Veri Tasarrufu ya da Enerji Tasarrufu modlarındayken de devre dışı bırakılır. Chrome sınırları bölümüne bakın.

Sunucu tarafında önceden işlemeyi algılama ve devre dışı bırakma

Önceden işlenen sayfalar Sec-Purpose HTTP üstbilgisiyle gönderilir:

Sec-Purpose: prefetch;prerender

Speculation Rules API kullanılarak önceden getirilen sayfalarda bu üstbilgi yalnızca prefetch olarak ayarlanır:

Sec-Purpose: prefetch

Sunucular, tahmini istekleri günlüğe kaydetmek, farklı içerik döndürmek veya önceden işlemenin gerçekleşmesini önlemek için bu başlığa göre yanıt verebilir. Başarılı olmayan bir nihai yanıt kodu döndürülürse (yani yönlendirmelerden sonra 200-299 aralığında değilse) sayfa önceden işlenmez ve önceden getirilen sayfalar silinir. 204 ve 205 yanıtlarının önceden işleme için geçerli olmadığını ancak önceden getirme için geçerli olduğunu da unutmayın.

Belirli bir sayfanın önceden işlenmesini istemiyorsanız 2XX olmayan bir yanıt kodu (ör. 503) döndürmek, bunun gerçekleşmemesini sağlamanın en iyi yoludur. Ancak en iyi deneyimi sunmak için önceden işlemeye izin vermeniz, ancak yalnızca sayfa gerçekten görüntülendiğinde gerçekleşmesi gereken işlemleri JavaScript kullanarak geciktirmeniz önerilir.

JavaScript'te önceden işlemeyi algılama

Sayfa önceden işlenirken document.prerendering API'si true değerini döndürür. Bu, sayfalar tarafından, önceden işleme sırasında belirli etkinlikleri sayfa gerçekten etkinleştirilene kadar engellemek veya geciktirmek için kullanılabilir.

Önceden işlenmiş bir doküman etkinleştirildiğinde PerformanceNavigationTiming öğesinin activationStart değeri de önceden işlemenin başlatılması ile dokümanın etkinleştirilmesi arasındaki süreyi temsil eden sıfır olmayan bir süreye ayarlanır.

Önceden işleme ve önceden işlenmiş sayfaları kontrol etmek için aşağıdaki gibi bir işlev kullanabilirsiniz:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

Bir sayfanın önceden işlenip işlenmediğini (tamamen veya kısmen) görmenin en kolay yolu, sayfa etkinleştirildikten sonra Geliştirici Araçları'nı açıp konsola performance.getEntriesByType('navigation')[0].activationStart yazmaktır. Sıfır dışında bir değer döndürülürse sayfanın önceden işlendiğini anlarsınız:

Sayfa, sayfayı görüntüleyen kullanıcı tarafından etkinleştirildiğinde document üzerinde prerenderingchange etkinliği gönderilir. Bu etkinlik, daha önce sayfa yüklenirken varsayılan olarak başlatılan ancak sayfa kullanıcı tarafından gerçekten görüntülenene kadar geciktirmek istediğiniz etkinlikleri etkinleştirmek için kullanılabilir.

Ön uç JavaScript, bu API'leri kullanarak önceden işlenmiş sayfaları algılayabilir ve bunlara uygun şekilde işlem yapabilir.

Analizlere etkisi

Analizler, web sitesi kullanımını ölçmek için kullanılır. Örneğin, sayfa görüntülemelerini ve etkinlikleri ölçmek için Google Analytics kullanılır. Alternatif olarak, Gerçek Kullanıcı İzleme (RUM) özelliğini kullanarak sayfaların performans metriklerini ölçebilirsiniz.

Sayfalar yalnızca kullanıcının sayfayı yükleme olasılığı yüksek olduğunda önceden işlenmelidir. Bu nedenle, Chrome adres çubuğu önceden işleme seçenekleri yalnızca bu kadar yüksek bir olasılık olduğunda (%80'den fazla) gerçekleşir.

Ancak özellikle Speculation Rules API kullanılırken önceden işlenen sayfalar analizleri etkileyebilir ve site sahiplerinin, önceden işlenen sayfalar için analizleri yalnızca etkinleştirme sırasında etkinleştirmek üzere ek kod eklemesi gerekebilir. Çünkü tüm analiz sağlayıcılar bunu varsayılan olarak yapmayabilir.

Bu, bir doküman önceden işleniyorsa prerenderingchange etkinliğini bekleyen veya şu anda işleniyorsa hemen çözümlenen bir Promise kullanılarak yapılabilir:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Alternatif bir yaklaşım, analiz etkinliklerini sayfa ilk kez görünür hale gelene kadar geciktirmektir. Bu, hem önceden işleme durumunu hem de sekmelerin arka planda açıldığı durumları (örneğin, sağ tıklayıp yeni sekmede açarak) kapsar:

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Bu durum, analiz ve benzeri kullanım alanları için mantıklı olsa da diğer durumlarda daha fazla içerik yüklenmesini isteyebilir ve bu nedenle, önceden işlenen sayfaları özel olarak hedeflemek için document.prerendering ve prerenderingchange kullanmak isteyebilirsiniz.

Önceden işleme sırasında diğer içerikleri bekletme

Daha önce ele alınan API'ler, önceden işleme aşamasında diğer içerikleri bekletmek için kullanılabilir. Bunlar, önceden işleme aşamasında çalıştırılmasını istemediğiniz JavaScript'in belirli bölümleri veya komut dosyası öğelerinin tamamı olabilir.

Örneğin, şu komut dosyasını ele alalım:

<script src="https://example.com/app/script.js" async></script>

Bunu, yalnızca önceki whenActivated işlevine göre ekleme yapan, dinamik olarak eklenmiş bir komut dosyası öğesiyle değiştirebilirsiniz:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Bu, analiz içeren farklı komut dosyalarını engellemek veya bir ziyaret süresi boyunca değişebilen duruma ya da diğer değişkenlere göre içerik oluşturmak için yararlı olabilir. Örneğin, en güncel bilgilerin sunulmasını sağlamak için öneriler, giriş durumu veya alışveriş sepeti simgeleri geri çekilebilir.

Bu durumun önceden işleme kullanıldığında daha sık gerçekleşme olasılığı daha yüksek olsa da bu koşullar, daha önce bahsedilen arka plan sekmelerinde yüklenen sayfalar için de geçerlidir (bu nedenle whenActivated yerine whenFirstVisible işlevi kullanılabilir).

Çoğu durumda, genel visibilitychange değişikliklerinde de durumun kontrol edilmesi idealdir. Örneğin, arka planda olan bir sayfaya geri dönerken alışveriş sepeti sayaçları, sepetteki en son ürün sayısıyla güncellenmelidir. Bu nedenle, bu sorun önceden işlemeye özgü değildir. Önceden işleme, yalnızca mevcut bir sorunu daha belirgin hale getirir.

Chrome, komut dosyalarını veya işlevleri manuel olarak sarmalama ihtiyacını azaltmak için daha önce de belirtildiği gibi belirli API'leri engeller ve üçüncü taraf iframe'leri oluşturmaz. Bu nedenle, yalnızca bunun üzerindeki içeriğin manuel olarak engellenmesi gerekir.

Performansı ölçmek

Performans metriklerini ölçmek için analizler, bunları tarayıcı API'lerinin raporlayacağı sayfa yükleme süresi yerine etkinleştirme süresine göre ölçmenin daha iyi olup olmadığını dikkate almalıdır.

Chrome tarafından Chrome Kullanıcı Deneyimi Raporu aracılığıyla ölçülen Core Web Vitals, kullanıcı deneyimini ölçmeyi amaçlar. Bu nedenle, bunlar etkinleştirme zamanına göre ölçülür. Bu genellikle 0 saniyelik bir LCP ile sonuçlanır. Bu da Core Web Vitals'ı iyileştirmenin harika bir yolu olduğunu gösterir.

3.1.0 sürümünden itibaren web-vitals kitaplığı, önceden oluşturulmuş gezinmeleri Chrome'un Core Web Vitals'ı ölçtüğü şekilde işleyecek şekilde güncellendi. Bu sürüm, sayfa tamamen veya kısmen önceden işlenmişse Metric.navigationType özelliğindeki bu metrikler için önceden işlenmiş gezinmeleri de işaretler.

Önceden işlemeleri ölçme

Bir sayfanın önceden işlenip işlenmediği, PerformanceNavigationTiming için sıfır olmayan bir activationStart girişiyle görülebilir. Bu, daha sonra bir özel boyut kullanılarak veya sayfa görüntülemeleri günlüğe kaydedilirken benzer bir şekilde günlüğe kaydedilebilir. Örneğin, pagePrerendered işlevi daha önce açıklandığı şekilde kullanılabilir:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Bu sayede analizleriniz, diğer gezinme türlerine kıyasla kaç gezinmenin önceden işlendiğini gösterebilir. Ayrıca, performans metriklerini veya işletme metriklerini bu farklı gezinme türleriyle ilişkilendirebilirsiniz. Daha hızlı sayfalar, daha mutlu kullanıcılar anlamına gelir. Örnek olay incelemelerimizin gösterdiği gibi, bu durumun işletme ölçümleri üzerinde genellikle gerçek bir etkisi olabilir.

Anında gezinme için sayfaları önceden işlemenin işletme üzerindeki etkisini ölçerken, daha fazla gezinmenin önceden işlenmesine olanak tanımak için bu teknolojiyi kullanmaya daha fazla çaba harcamaya veya sayfaların neden önceden işlenmediğini araştırmaya değip değmeyeceğine karar verebilirsiniz.

İsabet oranlarını ölçme

Önceden işlendikten sonra ziyaret edilen sayfaların etkisini ölçmenin yanı sıra, önceden işlenen ve daha sonra ziyaret edilmeyen sayfaları ölçmek de önemlidir. Bu durum, çok fazla önceden işleme yaptığınız ve kullanıcının değerli kaynaklarını çok az fayda için kullandığınız anlamına gelebilir.

Bu, spekülasyon kuralları eklendiğinde (tarayıcının HTMLScriptElement.supports('speculationrules') kullanarak önceden işlemeyi desteklediği kontrol edildikten sonra) önceden işlemenin istendiğini belirtmek için bir analiz etkinliği tetiklenerek ölçülebilir. (Önceden işleme isteğinde bulunulması, önceden işlemenin başlatıldığı veya tamamlandığı anlamına gelmez. Daha önce de belirtildiği gibi, önceden işleme tarayıcıya bir ipucu verir ve tarayıcı; kullanıcı ayarlarına, mevcut bellek kullanımına veya diğer sezgisel yöntemlere göre sayfaları önceden işlememeyi seçebilir.)

Ardından, bu etkinliklerin sayısını gerçek önceden işleme sayfa görüntülemeleriyle karşılaştırabilirsiniz. Alternatif olarak, karşılaştırmayı kolaylaştıracaksa etkinleştirme sırasında başka bir etkinlik tetikleyebilirsiniz.

"Başarılı isabet oranı", bu iki rakam arasındaki farka bakılarak tahmin edilebilir. Sayfaları önceden işlemek için Speculation Rules API'yi kullandığınız sayfalarda, kullanıcıların kaynaklarını onlara yardımcı olmak için kullanmak ile gereksiz yere kullanmak arasındaki dengeyi korumak amacıyla kuralları uygun şekilde ayarlayarak yüksek bir isabet oranı elde edebilirsiniz.

Yalnızca tahmin kurallarınız nedeniyle değil, adres çubuğunun önceden işleme özelliği nedeniyle de önceden işleme yapılabileceğini unutmayın. Bunları ayırt etmek istiyorsanız document.referrer değerini kontrol edebilirsiniz (önceden işlenmiş adres çubuğu gezinmeleri de dahil olmak üzere adres çubuğu gezinmeleri için bu değer boş olur).

Önceden işleme yapılmayan sayfalara da bakmayı unutmayın. Bu durum, söz konusu sayfaların adres çubuğundan bile önceden işleme için uygun olmadığını gösterebilir. Bu durum, söz konusu performans iyileştirmesinden yararlanmadığınız anlamına gelebilir. Chrome ekibi, önceden işleme uygunluğunu test etmek için geri-ileri önbellek test aracına benzer ek araçlar eklemeyi ve önceden işlemenin neden başarısız olduğunu açıklayan bir API eklemeyi planlıyor.

Uzantılara etkisi

Uzantı yazarlarının önceden oluşturulmuş sayfalar için göz önünde bulundurması gerekebilecek bazı ek noktaları ayrıntılı olarak açıklayan Chrome Uzantıları: Anında Gezinme'yi desteklemek için API'yi genişletme başlıklı özel yayını inceleyin.

Geri bildirim

Önceden işleme, Chrome ekibi tarafından aktif olarak geliştirilmektedir ve Chrome 108 sürümünde sunulan özelliklerin kapsamını genişletmek için birçok plan vardır. GitHub deposu veya Issue Tracker ile ilgili her türlü geri bildirimi memnuniyetle karşılarız. Bu heyecan verici yeni API ile ilgili örnek olayları dinlemeyi ve paylaşmayı sabırsızlıkla bekliyoruz.

İlgili bağlantılar

• Spekülasyon Kuralları Codelab'i
• Spekülasyon kurallarında hata ayıklama
• NoState Prefetch ile tanışın
• Speculation Rules API spesifikasyonu
• Gezinme spekülasyonu GitHub deposu
• Chrome Uzantıları: Anında gezinmeyi desteklemek için API'yi genişletme

Onaylar

Küçük resim: Unsplash'te Marc-Olivier Jodoin