Speculation Rules API: Οδηγός 2026

Q: Ποια είναι η διαφορά μεταξύ Speculation Rules API και του παλιού <link rel="prefetch">;

Το <link rel="prefetch"> είναι per-URL και χρησιμοποιείται συνήθως για subresources του τρέχοντος document. Το Speculation Rules API είναι pattern-based (μπορεί να καλύψει όλα τα εσωτερικά links με έναν κανόνα), προσθέτει eagerness heuristics, υποστηρίζει πλήρες prerender και HTTP header deployment, και είναι η μόνη σύγχρονη λύση για prerendering. Το legacy rel="prerender" έχει καταργηθεί από τον Chrome από το 2023.

Ενημερώθηκε: 9 Ιουλίου 2026

Το Speculation Rules API είναι ένα declarative browser API που δηλώνει στον Chrome ποιες σελίδες να κάνει prefetch ή prerender πριν καν κλικάρει ο χρήστης, ώστε η επόμενη πλοήγηση να εμφανίζεται σχεδόν ακαριαία (LCP συχνά κάτω από 100 ms). Στην πράξη, βάζεις ένα <script type="speculationrules"> ή στέλνεις έναν Speculation-Rules HTTP header και ρυθμίζεις eagerness (immediate, eager, moderate, conservative). Ο οδηγός καλύπτει την έκδοση του API όπως στέκεται στον Chrome 144 του 2026. Ειλικρινά, όταν το δοκίμασα πρώτη φορά σε production e-shop, το αποτέλεσμα ήταν από τα λίγα browser features που σε κάνουν να μη πιστεύεις το DevTools panel.

Το prerender φορτώνει και εκτελεί ολόκληρη τη σελίδα σε αόρατο tab, ενώ το prefetch κατεβάζει μόνο το HTML document. Prefetch = χαμηλό ρίσκο, prerender = μεγάλο κέρδος αλλά χρειάζεται προσοχή σε analytics και stateful pages.
Το eagerness ελέγχει πότε τρέχει η speculation: immediate αμέσως, eager στα 10 ms hover, moderate στα 200 ms hover ή σε viewport heuristics, conservative στο mousedown/touchstart.
Ο Chrome επιτρέπει έως 50 prefetches και 10 prerenders για immediate/eager, αλλά μόνο 2+2 για moderate/conservative με FIFO αντικατάσταση.
Το νέο prerender_until_script στο Chrome 144 (Ιανουάριος 2026) φορτώνει HTML, CSS, εικόνες και fonts αλλά σταματά τη JavaScript στο πρώτο blocking script, οπότε τέλος τα διπλά analytics hits.
Ο Speculation-Rules HTTP header επιτρέπει deployment από CDN edge χωρίς να πειράξεις HTML. Ιδανικό για ISR και edge caching στρατηγικές.
Πραγματικά αποτελέσματα 2025-2026: Ray-Ban 4.69 s → 2.66 s LCP στο mobile με moderate prerender, Shopify 130-180 ms βελτίωση σε όλα τα paint metrics με conservative prefetch.

Τι είναι το Speculation Rules API;

Το Speculation Rules API είναι μια δηλωτική διεπαφή που επιτρέπει στη σελίδα να πει στον browser: «αυτές τις διευθύνσεις μπορεί ο χρήστης να επισκεφθεί μετά, ξεκίνα να τις προετοιμάζεις». Ο Chrome (και το Edge, από την ίδια Chromium βάση) υποστηρίζει δύο ενέργειες. Πρώτον, το prefetch, που φέρνει μόνο το HTML document της σελίδας-στόχου. Δεύτερον, το prerender, που πάει ένα βήμα παρακάτω: φορτώνει την πλήρη σελίδα, τρέχει τα scripts, και την κρατά σε in-memory cache σαν αόρατο tab. Όταν ο χρήστης κάνει κλικ, η πλοήγηση απλά «ενεργοποιεί» το ήδη φορτωμένο tab, οπότε το LCP εμφανίζεται σε λιγότερο από 100 ms στις περισσότερες περιπτώσεις.

