ניווט וטעינה חזויה 14 דקות קריאה

Speculation Rules API ב-2026: המדריך המלא לטעינה חזויה, Prefetch ו-Prerender

גלו את Speculation Rules API — הטכנולוגיה שמאפשרת לדפדפן לטעון ולרנדר דפים מראש לפני שהמשתמש לוחץ. מדריך מעשי עם דוגמאות קוד, Cloudflare Speed Brain, וטיפים לשיפור LCP ו-Core Web Vitals.

Editorial Team

מבוא: הצעד הבא בסדרת ביצועי האתרים שלנו

אם עקבתם אחרי הסדרה שלנו, כבר כיסינו את Core Web Vitals, אופטימיזציית תמונות, JavaScript, TTFB עם CDN ו-Caching, ו-CSS עם פונטים. כל אלה מתמקדים באותה שאלה — איך לגרום לדף הנוכחי לטעון מהר יותר. אבל רגע, מה עם הדף הבא?

תחשבו על זה רגע. המשתמש נחת באתר שלכם, הדף נטען בזק. מצוין, עבודה טובה. עכשיו הוא לוחץ על קישור, ו... מחכה שוב. כל אותה עבודה קשה שהשקעתם בדף הראשון? התחושה נעלמת ברגע שהניווט הבא מרגיש איטי. ממש מתסכל.

וכאן נכנס לתמונה ה-Speculation Rules API.

זו טכנולוגיה שמאפשרת לדפדפן לטעון ואפילו לרנדר דפים מראש, לפני שהמשתמש בכלל לוחץ. התוצאה? ניווט שמרגיש כמעט מיידי — אפס זמן המתנה, אפס מסך לבן. ועם השפעה ישירה על LCP וחוויית המשתמש, אני חייב להגיד שזה אחד הנושאים הכי שווים ללמוד ב-2026.

מה זה Speculation Rules API ולמה אתם צריכים להכיר את זה

הבעיה עם הגישות הישנות

לפני Speculation Rules היו לנו בעצם שתי אפשרויות, ושתיהן מוגבלות:

  • <link rel="prefetch"> — שולף את המסמך מראש ושומר אותו בקאש HTTP. עובד, אבל לא נותן שליטה מספיקה ולא תומך ב-prerender.
  • <link rel="prerender"> — היה אמור לרנדר דפים מראש, אבל בפועל? עבד רק ב-Chrome, וגם שם ביצע רק NoState Prefetch. כיום זה deprecated לחלוטין.

ה-Speculation Rules API הוא המחליף המודרני של שתי הגישות האלה. הוא מציע תחביר JSON עשיר, שליטה ברמת הביטחון של כל חיזוי, ושמירה בזיכרון במקום בקאש דיסק — מה שמוביל לביצועים טובים משמעותית.

שני סוגי טעינה חזויה

ה-API נותן לנו שתי אסטרטגיות:

  • Prefetch — מוריד את תגובת ה-HTML של הדף הבא, אבל לא את תת-המשאבים (תמונות, CSS, JS) ולא מרנדר. אופציה קלילה שחוסכת את ה-roundtrip הראשון לשרת.
  • Prerender — מוריד את הדף, כל המשאבים שלו, מריץ JavaScript, ומרנדר הכל בטאב נסתר בזיכרון. כשהמשתמש מנווט — הדף פשוט מוחלף מיידית. אפס זמן טעינה.

ההבדל הזה קריטי. prefetch חוסך בנדוויד'ת וזיכרון, אבל עדיין דורש רינדור בזמן ניווט. prerender צורך יותר משאבים, אבל נותן חוויית ניווט שמרגישה כאילו הדף היה שם כל הזמן — אפס TTFB מנקודת המבט של המשתמש.

יישום מעשי: שלב אחר שלב

שיטה 1: תגית Script בתוך ה-HTML

הדרך הכי פשוטה להתחיל עם Speculation Rules. מוסיפים תגית <script type="speculationrules"> ב-head של הדף:

