המקור באנגלית: English
תאריך פרסום המקור באנגלית: 2026-08-17T10:14:50.771+03:00. תרגום ובדיקה: 28 באוקטובר 2026. זה אינו תאריך הפרסום של הגרסה העברית.
הערת עדכון: גרסה זו כוללת תיקונים עובדתיים ובטיחותיים מתועדים למקור. הדוגמאות להמחשה בלבד ולא הורצו במסגרת הכנת המאמר.
Cloudflare Web Analytics יכול להוסיף סקריפט מדידה ל־HTML העובר דרך המתווך כאשר הגדרה אוטומטית מופעלת עבור אתר שהוגדר בשירות המדידה. נבחן כיצד לבדוק את ההגדרה ואת הדף שנמסר לדפדפן. הטענה המקורית שלפיה שינוי שרתי שמות לבדו מפעיל מדידה שקטה בכל אתר חדש אינה נתמכת בתיעוד העדכני.
למנהלי אתרים חשוב לדעת איזה רכיב משנה תשובה כדי לאבחן תקלות ולבחון פרטיות וביצועים. מתווך הפוך עשוי לשנות HTML במכוון לפי הגדרות מוצר שהופעלו. יש לבדוק את ההגדרות והתשובה בפועל, ולא להניח כיצד נראה תהליך ההצטרפות או איזו הסכמה ניתנה.
נפריד בין התנהגות מתועדת לבין מודל מושגי של שכתוב HTML, נראה כיצד לבדוק דף ציבורי מורשה ונסביר את הגדרות לוח הבקרה וה־API. הדוגמאות מיועדות להסבר בלבד; שום אתר לא נבדק או הוגדר מחדש במסגרת הכנת המאמר.
איזה סקריפט Web Analytics עשוי להוסיף?
האצלת שרתי שמות והפעלת תיווך לרשומת DNS הן בחירות שונות. בתעבורה מתאימה שעוברת דרך המתווך, Cloudflare מבצעת בין היתר סיום TLS ועיבוד אבטחה ומטמון לפי ההגדרות; רשומות DNS בלבד אינן מעבירות את תשובת ה־HTTP דרך המתווך הזה. יש לבדוק את הרשומה ואת הגדרות המוצר ולא להניח שכל התעבורה מתווכת.
אתר שהוגדר לשירות עשוי לכלול מקטע Web Analytics כגון הדוגמה שלהלן. יש לקבל את המקטע העדכני מהגדרות האתר; האסימון כאן הוא מציין מקום, והקוד המוצג אינו מופעל מתוך המאמר.
<!-- Illustration only; obtain the current snippet from the site settings. -->
<script type="module" src="https://static.cloudflareinsights.com/beacon.min.js"
data-cf-beacon='{"token":"SITE_TOKEN_PLACEHOLDER"}'></script>מדדי Core Web Vitals הנוכחיים הם LCP, INP ו־CLS; המדד First Input Delay אינו מדד התגובתיות הנוכחי. מדריך ההתקנה מציין שהתקנה אוטומטית מופעלת כברירת מחדל כאשר מוסיפים לשירות Web Analytics שם מארח העובר דרך המתווך. השלב המתועד הזה אינו זהה להעברת שרתי שמות בלבד. יש להעריך את זרימת הנתונים ואת דרישות הפרטיות של השימוש המסוים, ולא להסיק עמידה בדרישות מתווית שיווקית.
המנגנון הטכני: ניתוח HTML דינמי בקצה הרשת
מתווך הפוך המסיים TLS יכול לעבד תוכן HTTP מפוענח בתוך גבול האמון שלו ולהצפין שוב את החיבור אל הלקוח. דחיסה היא עניין נפרד של ייצוג התוכן. שינויים בזרימה עשויים לצמצם אגירה, אך המאמר אינו קובע עלות השהיה מדודה או את המימוש הפנימי של Web Analytics.
עץ DOM מלא הוא דרך אחת לשנות HTML, לא דרישה היסטורית של כל מימוש. מנתחים זורמים יכולים לעבד מקטעים בהדרגה. הזיכרון, האגירה וההשהיה תלויים במנתח ובשינוי; לא נמדדה כאן תקורה קטסטרופלית.
שכתוב HTML בזרימה כמודל הסברי
Cloudflare Workers מציעה את HTMLRewriter; בתיעוד מתוארים ניתוח בזרימה וטקסט המגיע בכמה מקטעים. זהו מודל מועיל להבנת שינוי הדרגתי. אין בכך הוכחה באיזה מנתח, שפה, אסטרטגיית אגירה או סדר פעולות משתמש כיום שירות Web Analytics הנפרד.
התרשים הוא מסלול תשובה מושגי כאשר שינוי מוגדר פעיל, לא תיעוד מאומת של צינור העיבוד הפנימי של כלי המדידה:
[Origin HTTP response]
|
v
[TLS-terminating reverse proxy]
| configured transformation, if applicable
| (conceptual model, not an internal implementation trace)
v
[Delivered HTML, potentially including an analytics snippet]
|
v
[Browser: CSP/resource checks, then permitted script/network activity]
סקריפט שנוסף חייב לעמוד ב־CSP של הדף, ובקשות הרשת שלו חייבות לעמוד במדיניות החיבורים המתאימה. SRI מאמת משאב שנטען מול ערך שלמות; הוא אינו נעילה כללית על מסמך ה־HTML כולו. Cloudflare מתעדת ערך שלמות בהתקנה אוטומטית, ואילו המקטע הידני אינו מקובע לגרסה המאפשרת גיבוב SRI קבוע ובטוח. יש למדוד ביצועים בסביבה מייצגת.
למה זה חשוב: סיכוני אבטחה וביצועים
השאלה התפעולית היא האם השינוי שהוגדר תואם לכוונת מנהל האתר ולמדיניות היישום. אין צורך להסיק דבר על מניעי הספק. בדקו את שלושת התחומים הבאים:
1. הפרות של מדיניות אבטחת תוכן — CSP
להמחשה, המדיניות הבאה מתירה סקריפטים רק מהמקור של הדף עצמו. CSP לבדו אינו מוכיח שהיישום כולו מאובטח מאוד:
Content-Security-Policy: default-src 'self'; script-src 'self';מדיניות script-src שבדוגמה חוסמת סקריפט מ־static.cloudflareinsights.com. Cloudflare מתעדת את מקורות הסקריפט והחיבורים הדרושים: בהגדרה אוטומטית הדיווח הוא לנתיב /cdn-cgi/rum באתר עצמו, ובהגדרה ידנית ל־cloudflareinsights.com/cdn-cgi/rum. יש לבחון את ה־CSP המלא לפני מתן הרשאה. התנהגות nonce תלויה במדיניות המדויקת; אין להניח העברה אוטומטית שלו או להחליש CSP בלי בדיקה.
2. המשמעות של ETag ואימות מטמון
ETag הוא מזהה אימות אטום, לא בהכרח גיבוב קריפטוגרפי. מזהה חזק מבדיל בין ייצוגים ברמת הבתים; מזהה חלש מאפשר שקילות סמנטית. שינוי תוכן ודחיסה עשויים לחייב שינוי, החלשה או הסרה של המזהה לפי תצורת המטמון. Cloudflare מתעדת כמה מקרים כאלה. בדקו כותרות וכללי מטמון בפועל; עצם הופעת הסקריפט אינה מוכיחה שאימות המטמון פגום.
3. עקרון ההרשאה המזערית
מתווך הפוך המסיים TLS כבר נמצא בתוך גבול האמון של תוכן היישום. הרשאה מזערית ובקרת שינויים עדיין חשובות: הפעילו רק יכולות רצויות, הגבילו גישה ניהולית ותעדו שינויים. CDN הכולל אבטחה ומטמון אינו בהכרח צינור המעביר בתים ללא שינוי.
איך לבדוק את האתרים שלכם
אחזור לקריאה בלבד יכול להראות אם ה־HTML שנמסר מכיל הפניה מוכרת למשואה. הוא אינו יכול לקבוע לבדו מי הוסיף אותה. יש לבחון גם תבניות מקור, מנהלי תגיות ותצורת מדידה.
הדוגמה מיועדת לדף HTTPS ציבורי ומהימן שיש לכם הרשאה לבדוק, והיא לא הורצה. החליפו במכוון את example.com, בחרו שם חדש לקובץ הפלט המקומי ובדקו שגיאות HTTP או הפניות לפני הסקת מסקנות. האפשרות --compressed של curl מטפלת בקידודי תוכן נתמכים; אין להעביר כל תשובה באופן עיוור ל־gunzip. הדוגמה דורשת curl בגרסה 8.20 ומעלה כדי להגביל את גודל הפלט לאחר פריסה; בגרסאות ישנות התנהגות המגבלה שונה. שלב grep מותנה בהצלחת curl ובמצב HTTP 200, ואין מעקב אחרי הפניות.
# Documentation only; NOT run. Requires curl 8.20+ for the decompressed-size cap.
# Use a new output filename and an authorized trusted public HTTPS page.
status=$(curl --fail --silent --show-error --compressed \
--proto '=https' --max-time 20 --max-filesize 2097152 \
--output audit-page-example.html --write-out '%{http_code}' https://example.com/)
result=$?
if [ "$result" -eq 0 ] && [ "$status" = '200' ]; then
grep -nE 'cloudflareinsights|beacon\.min\.js' audit-page-example.html
else
printf 'No content conclusion: curl exit=%s, HTTP=%s\n' "$result" "$status" >&2
fi
# Redirects are intentionally not followed. A grep match does not identify insertion source.
התאמה פירושה שהתשובה המסוימת מכילה את הטקסט. הוא עשוי להגיע מהתקנה אוטומטית, ממקטע ידני או משילוב אחר. גם היעדר התאמה אינו מוכיח שמדידה לעולם אינה נטענת: התנהגות הדפדפן, נתיבים, תנאים וגרסאות פרוסות עשויים להשתנות. השוו למקור ולתצורה מורשים ובדקו בנפרד בקשת דפדפן מייצגת.
ניהול ההתקנה האוטומטית של Web Analytics
מנהל מורשה יכול לנהל את התקנת Web Analytics בלוח הבקרה או דרך ה־API ברמת החשבון. ביטול היכולת הזאת אינו מבטל כל שינוי HTML אפשרי, אינו מסיר קוד שהוטמע ידנית ואינו מוכיח שכל המדידה נפסקה. יש לתעד את המצב הקודם ולוודא את התוצאה המיועדת אחרי שינוי מאושר.
שיטה 1: דרך לוח הבקרה של Cloudflare
- היכנסו ל־Cloudflare Dashboard.
- פתחו את Web Analytics בלוח הבקרה של החשבון.
- מצאו את אתר המדידה או שם המארח הרלוונטי ואת התפריט שלו.
- בחרו Manage Site ובדקו את מצב ההתקנה הקיים.
- בחרו Disable לביטול Web Analytics, או באפשרות התקנת מקטע JavaScript ידנית אם המדידה עדיין רצויה ללא הוספה אוטומטית. ודאו את ההגדרה שהתקבלה ובדקו בנפרד אם כבר קיים מקטע ידני.
התקנה ידנית פירושה שאתם מציבים בעצמכם את המקטע שסופק בדף. היא אינה מוכיחה שיש תמיכה באירוח עצמי של עותק המשואה, בדחייה שרירותית של טעינתה או בשילוב nonce אוטומטי. השתמשו במקטע העדכני של הספק ובחנו CSP, זרימת נתונים והתנהגות טעינה לפני פריסה.
שיטה 2: באופן תכנותי דרך Cloudflare API
נקודת הקצה המתאימה היא PUT /accounts/{account_id}/rum/site_info/{site_id}, ולא הגדרת development_mode ברמת האזור שהופיעה במקור. תבנית הבקשה שלהלן מגדירה auto_install כ־false כדי להפסיק התקנה אוטומטית של המקטע. היא אינה מסירה מקטע שהותקן ידנית. זהו שינוי הגדרה בחשבון המחייב הרשאה; לא נשלחה שום בקשה.
PUT https://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/rum/site_info/SITE_ID
Authorization: Bearer SCOPED_TOKEN_PLACEHOLDER
Content-Type: application/json
{"auto_install":false}
# Request blueprint only: NOT sent; this would change an account setting.
# Existing manually embedded snippets require separate review.
תיעוד ה־API מעדיף אסימון Bearer מוגבל ומציין עבור נקודת קצה זו הרשאת Account Settings Write, לא Zone.Settings:Edit. יש לזהות במכוון את החשבון ואת אתר המדידה, לצמצם הרשאות ולטפל בסודות מחוץ ליומנים או לקוד מפורסם. בדקו מצב HTTP, שדות success/errors והמצב שהוחזר, ואז את הדף שנמסר. השדה הנפרד enabled חל רק כאשר auto_install=true; אין להסיק משמעות מהעתקת מטען של מוצר אחר.
סיכום
הלקח המעשי הוא נראות של התצורה, לא טענה לא מאומתת על כל מעבר שרתי שמות. בררו אם Web Analytics הוגדר, כיצד המקטע מותקן והאם ההתנהגות תואמת לכוונת בעל האתר.
שלבו סקירת הגדרות עם בדיקת תשובות, CSP ובדיקות ביצועים מייצגות. כך מתקבלות ראיות על התצורה שנבדקה, לא הבטחה שכל נתיב, גרסת מטמון או פריסה עתידית יתנהגו באופן זהה.
מה דעתכם? האם פלטפורמות ענן צריכות תמיד לדרוש הסכמה מפורשת לפני שינוי HTML, או שאתם מעדיפים את הנוחות של מדידה ללא הגדרה? בואו נדבר בתגובות.
עד הפעם הבאה, שמרו על תלויות מעודכנות ועל הגדרות מפורשות. להתראות!
מקרא התרשים: תשובת שרת המקור, מתווך המסיים TLS, שינוי מוגדר אם הוא פעיל, HTML שנמסר ודפדפן שמחיל בדיקות CSP ומשאבים. זהו מודל הסברי ולא תיעוד של המימוש הפנימי.