המדריך בוחן את הכללים של PageSpeed Insights בהקשר שלהם: למה חשוב לשים לב כשמבצעים אופטימיזציה של נתיב העיבוד הקריטי, ומדוע.
להסיר JavaScript ו-CSS שחוסמים את העיבוד
כדי לקצר את משך הזמן עד לעיבוד הראשון, כדאי לצמצם (ואם אפשר) את מספר המשאבים הקריטיים שבדף, למזער את מספר הבייטים הקריטיים שהורדו ולבצע אופטימיזציה של אורך הנתיב הקריטי.
אופטימיזציה של השימוש ב-JavaScript
משאבי JavaScript חסומים כברירת מחדל על ידי המנתח, אלא אם הם מסומנים כ-async או נוספו באמצעות קטע JavaScript מיוחד. מנתח חסימת JavaScript מאלץ את הדפדפן להמתין ל-CSSOM ומשהה את בניית ה-DOM, מה שעלול לעכב באופן משמעותי את הזמן לעיבוד הראשון.
יש לתת עדיפות למשאבי JavaScript אסינכרוניים
משאבים אסינכרוניים מבטלים את החסימה של מנתח המסמכים ומאפשרים לדפדפן להימנע מחסימה ב-CSSOM לפני הפעלת הסקריפט. לעיתים קרובות, אם הסקריפט יכול להשתמש במאפיין async, המשמעות היא גם שהוא לא חיוני לעיבוד הראשון. מומלץ לטעון סקריפטים באופן אסינכרוני אחרי הרינדור הראשוני.
הימנעות מקריאות שרת סינכרוניות
משתמשים בשיטה navigator.sendBeacon() כדי להגביל נתונים שנשלחים על ידי XMLHttpRequests ברכיבי handler של unload. מכיוון שדפדפנים רבים דורשים שהבקשות יהיו סינכרוניות, הם עלולים להאט מעברי דפים, לפעמים באופן בולט. הקוד הבא מראה איך להשתמש ב-navigator.sendBeacon() כדי לשלוח נתונים לשרת ב-handler של pagehide במקום ב-handler של unload.
<script>
function() {
window.addEventListener('pagehide', logData, false);
function logData() {
navigator.sendBeacon(
'https://putsreq.herokuapp.com/Dt7t2QzUkG18aDTMMcop',
'Sent by a beacon!');
}
}();
</script>
השיטה החדשה fetch() מספקת דרך קלה לבקש נתונים באופן אסינכרוני. מאחר שהתכונה עדיין לא זמינה בכל מקום, עליכם להשתמש בזיהוי תכונות כדי לבדוק את נוכחותה לפני השימוש. השיטה הזו מעבדת תגובות עם הבטחות במקום עם כמה גורמים מטפלים באירועים. בניגוד לתגובה ל-XMLHttpRequest, תגובת אחזור היא אובייקט סטרימינג שמתחיל ב-Chrome 43. כלומר, גם קריאה אל json() מחזירה Promise.
<script>
fetch('./api/some.json')
.then(
function(response) {
if (response.status !== 200) {
console.log('Looks like there was a problem. Status Code: ' + response.status);
return;
}
// Examine the text in the response
response.json().then(function(data) {
console.log(data);
});
}
)
.catch(function(err) {
console.log('Fetch Error :-S', err);
});
</script>
השיטה fetch() יכולה לטפל גם בבקשות POST.
<script>
fetch(url, {
method: 'post',
headers: {
"Content-type": "application/x-www-form-urlencoded; charset=UTF-8"
},
body: 'foo=bar&lorem=ipsum'
}).then(function() { // Additional code });
</script>
דחיית ניתוח JavaScript
כדי לצמצם את כמות העבודה שהדפדפן צריך לבצע על עיבוד הדף, עדיף לדחות סקריפטים לא חיוניים שאינם קריטיים לבניית התוכן הגלוי לעיבוד הראשוני.
הימנעות מ-JavaScript ממושך
JavaScript שפועל במשך זמן רב מונע מהדפדפן לבנות את ה-DOM , CSSOM ולעבד את הדף. לכן, צריך לדחות למועד מאוחר יותר כל לוגיקת אתחול ופונקציונליות שאינן חיוניות בעיבוד הראשון. אם צריך להריץ רצף אתחול ארוך, כדאי לפצל אותו לכמה שלבים כדי לאפשר לדפדפן לעבד אירועים אחרים ביניהם.
אופטימיזציה לשימוש ב-CSS
נדרש CSS כדי לבנות את עץ העיבוד, ובדרך כלל JavaScript חוסם ב-CSS במהלך הבנייה הראשונית של הדף. ודאו שכל שירות CSS שאינו חיוני מסומן כלא קריטי (לדוגמה, שאילתות דפוס ושאילתות מדיה אחרות), ושכמות ה-CSS הקריטית והזמן הנדרש לאספקתו הם קטנים ככל האפשר.
מקם CSS בראש המסמך
צריך לציין את כל משאבי ה-CSS בהקדם האפשרי בתוך מסמך ה-HTML, כדי שהדפדפן יוכל לגלות את תגי <link> ולשלוח את הבקשה ל-CSS בהקדם האפשרי.
הימנעות מייבוא של שירותי CSS
ההנחיה של ייבוא CSS (@import) מאפשרת לגיליון סגנונות אחד לייבא כללים מקובץ גיליון סגנונות אחר. עם זאת, עדיף להימנע מההנחיות האלה כי הן יוצרות פעולות דו-כיווניות נוספות לנתיב הקריטי: משאבי ה-CSS המיובאים מתגלים רק אחרי שגיליון הסגנון של ה-CSS עם הכלל @import עצמו מתקבל ומנותח.
CSS מוטבע לחסימת עיבוד
כדי להשיג את הביצועים הטובים ביותר, מומלץ להכניס את ה-CSS הקריטי ישירות למסמך ה-HTML. אפשרות זו מבטלת פעולות דו-כיווניות נוספות בנתיב הקריטי, ואם עושים זאת בצורה נכונה, ניתן לספק אורך נתיב קריטי 'האחד הלוך ושוב' שבו רק ה-HTML מהווה משאב חוסם.