<head>
  <script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["/products", "/about", "/contact"]
      }
    ],
    "prerender": [
      {
        "urls": ["/checkout"]
      }
    ]
  }
  </script>
</head>

פשוט, נכון? אנחנו אומרים לדפדפן: "תשלוף מראש את דפי המוצרים, אודות וצור קשר, ותרנדר מראש את דף הצ'קאאוט." זה הגיוני — אם המשתמש כבר באתר, סביר שינווט לדפים האלה. ודף הצ'קאאוט? זו המרה קריטית שאתם רוצים שתהיה מיידית.

שיטה 2: באמצעות HTTP Header

אם אתם מעדיפים לא להוסיף תגיות script ל-HTML (מה שלגיטימי לגמרי), אפשר להגדיר את החוקים דרך כותרת HTTP. שימושי במיוחד באתרים דינמיים:

Speculation-Rules: "/rules/speculation.json"

וקובץ ה-JSON הנפרד נראה ככה:

// /rules/speculation.json
{
  "prefetch": [
    {
      "urls": ["/popular-category", "/sale"]
    }
  ],
  "prerender": [
    {
      "urls": ["/homepage"]
    }
  ]
}

טיפ חשוב: קובץ ה-JSON חייב להיות מוגש עם סוג MIME של application/speculationrules+json. בלי זה, הדפדפן פשוט יתעלם מהקובץ. נתקלתי בזה בעצמי ובזבזתי שעה טובה על דיבאג עד שהבנתי שזו הבעיה.

שיטה 3: Document Rules — וזה כבר הכוח האמיתי

אוקיי, אז עד עכשיו ציינו כתובות URL ספציפיות. אבל Document Rules זה משחק אחר לגמרי — הם מאפשרים להגדיר חוקים דינמיים שמתבססים על הקישורים שקיימים בדף. הנה דוגמה:

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

מה שקורה פה: הדפדפן סורק את כל הקישורים בדף ומחיל עליהם את החוקים. כל קישור פנימי (חוץ מ-logout ואזור הניהול) ייטען מראש, וכל קישור למוצר ירונדר מראש — אבל רק כשהמשתמש מרחף מעליו. אלגנטי, יעיל, ומתעדכן אוטומטית כשהתוכן משתנה.

הגדרת Eagerness — מתי הדפדפן צריך לפעול