Η μεγάλη διαφορά από τα παλιά resource hints (<link rel="prefetch">, <link rel="prerender">) είναι ότι το Speculation Rules API είναι rule-based. Αντί να δηλώνεις μία-μία URL, δηλώνεις pattern (π.χ. «όλα τα /product/* links στο viewport») και ο browser αποφασίζει πότε να speculate βάσει του eagerness. Επίσης, το legacy rel="prerender" έχει καταργηθεί εντελώς από τον Chrome από το 2023· η μοναδική σύγχρονη επιλογή είναι πλέον το Speculation Rules API. Στην εμπειρία μου από full-stack rollouts, αυτό αλλάζει τη λογική: δεν είναι πλέον «δώσε hint για μία σελίδα», είναι «δήλωσε πολιτική prefetch για όλο το site».

Prefetch vs prerender: πότε επιλέγεις ποιο

Το prefetch και το prerender λύνουν διαφορετικά προβλήματα και έχουν πολύ διαφορετικό κόστος. Το prefetch κατεβάζει μόνο το HTML (συνήθως 20–80 KB) και εκμεταλλεύεται τον HTTP cache. Είναι φθηνό, ασφαλές ακόμη και για μεγάλη λίστα URLs, και δεν εκτελεί κανένα JavaScript στην target σελίδα. Το prerender αντίθετα κάνει πλήρες page load με CSS, JS, εικόνες, font requests και εκτέλεση όλου του main-thread work. Μπορεί εύκολα να ξεπεράσει τα 2-3 MB δικτύου και αρκετά δευτερόλεπτα CPU. Το κέρδος είναι εκρηκτικό όταν χτυπάει, αλλά το κόστος όταν αστοχεί είναι σημαντικό.

Χαρακτηριστικό	Prefetch	Prerender
Τι φορτώνει	Μόνο HTML document	HTML + CSS + JS + subresources + εκτέλεση
Κόστος bandwidth	~20–80 KB	Συχνά 1–5 MB
Κόστος CPU	Ελάχιστο	Πλήρες page load
Επίδραση σε LCP επόμενης σελίδας	Μείωση TTFB κατά 200–500 ms	LCP συχνά <100 ms
Όριο Chrome (immediate)	50 concurrent	10 concurrent
Όριο Chrome (moderate/conservative)	2 concurrent (FIFO)	2 concurrent (FIFO)
Απαιτεί prerender-aware analytics	Όχι	Ναι
Ασφαλές για stateful pages	Συνήθως	Όχι χωρίς προσοχή

Ο κανόνας που ακολουθώ όταν στήνω τη στρατηγική είναι απλός. Κάνε broad prefetch για όλες τις σημαντικές σελίδες που είναι «διαβαστικές» (blog posts, product listings, article pages), και prerender στοχευμένα με moderate ή conservative eagerness μόνο για τα top-3 candidate links του τρέχοντος view. Αν δεν είσαι σίγουρος, ξεκίνα από prefetch· η αναβάθμιση σε prerender γίνεται εκ των υστέρων με άλλο rule χωρίς σπάσιμο.

Πώς λειτουργεί το eagerness setting

Το eagerness είναι το πιο σημαντικό tuning knob του API. Δεν αλλάζει ποιες URLs speculate, αλλά πότε. Έχει τέσσερα levels:

immediate: Η speculation ξεκινά τη στιγμή που ο browser βλέπει τους κανόνες. Χρησιμοποιείται σχεδόν αποκλειστικά με source: "list" για συγκεκριμένες URLs (π.χ. το επόμενο βήμα σε ένα wizard).
eager: Πριν τον Chrome 143 συμπεριφερόταν όπως το immediate. Από το 2026, σε desktop το eager τρέχει μετά από 10 ms hover πάνω σε link. Σε mobile βασίζεται σε viewport heuristics.
moderate: Speculation μετά από 200 ms hover πάνω σε link, ή στο pointerdown αν έρθει νωρίτερα. Σε mobile από τον Αύγουστο 2025, ο Chrome χρησιμοποιεί complex viewport heuristics: μετά 500 ms χωρίς scrolling, για anchors μέσα σε 30% της κάθετης απόστασης από το τελευταίο pointer down.
conservative: Speculation ξεκινά στο mousedown (desktop) ή touchstart (mobile). Το click event πυροδοτείται στο mouseup, οπότε κερδίζεις κάπου 80–200 ms. Φαινομενικά λίγο, αλλά αρκετό ώστε να «κρύψει» ένα σημαντικό μέρος του TTFB.

Το default για urls (list) rules είναι immediate· για where (document) rules είναι conservative. Στην πράξη, το moderate είναι το «sweet spot» για most sites. Αρκετά επιθετικό ώστε να προλαβαίνει τον χρήστη, αρκετά συντηρητικό ώστε να μη σπαταλάει bandwidth σε χρήστες που απλά scroll. Δες και το άρθρο για τη βελτιστοποίηση INP. Το prerendering βοηθά έμμεσα το INP επειδή μειώνει το main-thread work στο first interaction της νέας σελίδας.

Βασικό παράδειγμα υλοποίησης

Ξεκινάμε με το πιο συνηθισμένο pattern: prefetch για όλα τα εσωτερικά links, και prerender για τα top product links με moderate eagerness. Αυτό το snippet πηγαίνει στο <head> ή τέλος του <body>:

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/account/*" } },
          { "not": { "selector_matches": "[data-no-prefetch]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "source": "document",
      "where": { "selector_matches": ".product-card a" },
      "eagerness": "moderate"
    }
  ]
}
</script>

Τι κάνει εδώ κάθε κομμάτι; Το href_matches δέχεται URL pattern με wildcards, το selector_matches τρέχει CSS selector πάνω στα anchors στο DOM, και ο συνδυασμός με and, or, not επιτρέπει να αποκλείσεις sensitive routes όπως logout, checkout, account management. Το data-no-prefetch attribute είναι ένα δικό μας hint που βάζουμε σε links προς σελίδες με side effects (π.χ. «Delete» buttons που είναι υλοποιημένα ως GET links· μη το κάνετε, αλλά αν το έχετε αφήστε το να μη γίνεται prefetch).

Για dynamic rules που δεν εκφράζονται καλά με selectors, μπορείς να τρέξεις τα rules από JavaScript:

if (HTMLScriptElement.supports?.('speculationrules')) {
  const rules = document.createElement('script');
  rules.type = 'speculationrules';
  rules.textContent = JSON.stringify({
    prerender: [{
      source: 'list',
      urls: computeTopCandidates()
    }]
  });
  document.head.appendChild(rules);
}

function computeTopCandidates() {
  // π.χ. από analytics-driven ranking των πιθανότερων επόμενων URLs
  return ['/products/best-seller', '/blog/latest'];
}

Το HTMLScriptElement.supports('speculationrules') είναι το feature detection API. Παλαιότεροι browsers θα αγνοήσουν σιωπηλά το script tag, οπότε η υλοποίηση είναι progressive enhancement με μηδενικό ρίσκο. Έχει σωθεί το τομάρι μου σε δύο rollouts μέχρι στιγμής.

Deployment με Speculation-Rules HTTP header

Αν τρέχεις CDN-first stack (Vercel, Cloudflare, Fastly, Akamai) και δεν θες να ακουμπάς το HTML output, ο Speculation-Rules HTTP header σού επιτρέπει να δηλώσεις rules στο edge. Ο browser κατεβάζει ένα εξωτερικό JSON με τους κανόνες και το εφαρμόζει σαν να ήταν inline script. Αυτό αλλάζει τα πράγματα για static sites και ISR pipelines όπου το HTML είναι cached και δεν θες να το invalidate μόνο για να αλλάξεις rules.

# Παράδειγμα Cloudflare Worker / Vercel Edge Middleware
export default {
  async fetch(request, env) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);

    // Δείχνει σε στατικό JSON αρχείο που σερβίρει το ίδιο site
    newHeaders.set('Speculation-Rules', '"/speculation-rules.json"');

    return new Response(response.body, {
      status: response.status,
      headers: newHeaders,
    });
  },
};

// /speculation-rules.json (σερβίρεται με Content-Type: application/speculationrules+json)
{
  "prefetch": [
    {
      "source": "document",
      "where": { "href_matches": "/blog/*" },
      "eagerness": "moderate"
    }
  ]
}

Αυτό συνδυάζεται πολύ καλά με στρατηγικές που εξηγώ στο άρθρο για μείωση TTFB με CDN, HTTP/3 και Early Hints. Το prefetch βασίζεται στο edge cache: αν το HTML είναι ήδη warm στο CDN, το prefetched request έχει TTFB <40 ms και η επακόλουθη πλοήγηση είναι σχεδόν ακαριαία. Ο πλήρης οδηγός βρίσκεται στη τεκμηρίωση του MDN για το Speculation Rules API.

Νέο στο Chrome 144: prerender_until_script

Το μεγαλύτερο pain point του prerendering ήταν πάντα ένα: τα third-party scripts τρέχουν κατά το prerender, οπότε τα analytics counters χτυπάνε views για σελίδες που ο χρήστης δεν επισκέφθηκε ποτέ πραγματικά. Το νέο prerender_until_script, που ξεκίνησε ως origin trial στον Chrome 144 τον Ιανουάριο του 2026, φέρνει τη λύση. Ο browser κάνει fetch το HTML, ξεκινά το CSS parsing, φορτώνει εικόνες και fonts, αλλά σταματά την εκτέλεση JavaScript στο πρώτο blocking script tag. Όταν ο χρήστης πραγματικά κλικάρει, η εκτέλεση συνεχίζει.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": { "selector_matches": "a.hero-cta" },
      "eagerness": "moderate",
      "behavior": "prerender_until_script"
    }
  ]
}
</script>

Πρακτικά αυτό σημαίνει ότι όλα τα ρίσκα του prerendering (double analytics fires, unexpected data fetches, ads που προμετρώνται) εξαφανίζονται, αλλά κρατάς σχεδόν όλο το perceived-speed benefit. Ο λόγος είναι απλός: το critical rendering path (HTML + CSS + LCP εικόνα) έχει ήδη ολοκληρωθεί. Ο Chrome team δίνει feedback στο Chrome for Developers blog post για το prerender_until_script για το πόσο κοντά είναι στη σταθεροποίηση.

Πώς χειρίζεσαι analytics και third-party scripts

Αν δεν θες να περιμένεις το prerender_until_script, ή έχεις legacy analytics που δεν είναι prerender-aware, ο εκκινητής σου είναι το document.prerendering flag και το prerenderingchange event. Το prerender-loaded document έχει document.prerendering === true κατά την προετοιμασία και το event πυροδοτείται τη στιγμή της activation. Πρακτικό pattern:

function initAnalytics() {
  // Οτιδήποτε στέλνει pageview / conversion
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'page_view', path: location.pathname });
}

if (document.prerendering) {
  document.addEventListener('prerenderingchange', initAnalytics, { once: true });
} else {
  initAnalytics();
}

Το ίδιο pattern λύνει και το πρόβλημα του stale content. Αν η σελίδα prerenderarizeται νωρίς και ο χρήστης κάνει click 30 δευτερόλεπτα αργότερα, μπορεί να χρειάζεσαι revalidate: κάνε ένα SWR-style fetch όταν πυροδοτηθεί το prerenderingchange και ενημέρωσε τα δυναμικά κομμάτια (π.χ. καλάθι αγορών, live stock counts). Για third-party scripts που δεν ελέγχεις (π.χ. tag manager, ad networks), δες τον οδηγό για βελτιστοποίηση third-party scripts για Core Web Vitals. Ένα κοινό pattern είναι να καθυστερείς το injection του GTM script μέχρι το prerenderingchange, ώστε να μη γίνει διπλό tracking.

Ποιες σελίδες δεν πρέπει να κάνεις prerender;

Δεν είναι όλες οι σελίδες κατάλληλες για prerender. Ορισμένες θα σε βάλουν σε μπελάδες:

Logout, delete, purchase-confirmation URLs: κάθε endpoint που έχει side effect ακόμη και σε GET. Αν το site έχει «Logout» ως link, ένα prerender θα αποσυνδέσει τον χρήστη πριν κλικάρει. Το έχω δει να συμβαίνει, δεν το ξεχνάς εύκολα.
Stateful pages με βραχύχρονο TTL: flash sales, seat maps για κρατήσεις, live betting odds. Το prerender γίνεται 30 s νωρίτερα και ο χρήστης βλέπει stale price ή κλεισμένη θέση που φαινομενικά είναι διαθέσιμη.
Redirect-only URLs: τα redirects «καταναλώνουν» μια speculation slot χωρίς όφελος. Απόκλεισέ τα με explicit not.
Cross-origin: το Speculation Rules API υποστηρίζει cross-origin prerender μόνο με το Supports-Loading-Mode: credentialed-prerender header στην target. Αν δεν το ελέγχεις, μείνε same-origin.
Σελίδες με heavy client-side rendering και large hydration cost: το prerender θα κάψει CPU για κάτι που ίσως δεν χρειαστεί. Εδώ, καλύτερα plain prefetch για να ζεσταθεί ο HTTP cache.

Για stateful pages που πρέπει οπωσδήποτε να prerenderarizeιn, ένα καλό pattern είναι να χωρίσεις το UI. Prerender την «shell» με στατικά μέρη (header, layout, LCP hero) και fetch τα πραγματικά δεδομένα μετά το activation με έναν SWR call. Έτσι κρατάς το speed benefit και αποφεύγεις τα staleness bugs. Αυτή η προσέγγιση συνδέεται στενά με το πώς σκεφτόμαστε τη βελτιστοποίηση LCP, αφού το prerender κάνει το LCP «σχεδόν δωρεάν» όταν η shell είναι έτοιμη.

Debugging με DevTools και Chrome flags

Το πιο σημαντικό εργαλείο είναι το panel Chrome DevTools → Application → Background Services → Speculative Loads. Δείχνει σε πραγματικό χρόνο κάθε rule που εφαρμόστηκε, τις URLs που speculatedηκαν, το status κάθε speculation (Ready, Failed, Rejected, Not eligible), και τον λόγο απόρριψης αν κάτι δεν προχώρησε.

Χρήσιμα Chrome flags για local debugging:

chrome://flags/#enable-speculation-rules-header: για origin trials πριν το feature προωθηθεί σταθερά.
chrome://net-export: δίνει network log που δείχνει ποιες speculated URLs έφτασαν στο network layer και ποιες κόπηκαν από το caching.
Το Lighthouse «Speculation Rules audit» (v11.5+) δίνει scored feedback για την υγεία των rules σου.

Για production monitoring, κοίτα το Sec-Purpose: prefetch ή Sec-Purpose: prefetch;prerender HTTP header. Ο Chrome τα προσθέτει σε κάθε speculated request. Στα server logs μπορείς να ξεχωρίσεις πόσα από τα requests σου είναι speculative· ένα υγιές rollout δείχνει 15-30% speculative traffic, με hit rate 40-60% (δηλαδή τα μισά τουλάχιστον οδηγούν σε πραγματικές πλοηγήσεις). Οι λεπτομέρειες για το debugging είναι εξαιρετικά καλά τεκμηριωμένες στο Chrome for Developers guide για prerender pages.

Στο πραγματικό performance instrumentation, φρόντισε επίσης να αναγνωρίζεις τα prerendered navigations στα analytics σου. Το PerformanceNavigationTiming.activationStart δίνει timestamp όταν ενεργοποιήθηκε ένα prerendered document, ώστε να μετράς σωστά τα Core Web Vitals (LCP, FCP) από το activation, όχι από το prerender start.

Συχνές ερωτήσεις

Ποια είναι η διαφορά μεταξύ Speculation Rules API και του παλιού <link rel="prefetch">;

Το <link rel="prefetch"> είναι per-URL και χρησιμοποιείται συνήθως για subresources του τρέχοντος document. Το Speculation Rules API είναι pattern-based (μπορεί να καλύψει όλα τα εσωτερικά links με έναν κανόνα), προσθέτει eagerness heuristics, υποστηρίζει πλήρες prerender και HTTP header deployment, και είναι η μόνη σύγχρονη λύση για prerendering. Το legacy rel="prerender" έχει καταργηθεί από τον Chrome από το 2023.

Υποστηρίζει το Safari ή ο Firefox το Speculation Rules API;

Όχι, όχι ακόμη. Το API είναι Chromium-only (Chrome, Edge, Opera, Brave, Samsung Internet). Ο Firefox έχει το ticket ανοιχτό αλλά χωρίς commitment ημερομηνίας· ο Safari δεν έχει δηλώσει πρόθεση. Ωστόσο η υλοποίηση είναι progressive enhancement: unsupported browsers αγνοούν σιωπηλά το <script type="speculationrules">, οπότε είναι ασφαλές να το ενεργοποιήσεις χωρίς detection.

Θα σπάσει το prerender τα Google Analytics ή Meta Pixel;

Χωρίς μέτρα, ναι, θα δεις διπλά pageviews στα analytics για πολλές σελίδες που ο χρήστης δεν επισκέφθηκε ποτέ. Οι λύσεις είναι τρεις: (1) χρήση του prerender_until_script στον Chrome 144+ που σταματά τη JS εκτέλεση κατά το prerender, (2) καθυστέρηση του analytics init μέχρι το prerenderingchange event, ή (3) upgrade σε GA4 v3+ που είναι prerender-aware και μετράει views μόνο μετά την activation.

Πόσο επηρεάζει το Speculation Rules API τα Core Web Vitals μου;

Επηρεάζει κυρίως το LCP και το INP των επόμενων πλοηγήσεων μέσα στο site. Πραγματικά νούμερα: Ray-Ban κατέγραψε πτώση LCP από 4.69 s σε 2.66 s στο mobile (43% γρηγορότερα) με moderate prerender, και το Shopify κατέγραψε 130-180 ms βελτίωση σε όλα τα paint metrics με conservative prefetch. Για την πρώτη σελίδα εισόδου, το API δεν βοηθά· για αυτό χρειάζεσαι CDN caching και edge rendering.

Χρειάζομαι SSR/ISR για να χρησιμοποιήσω το Speculation Rules API;

Όχι, το API λειτουργεί με οποιοδήποτε rendering strategy (SSR, SSG, ISR, ακόμη και client-side rendering). Ωστόσο το κέρδος είναι μεγαλύτερο όταν οι speculated σελίδες σερβίρονται γρήγορα από cache (CDN edge, ISR, static output), γιατί το prefetch χτυπάει τον cache και είναι σχεδόν δωρεάν. Σε καθαρά CSR SPAs, το prerender έχει περιορισμένη αξία γιατί η ίδια runtime hydration απαιτείται εξαρχής.