אחד הפיצ'רים הכי חזקים של ה-API הוא ההגדרה eagerness. היא קובעת באיזה רגע הדפדפן מתחיל את הטעינה המקדימה:

  • immediate — מתחיל מיד עם טעינת הדף. מתאים לחיזויים ברמת ביטחון גבוהה (למשל, דף הצ'קאאוט אחרי הוספה לסל).
  • eager — מתחיל מוקדם, מגיב לאותות עדינים כמו תנועת עכבר לכיוון הקישור.
  • moderate — מתחיל כשהמשתמש מרחף מעל הקישור למשך 200 מילישניות. ברירת מחדל מאוזנת וטובה.
  • conservative — מתחיל רק בלחיצה (mousedown/pointerdown). הכי חסכוני במשאבים.

ההמלצה שלי? התחילו עם moderate עבור prefetch ו-conservative עבור prerender. זה נותן איזון מצוין בין מהירות לצריכת משאבים, ותוכלו תמיד לכוון מכאן לפי הנתונים שתראו.

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

מגבלות זיכרון שכדאי להכיר

Chrome מגביל את כמות ה-speculations הפעילות:

  • עד 50 דפים ב-prefetch
  • עד 10 דפים ב-prerender

כשמגיעים למגבלה, speculation חדש דוחף החוצה את הישן ביותר (FIFO). אם המשתמש חוזר ומרחף על קישור שנדחף — הוא פשוט ייטען מחדש. לא דרמה.

Cloudflare Speed Brain — Speculation Rules בלי לגעת בקוד

אחד הדברים שבאמת התלהבתי מהם לאחרונה הוא הפיצ'ר Speed Brain של Cloudflare. הוא מוסיף אוטומטית כותרת Speculation-Rules לתגובות ה-HTTP שלכם — בלי שתצטרכו לגעת בשורת קוד אחת.

איך מפעילים

ב-Cloudflare Dashboard: Speed → Optimization → Content Optimization → Speculation. לאתרים בתוכנית חינמית זה מופעל כברירת מחדל (אפשר לבטל). לתוכניות Pro ומעלה צריך להפעיל ידנית.

רוצים לעשות את זה דרך API? בבקשה:

curl -X PATCH   "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/speed_brain"   -H "Authorization: Bearer {api_token}"   -H "Content-Type: application/json"   --data '{"value": "on"}'

תוצאות בפועל

המספרים פה מדברים בעד עצמם. לפי הנתונים של Cloudflare, אתרים חינמיים שהשתמשו ב-Speed Brain ראו ירידה של 0.88 עד 1.1 שניות ב-LCP בכל prefetch מוצלח. מ-p75 LCP של 2.2 שניות, זה שיפור של 40%-50%.

קשה להתווכח עם זה.

הערה חשובה: Speed Brain לא משפר את הדף הראשון שהמשתמש מבקר בו — רק את הניווטים הבאים. הוא גם לא עובד על דפים שמריצים Cloudflare Workers או על תוכן דינמי שלא מוגש מהקאש. חשוב לזכור את זה כדי שלא תצפו לניסים בכל הדפים.

דיבאג ומעקב ב-Chrome DevTools

אז הגדרתם הכל, אבל איך בודקים שזה באמת עובד? למזלנו, Chrome DevTools מציע כלים מובנים ממש טובים לזה.

שלב 1: פתיחת Speculative Loads

ב-DevTools, נווטו ל-Application → Background Services → Speculative Loads → Speculations. וכאן יש טיפ קריטי — פתחו את הפאנל לפני שטוענים את הדף. אם תפתחו אותו אחרי, לא תראו את ה-speculations שכבר התרחשו.

שלב 2: בדיקת החוקים

בפאנל תראו רשימה של כל ה-speculations שהדפדפן ביצע. לכל אחד יש סטטוס — הצליח, נכשל, או עדיין בתהליך. ואם משהו נכשל, תראו גם את הסיבה. מאוד נוח לדיבאג.

שלב 3: בדיקת דף מרונדר מראש

כשדף מרונדר מראש, DevTools מאפשר לעבור להקשר של הדף המרונדר ולבדוק אותו כאילו הוא דף רגיל. אפשר לבדוק את ה-DOM, לראות את ה-Network requests, הכל.

שלב 4: לשונית Network

ב-Network tab תוכלו לזהות את הבקשות שנוצרו על ידי speculation rules — הן מסומנות עם סוג מיוחד שמקל על הזיהוי. אם אתם לא רואים אותן, ודאו שהפילטר לא מסתיר אותן.

תוצאות בעולם האמיתי — והמספרים מרשימים

בואו נדבר תכל'ס. ההשפעה של Speculation Rules על ביצועים מתועדת היטב, והנה כמה דוגמאות:

  • Ray-Ban — השתמשו ב-speculative preloading והגדילו את ההמרות בדסקטופ ב-156%. קראתם נכון, 156 אחוז.
  • Scalemates — ב-p95, LCP היה מהיר ב-500 מילישניות. ב-p75, LCP ירד מ-714ms ל-537ms בדפים מרונדרים מראש — שיפור של 177 מילישניות. ו-59% מהניווטים הפעילו prerender, מה שאומר שהשיפור הורגש ברוב החוויה.
  • Cloudflare Speed Brain — חיסכון של 0.88-1.1 שניות ב-LCP בכל prefetch מוצלח.

ההשפעה העיקרית היא על LCP, כי הדף כבר טעון כשהמשתמש מנווט. אבל יש גם השפעה על CLS (פחות קפיצות — הפריסה כבר חושבה מראש) ועל INP (פחות עומס על ה-main thread ברגע הניווט). בקיצור, Win-Win-Win.

שיטות עבודה מומלצות ומלכודות נפוצות

מה כן לעשות

  • התחילו עם prefetch רחב ו-prerender ממוקד — prefetch לכל הקישורים הפנימיים, prerender רק למסלולי ניווט שאתם בטוחים לגביהם.
  • העדיפו Document Rules — הם גמישים יותר מרשימות URL סטטיות ומתעדכנים אוטומטית כשהתוכן משתנה.
  • מדדו את ההשפעה — השתמשו ב-CrUX או RUM כדי לוודא שהשיפור אמיתי. לא כל speculation מצליח, ו-overspeculation דווקא יכול להזיק.
  • התאימו eagerness לסוג התוכן — moderate עבור ניווט כללי, conservative עבור דפים כבדים. אל תפחדו להתחיל שמרנית ולהגביר בהדרגה.

מה לא לעשות

  • אל תרנדרו מראש דפים כבדים בלי סיבה — דף עם הרבה JavaScript צורך משאבים רציניים. אם המשתמש לא ינווט לשם, בזבזתם בנדוויד'ת וזיכרון לחינם.
  • אל תתעלמו מ-analytics — prerender מריץ JavaScript, כולל סקריפטים של analytics. ודאו שספריית ה-analytics שלכם תומכת ב-Document.prerendering API, אחרת תקבלו צפיות כפולות. וזה באמת מבלבל בדאשבורד.
  • אל תשתמשו ב-prerender בין דומיינים — מסיבות פרטיות, cross-site prefetch עובד רק כשלמשתמש אין cookies באתר היעד.
  • אל תשכחו לבדוק תמיכת דפדפנים — נכון ל-2026, Speculation Rules נתמך בדפדפני Chromium (Chrome, Edge, Opera). Firefox ו-Safari מתקדמים אבל עדיין בגדר ניסיוני. החדשות הטובות? הכיסוי הגלובלי כבר מעל 75% מהמשתמשים.

טיפול בדפדפנים לא נתמכים

וכאן באה הידיעה המרגיעה: Speculation Rules הוא progressive enhancement מובנה. דפדפנים שלא מכירים את <script type="speculationrules"> פשוט מתעלמים ממנו. לא צריך polyfill, לא צריך feature detection. הדף עובד רגיל, ומשתמשים בדפדפנים תומכים מקבלים בונוס של חוויה מהירה יותר. ככה צריך לעשות progressive enhancement.

דוגמת יישום מלאה: אתר מסחר אלקטרוני

אז הנה דוגמה מלאה שמחברת את כל מה שדיברנו עליו. נניח שיש לכם אתר מסחר אלקטרוני טיפוסי:

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/admin/*" } },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/cart/remove/*" } },
          { "not": { "selector_matches": "[data-no-prefetch]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "source": "document",
      "where": {
        "href_matches": "/products/*"
      },
      "eagerness": "moderate"
    },
    {
      "source": "document",
      "where": {
        "selector_matches": ".cta-primary"
      },
      "eagerness": "eager"
    }
  ]
}
</script>

בואו נפרק את מה שקורה פה:

  1. Prefetch רחב — כל קישור פנימי ייטען מראש כשהמשתמש מרחף מעליו. יוצאים מן הכלל: נתיבי API, אזור ניהול, התנתקות, ואלמנטים עם data-no-prefetch.
  2. Prerender ממוקד למוצרים — דפי מוצר ירונדרו מראש ברחיפה. הם יעד ניווט שכיח עם פוטנציאל המרה גבוה, אז זה שווה את המשאבים.
  3. Prerender אגרסיבי ל-CTA — כפתורי הנעה לפעולה ירונדרו עם eagerness: eager. הרעיון — אם מישהו מתקרב ל-CTA, הוא כנראה מתכוון ללחוץ. אז בואו נהיה מוכנים.

טיפול נכון ב-Analytics עם Prerender

כפי שהזכרתי קודם, prerender מריץ JavaScript מראש — וזה כולל גם את סקריפטי ה-analytics שלכם. כדי למנוע ספירה כפולה של צפיות דף, תצטרכו להשתמש ב-Document.prerendering API:

// Check if the page is being prerendered
if (document.prerendering) {
  // Wait for activation (actual navigation)
  document.addEventListener("prerenderingchange", () => {
    // Now the user actually navigated here
    trackPageView();
  }, { once: true });
} else {
  // Normal page load
  trackPageView();
}

function trackPageView() {
  // Your analytics code here
  gtag("event", "page_view", {
    page_title: document.title,
    page_location: window.location.href
  });
}

שווה לציין ש-Google Analytics 4 כבר מטפל בזה מובנה. אבל אם אתם משתמשים בפתרון analytics מותאם אישית (ויש לא מעט חברות שכן), הקוד הזה הכרחי.

שאלות נפוצות (FAQ)

מה ההבדל בין Speculation Rules API ל-link rel="prefetch" הישן?

כמה הבדלים מהותיים: Speculation Rules שומר תוצאות בזיכרון (לא בקאש HTTP), תומך ב-prerender מלא (ולא רק prefetch), מציע תחביר JSON עשיר עם Document Rules, ומאפשר שליטה ב-eagerness. בנוסף, <link rel="prerender"> הישן הוא deprecated — הוא לא ביצע prerender אמיתי כבר שנים.

האם Speculation Rules API עובד עם SPA כמו React או Vue?

בקצרה — לא. ה-API מיועד ל-Multi-Page Applications שבהן ניווט כולל טעינת מסמך HTML חדש. ב-SPA הניווט מתרחש בצד הלקוח, ואתם צריכים את מנגנוני ה-prefetch של הפריימוורק (למשל, next/link ב-Next.js עם prefetch). עם זאת, אם אתם עובדים ב-SSR עם ניווט מלא בין דפים — ה-API כן רלוונטי עבורכם.

כמה משאבים צורך prerender וזה בטוח להפעיל?

prerender צורך משאבים דומים לטעינת דף רגיל — JavaScript, CSS, תמונות, הכל. אבל Chrome חכם — הוא מגביל ל-10 דפים מרונדרים בזיכרון, מבטל speculations ב-battery saver mode, ועוצר כשהזיכרון מוגבל. גם תוספי חסימה כמו uBlock Origin יכולים לבטל preload. כל עוד אתם לא מנסים לרנדר מראש 100 דפים בו-זמנית (ולמה שתעשו?), הסיכון נמוך מאוד.

איך Speculation Rules משפיע על עלויות שרת?

שאלה מצוינת שלא מספיק אנשים שואלים. אם כל ניווט מייצר 2-3 בקשות prefetch נוספות, עלויות ה-backend עלולות לזנק. ההמלצה: התחילו עם eagerness: moderate או conservative, עקבו אחרי traffic patterns, ושקלו להגיש דפים מ-CDN cache. ואם אתם משתמשים ב-Cloudflare Speed Brain — בקשות ה-prefetch מוגשות מהקאש ולא מגיעות בכלל לשרת המקור. חיסכון כפול.

האם Speculation Rules API משפיע על SEO?

ישירות — לא, מנועי חיפוש לא מתייחסים ל-speculation rules בדירוג. אבל עקיפות? בהחלט. שיפור ב-LCP ובחוויית ניווט משפר את מדדי Core Web Vitals, שהם גורם דירוג. ובכלל, חוויית משתמש מהירה מובילה לשהייה ארוכה יותר, נטישה נמוכה יותר, ויותר המרות — כל אלה אותות חיוביים עבור Google.

אודות הכותב Editorial Team

Our team of expert writers and editors.