כשאתם מתחילים לשים לב שכרום איטי בתשתית ה-VDI שלכם, צורך יותר מדי זיכרון RAM, או מגביר את ניצול המעבד , לא רק חוויית המשתמש סובלת: חשבונות השרת, הרישיון והרשת שלכם מרקיעים שחקים. בסביבות עם עשרות או מאות שולחנות עבודה וירטואליים, כל כרטיסייה נוספת וכל מגה-בייט שמנוהל בצורה גרועה מוכפלים בכל המשתמשים המחוברים.
זו הסיבה שזה הגיוני לחלוטין לבצע ביקורת רצינית של ביצועי Chrome ואופטימיזציה ב-VDI עם דגש על הפחתת עלויות . זה לא רק עניין של "להפוך אותו למהיר יותר", אלא של הבנת מה קורה, מדידת זה בעזרת הכלים הנכונים (DevTools, Lighthouse, PageSpeed, ניתוח נתונים, מדדי שרת וכו'), ויישום מדיניות טכנית ומדיניות שימוש שמצמצמת את צריכת המשאבים מבלי לפגוע בפריון העובדים.
מדוע ביצועי Chrome ב-VDI משפיעים ישירות על העלויות שלך
ברשת, ראינו במשך שנים כיצד כמה מאות מילישניות יכולות לעשות הבדלים עצומים בעסקים : חברות גדולות מדדו ירידות במכירות או בתנועה פשוט מעלייה קלה בזמן ההשהיה של הדף שלהן. משהו דומה קורה ב-VDI, אבל בקנה מידה שונה: כל האטה, כל טאב שקופא, מתורגם ליותר CPU וזיכרון לכל משתמש, יותר שרתים, יותר רישיונות ויותר רוחב פס.
בינתיים, במחשב שולחני פיזי, המשתמש נושא כמעט בכל עלות הביצועים במחשב שלו. עם זאת, בתשתית שולחן עבודה וירטואלי, כל המשאבים הללו מגיעים ממאגר משותף במרכז הנתונים . דפדפן כרום לא ממוטב על 100 שולחנות עבודה יכול לאלץ אותך להגדיל את חוות ה-VDI שלך, לשלם יותר עבור אחסון, לחתום על קיבולת רשת גדולה יותר ואפילו להשקיע במעבדים גרפיים אם אתה רוצה ניגון וידאו חלק.
יתר על כן, גם מהירות יישומי האינטרנט שנפתחים בתוך כרום משפיעה. אתר אינטרנט כבד, עם תמונות רבות ו-JavaScript מיותר , לא רק מתסכל את המשתמש אלא גם פירושו שימוש גבוה יותר במעבד, יותר זיכרון ויותר רוחב פס עבור כל סשן VDI. אופטימיזציה של אתרים ואפליקציות אינטרנט, לא רק הדפדפן, היא חלק מרכזי במשוואת העלות.
יתר על כן, מנועי חיפוש נותנים עדיפות גוברת לביצועים. אם גם לאפליקציות האינטרנט הפנימיות שלכם יש גרסה ציבורית, ביקורת ביצועים יסודית וקידום אתרים טכני יעזרו לשפר את הדירוג שלכם, למשוך יותר תנועה איכותית ולמקסם את התשואה על השקעת הפיתוח.
יסודות VDI ויצירת פרופיל משאבים עבור Chrome
תשתית שולחן עבודה וירטואלי היא למעשה אוסף של שולחנות עבודה של Windows (או מערכות הפעלה אחרות) הפועלים על שרתים מרכזיים , נגישים כמעט מכל מכשיר דרך רשת. במקום שמערכת ההפעלה והאפליקציות יהיו מותקנות על מחשב המשתמש, הן מתארחות במרכז הנתונים, בין אם מקומי או בענן.
במודל זה, כל סשן משתמש הוא מכונה וירטואלית או שולחן עבודה שפורסם ומתחרה על משאבי שרת: זיכרון RAM, vCPU, דיסק, רשת ואפילו GPU אם זמין. כרום, בשל הארכיטקטורה מרובת התהליכים שלו ושימוש אינטנסיבי בזיכרון, הוא לעתים קרובות אחד הרכיבים התובעניים ביותר, במיוחד בשילוב עם אתרים עתירי משאבים, כרטיסיות פתוחות רבות ותוספים שגוי ממוטבים.
כקו מנחה מעשי, ספק הדפדפן עצמו ממליץ על כ -1 ג'יגה-בייט של זיכרון RAM ובין 2 ל-4 מעבדי וירטואליים (vCPU) לכל שולחן עבודה וירטואלי לצורך ביצועי VDI חלקים . משמעות הדבר היא שאם ברצונך לשרת 100 משתמשים בו זמנית, עליך לתכנן לפחות 100 ג'יגה-בייט של זיכרון RAM ו-200 מעבדי וירטואליים. אם לא תגדיר את המשאבים שלך כראוי, כרום יתחיל להשהות, הפעלות ייפגעו וחוויית המשתמש הכוללת תהיה גרועה.
לפני שצוללים לאופטימיזציה, מומלץ לעשות סקירה כללית: איזו גרסה של Chrome נמצאת בשימוש, אילו תוספים מותקנים, אילו סוגי אתרים מבקרים בתדירות הגבוהה ביותר, כיצד מנהלים פרופילי משתמשים ואיזו חומרה פועלת . תמונה ראשונית זו חיונית למיקוד הביקורת ולהשוואת שיפורים בהמשך.
שיטות עבודה מומלצות להגדרת VDI עבור Chrome
השכבה הראשונה של האופטימיזציה כוללת תכנון נכון של סביבת ה-VDI עצמה כך של-Chrome יהיה את מה שהוא צריך, אך מבלי לבזבז משאבים. זה כרוך הן בקיבולת השרת והן בהחלטות שונות בנוגע לאדריכלות ולמדיניות קבוצתית.
זיכרון שרת ומעבד
יחס המשתמש ל-VDI-מארח בר קיימא רק אם מכבדים תנאים מסוימים... הקצאות RAM ו-vCPU מינימליות לכל שולחן עבודה וירטואליאין טעם לנסות להכניס 200 שולחנות עבודה לשרת עם זיכרון מוגבל: בסופו של דבר תצטרכו להחליף נתונים, לבעיות השהייה משמעותיות ולמשתמשים שיתקשרו לתמיכה כל הזמן. התאם את מספר שולחנות העבודה לכל מחשב שרת בהתבסס על:
- זיכרון RAM זמין בשרת וזיכרון ממוצע הנצרך לכל סשן של Chrome.
- מעבדי vCPU פיזיים ורישום יתר מקובל בהתאם להיפר-ויזור שלך.
- דפוסי שימוש: אם משתמשים מבצעים הרבה סטרימינג, ניתוח נתונים או שיחות וידאו, הם יזדקקו ליותר משאבים.
נוהג שימושי הוא להשתמש במנהל המשימות ובמדדי ההיפר-ויזור של כרום כדי להשוות את ביצועי ההפעלות של הארגון שלך מול קבוצת דפי עזר, וכך להעריך טוב יותר את השימוש בפועל.
האצת חומרה ו-GPU
לשרתי VDI רבים אין מעבדי גרפיקה ייעודיים, או שהם שמורים לעומסי עבודה גרפיים ספציפיים מאוד. במקרים אלה, אם תשאיר את האפשרות מופעלת... "השתמש בהאצת חומרה כאשר היא זמינה"ייתכן שתיתקל בהתנהגות מוזרה, ניצול CPU גבוה מהצפוי או בבעיות יציבות.
הפתרון ברור: נהל אפשרות זו דרך מדיניות קבוצתית . בעורך ניהול מדיניות קבוצתית של Windows, השבת את האצת החומרה של Chrome כאשר לשרת אין מעבדי גרפיקה מתאימים. פעולה זו מונעת מהדפדפן לנסות להסתמך על האצת גרפיקה שאינה קיימת בפועל או שאינה ממוטבת עבור VDI.
ניהול הרחבות קפדני
תוספי כרום הם נוחים להפליא, אבל הם גם אחד המקורות העיקריים לבזבוז זיכרון וזמן אתחול.בשולחנות עבודה וירטואליים, מתן אפשרות לכל משתמש להתקין את כל מה שהוא רוצה מהווה מקור לבעיות וצריכת משאבים מוגזמת.
הגישה הנבונה ביותר היא להגדיר מדיניות הרחבות ארגונית: רשימה לבנה של הרחבות מותרות, חסימה של השאר ובדיקה סדירה . לעתים קרובות תגלו תוספים עם פונקציונליות כפולה או כאלה שכבר אינם נחוצים. קונסולת הניהול של Chrome ומדיניות האפליקציות וההרחבות של Windows הן בעלות הברית שלכם בשמירה על סביבה נקייה וצפויה.
פרופילי משתמשים נודדים וסנכרון
ב-VDI, חוויית המשתמש נפגעת אם בכל פעם שהם מתחברים, הכל מתנהג כמו "כרום שהותקן טרי". כדי להימנע מכך, ניתן לסמוך על... פרופילי משתמשים נודדים וסנכרון מנוהל של Chromeאשר מאפשרים לך לשמור סימניות, היסטוריה והגדרות מסוימות בין הפעלות לשולחנות עבודה.
חשוב מאוד לפעול לפי המלצות גוגל לסנכרון פרופילים וגרסאות . אם תשתמשו שוב באותו פרופיל עם גרסאות דפדפן ישנות וחדשות יותר, אתם עלולים להיתקל בבסיסי נתונים פגומים, שגיאות התחברות או התנהגות לא עקבית. הימנעו תמיד משדרוג לאחור במחשבים שולחניים שחולקים פרופילים, ואם אינכם משתמשים בשיטות המומלצות, שימו לב היטב לתאימות קדימה.
המלצות שימוש למשתמשים בסביבות VDI
לא משנה כמה טוב תכווננו את ההיבטים הטכניים, להתנהגות היומיומית של המשתמשים יש השפעה עצומה על הביצועים הכוללים . ב-VDI, הרגל רע כפול 300 איש הופך לאסון. כדאי להשקיע זמן בהכשרה ובהסברת משתמשים.
ההמלצה הראשונה והברורה ביותר היא להגביל את מספר הכרטיסיות. ככל שיותר כרטיסיות פעילות, כך משתמשים ביותר תהליכי Chrome ויותר זיכרון ומעבד לכל משתמש. בקשו מהצוות שלכם לסגור את כל הכרטיסיות שהם לא משתמשים בהן בפועל. לפעמים, רק העלאת המודעות והצגת נתונים מספיקים כדי לגרום לאנשים לשנות את ההרגל של 40 כרטיסיות פתוחות "למקרה הצורך".
אמצעי יעיל נוסף הוא שימוש בתוספים שמשהים כרטיסיות לא פעילות. כלים ש"מעבירים למצב שינה" כרטיסיות שהיו פעילות במשך זמן מה מפנים זיכרון מבלי שהמשתמש יאבד תוכן, מכיוון שהוא נטען מחדש כשהוא חוזר לכרטיסייה. עם זאת, הקפידו לבחור תוסף אמין ומתוחזק היטב העומד במדיניות הפרטיות שלכם, ולהפיץ אותו באופן מרכזי.
חשוב גם לחנך משתמשים לגבי שימוש אחראי בשירותי סטרימינג (וידאו, מוזיקה וכו') וכיצד לשפר את איכות שיחות הווידאו שלהם מ-VDI. קבוצת משתמשים שצופים בו זמנית ביוטיוב, משתמשים בפלטפורמות וידאו לפי דרישה ומבצעים שיחות וידאו עלולה להעמיס הן על רוחב הפס של השרת והן על המעבד, במיוחד אם אינכם משתמשים בכרטיס מסך (GPU). הגדירו בבירור במדיניות הארגונית שלכם אילו שימושים מותרים ובאילו תנאים, ושקלו חלופות, כגון הפעלת תוכן ישירות במכשיר המקומי במידת הצורך.
ביקורת ביצועי אינטרנט עם DevTools ולוח מחוונים לביקורת
כרום כולל כלים מובנים רבי עוצמה לניתוח ושיפור ביצועי יישומי אינטרנט הפועלים בדפדפן . למרות שהם מקושרים לעתים קרובות לפיתוח טהור, כלים אלה חיוניים גם בסביבת VDI, מכיוון שאתר אינטרנט איטי פירושו צריכת משאבים גבוהה יותר לכל הפעלה.
הצעד הראשון הוא להכיר את כלי המפתחים (DevTools) . ניתן לפתוח אותם מתפריט הדפדפן (כלים > כלי מפתחים) או באמצעות קיצורי הדרך הרגילים. בין הפאנלים שלהם, תמצאו את הפאנלים Audits או Lighthouse , המאפשרים לכם להריץ ניתוחים אוטומטיים של ביצועים, נגישות, שיטות עבודה מומלצות והיבטים אחרים.
כשמפעילים ביקורת ביצועים, הדף נטען מחדש עם היוריסטיקות שונות מופעלות, ו-Lighthouse מחזיר דוח עם המלצות מדורגות לפי חומרה , בדרך כלל מקודדות בצבע (אדום לבעיות חמורות, צהוב לבעיות בעדיפות בינונית). כל המלצה מציינת גם כמה פעמים הבעיה זוהתה בדף.
המטרה היא להשתמש בדוח זה כנקודת התחלה כדי לתעדף שיפורים טכניים באתרי האינטרנט ובאפליקציות האינטרנט שלכם : משאבים שאינם מאוחסנים במטמון, תמונות גדולות מדי, JavaScript שחוסם טעינה, CSS שאינו בשימוש וכו'. אם לחברה שלכם יש אפליקציות פנימיות אליהן ניתן לגשת דרך Chrome ב-VDI, הפעלת Lighthouse עליהן ופתרון הבעיות החמורות ביותר היא אחת ההשקעות הטובות ביותר שתוכלו לעשות כדי להפחית את צריכת המעבד, הזיכרון RAM ורוחב הפס.
אסטרטגיות מפתח: רשת, מטמון, משאבים וסדר טעינה
ביקורות ביצועים בדרך כלל מקבצות את הצעותיהן לשתי קטגוריות עיקריות: שימוש ברשת וביצועי דפים . שני ממדים אלה משפיעים על עלות הצגת האפליקציה שלך בסביבת VDI.
בסעיף הרשת, המלצות אופייניות כוללות:
- נצל את מטמון הדפדפן כדי למנוע פריקות חוזרות ונשנות.
- השתמש במטמון פרוקסי או ב-CDN במידת האפשר.
- הקטן את גודל העוגיות כדי לייעל כל בקשה.
- הצגת תוכן סטטי מדומיינים ללא קובצי Cookie.
- ציינו מידות בתמונות כדי להפוך את הפריסה לחיזוי יותר.
בצד הדף, היבטים מרכזיים כוללים אופטימיזציה של סדר הטעינה של CSS ו-JavaScript , טעינה אסינכרונית או דחייתית של אלמנטים שאינם קריטיים, והסרת כללי CSS וקוד JavaScript שאינם בשימוש . כל עודף שניתן לקצץ פירושו פחות קילובייט להורדה, פחות ניתוח, פחות ביצוע, ובסופו של דבר, פחות מעבד וזיכרון שנצרכו על ידי Chrome בכל שולחן עבודה וירטואלי.
ראוי לזכור שרבות מההמלצות הללו הן שיטות עבודה מומלצות כלליות לפיתוח אתרים , אך ב-VDI יש להן השפעה כלכלית נראית לעין יותר: אם תצמצמו את גודל הדפים שלכם ואת מספר הבקשות, תצמצמו את חשבון הפרסום שלכם, את רוחב הפס של הרשת ואפילו את עלויות האחסון והאחסון במטמון של השרת האחורי.
התעמקות במטמון הדפדפן והרשת
אחד ההיבטים היעילים ביותר מבחינת עלות הוא מקסום אחסון במטמון HTTP . אם משאב סטטי (כמו תמונה, CSS או סקריפט) משתנה מעט מאוד, אין טעם שהדפדפנים בכל שולחנות העבודה הווירטואליים שלך יורידו אותו בכל ביקור. בעזרת הכותרות הנכונות, תוכל להורות להם לאחסן אותו באופן מקומי לפרק זמן מסוים.
פרוטוקול HTTP מגדיר הנחיות כגון Cache-Control, Expires ו-ETag המאפשרות לך לשלוט במשך הזמן שבו משאבים מאוחסנים וכיצד הם מאומתים. לדוגמה, תוכל להורות ללקוחות לא לבקש קובץ שוב במשך מספר ימים או שבועות, או לבצע שאילתה לשרת כדי לראות אם הוא השתנה לפני הורדת הקובץ כולו.
כדי לאבחן בעיות במטמון, ניתן להשתמש בחלונית הרשת של DevTools: על ידי לחיצה על משאב, תראו את כותרות הבקשה והתגובה . אם אתם רואים כותרות כמו "Cache-Control: no-cache" או היעדר מוחלט של מדיניות תפוגה במשאבים סטטיים בבירור, כבר יש לכם מושג מדוע האתר שלכם מייצר כל כך הרבה תנועה בכל טעינה.
הפתרון כרוך בהתאמת תצורת השרת או מסגרת האפליקציה על ידי הוספת כותרות Expires ו-Cache-Control עם ערכי גיל מקסימליים מתאימים עבור המשאבים שברצונך לאחסן במטמון. זה מפחית את התעבורה בביקורים עוקבים, משפר את זמני הטעינה, וב-VDI, אומר פחות עומס על הרשת והמעבד לכל שולחן עבודה.
רישום וניתוח של בקשות משאבים
כדי לבצע ביקורת ביצועים יסודית, לא מספיק להסתכל על דוח בודד. כדאי מאוד לתעד באופן שיטתי בקשות למשאבים : כמה יש, איזה סוג, מה גודל ומתי הן נענו.
לוח הרשת של הדפדפן מאפשר לך לראות במבט חטוף את גודל הדף הכולל, מספר הקבצים ופירוט לפי סוג (תמונות, סקריפטים, גיליונות סגנונות, גופנים וכו'). לפני ביצוע שינויים כלשהם, מומלץ להשבית את המטמון (או להשתמש בחלון גלישה בסתר) כדי למדוד את העומס הראשוני בפועל. לאחר מכן, תוכל לשמור את הפרופיל בקובץ JSON או בצילום מסך פשוט להשוואה.
כמה מדדים מרכזיים שכדאי לעקוב אחריהם הם:
- משקל העמודים הכולל ומספר הבקשות.
- גודל וכמות של קוד JavaScript, וסקריפטים בודדים מעל סף מסוים (למשל, 100 KB).
- קוד JavaScript ו-CSS לא בשימוש, ניתן לזיהוי באמצעות כלי הכיסוי של כרום.
- גודל ומספר התמונות, הפורמטים שבהם נעשה שימוש (PNG, JPEG, WebP, SVG) והאם מיושמות טכניקות רספונסיביות.
- שימוש במשאבים נוספים כגון גופני אינטרנט, גופני אייקונים, סרטונים וכו'.
בסביבות עם קישוריות טובה, קל ליפול למלכודת של לחשוב "זה נטען מהר וזהו". עם זאת, סימולציה של חיבורים ניידים איטיים או בעלי השהייה גבוהה עוזרת להבין כיצד האפליקציה תתנהג עבור משתמשים מרוחקים או ברשתות עמוסות, דבר נפוץ מאוד כאשר הפעלות VDI מתחברות מאתרים עם רוחב פס WAN מוגבל.
תמונות, משקל עמוד וניצולת זיכרון
ברוב האתרים, תמונות הן ללא ספק התורם הגדול ביותר לגודל הקובץ הכולל ולמספר הבקשות . מלבד הורדתן דרך הרשת, יש צורך לפענח ולעבד אותן, מה שצורך זיכרון ומעבד. בטלפונים ובמכשירים פשוטים, הן יכולות להוות צוואר בקבוק; בסביבות VDI, כאשר הן מוכפלות על פני כל הסשנים, הן יכולות לדחוף את זיכרון ה-RAM של השרת עד לקצה גבול היכולת שלו.
המתכון הבסיסי לאופטימיזציה של תמונות כולל:
- הסר תמונות מיותרות או פריטי נוי שלא תורמים דבר.
- צמצמו את ממדי הפיקסלים למה שבאמת נחוץ לעיצוב.
- הגברת הדחיסה ולבחור פורמטים יעילים (למשל, JPEG במקום PNG במידת האפשר, או WebP עם גיבוי).
- טעינה עצלנית של תמונות שאינן נראות במסך הראשון.
דפוס נפוץ הוא היתקלות בתמונות ברוחב אלפי פיקסלים המוצגות במיכל קטן . התוצאה היא בזבוז משאבים עצום: קבצים בגודל של מאות קילובייט, אשר לאחר פירוק הדחיסה יכולים לתפוס כמה מגה-בייט של זיכרון RAM בכל כרטיסייה. שינוי גודלם ודחיסתם מחדש יכולים להשיג הפחתות גודל של 90% או יותר, עם השפעה ישירה על הביצועים הנתפסים וצריכת המשאבים.
כדי לזהות מקרים אלה, פשוט מיין את בקשות הרשת לפי גודל ובחן את התמונות הגדולות ביותר. משם, כלי אופטימיזציה של תמונות ותהליך עבודה לפרסום שמעבד אותן באופן אוטומטי יעזרו לך לשמור על גודל הקבצים תחת שליטה.
כלי מעבד, זיכרון ויצירת פרופילים
מעבר לרשת, צוואר בקבוק עיקרי נוסף, במיוחד במובייל וב-VDI, הוא עומס המעבד וניצול הזיכרון . JavaScript כבד, DOMs ענקיים, אנימציות מורכבות וספריות כפולות מתורגמים ישירות לעומס עבודה מוגבר על השרת.
כרום מספק מספר כלים למדידת היבטים אלה. מנהל המשימות של הדפדפן מאפשר לך לראות כמה כל כרטיסייה ותוסף צורכים. פרופילי ביצועים וזיכרון ב-DevTools מציעים פרטים נוספים על אילו חלקים בקוד משפיעים לרעה על חוויית המשתמש.
כמה שיטות עבודה מומלצות למניעת עלייה חדה בניצול המעבד והזיכרון הן:
- צמצום ג'אווה סקריפט מיותרהן בגודל והן במורכבות.
- הימנעו מטעינת אותה ספרייה בכמה גרסאות שונות.
- שמור על גודל ה-DOM סביר, ללא צמתים יתומים או מבנים עמוקים באופן אבסורדי.
- השתמש בטכניקות פיצול קוד וטעינה עצלה עבור מודולים שאינם נחוצים בעת האתחול.
ב-VDI, כל זה מורגש מיד: ככל שהממשק הקדמי שלך קל ויעיל יותר, כך תוכל לשרת יותר משתמשים בכל מארח עם אותה חומרה, וכך פחות סביר ש-Chrome "יאכל" את הזיכרון הזמין.
ביקורת SEO עם Lighthouse לאתרי אינטרנט עסקיים
בעוד שמאמר זה מתמקד בביצועי VDI ובעלויות שלו, חשוב לזכור שניתן להשתמש בכלי ביקורת רבים גם כדי לבחון היבטים בסיסיים של SEO באתרי האינטרנט הציבוריים שלכם. Lighthouse כולל קטגוריית ביקורת SEO ספציפית שבודקת אלמנטים חיוניים עבור מנועי חיפוש.
בדיקות אלו אינן ערובה לדירוג מושלם, וגם לא מתכוונות לכסות את כל טכניקות ה-SEO הקיימות. מטרתן היא לאמת שהדף שלך עומד בשורה של דרישות בסיסיות , כגון נוכחות של תגיות מטא, מאפייני תמונה חלופיים, מבנה כותרת קוהרנטי, קישורים הניתנים לאינדקס וכו'.
ניתן לבצע ביקורות אלו בשתי דרכים:
- עם תוסף Lighthouse עבור Chrome, בחירת קטגוריית קידום אתרים (SEO) ויצירת הדוח.
- מ כלי פיתוח (ביקורות) בדפדפנים מבוססי כרום שמשלבים אותו.
לאחר שתקבלו את הדוח, תראו אילו אלמנטים בסיסיים אתם עומדים בהם ואילו עליכם לשפר. עבור פרויקטים חדשים או צוותים שאינם מומחי קידום אתרים, זוהי דרך מהירה לוודא שאתם לא עושים טעויות "מתחילות" שמגבילות את הנראות שלכם במנועי חיפוש.
מדדים עסקיים, אנליטיקה ובדיקות בעולם האמיתי
הביקורת הטכנית היא רק חלק אחד מהעבודה. כדי לדעת אם השינויים שלכם כדאיים, אתם זקוקים למדדים מהעולם האמיתי: טכניים ועסקיים כאחד . ללא נתונים, אי אפשר להדגים להנהלה שאופטימיזציה של Chrome ב-VDI ואתרי האינטרנט הארגוניים שלכם חוסכת כסף.
בצד הטכני, ניתן למנף ממשקי API כמו תזמון הניווט או PerformanceObserver כדי לתעד זמני טעינה, השהיית אינטראקציה ואירועים רלוונטיים אחרים. לאחר מכן ניתן לשלוח נתונים אלה למערכת האנליטיקה שלך (למשל, גוגל אנליטיקס) כאירועים מותאמים אישית ולהצליב אותם עם מדדים כגון שיעור המרה, נטישה ועוד.
מנקודת מבט עסקית, חשוב לנטר מדדים כגון שיעורי יציאה מדף (bounce rates), זמן בדף, המרות, הזמנות לדקה ושימוש בשרתים האחוריים (backend) . אם, לאחר סבב אופטימיזציות, תראו שזמני טעינה מתקצרים וההמרות עולות, יש לכם סיבה טובה להמשיך להשקיע בשיפורי ביצועים.
ב-VDI, כדאי גם לאסוף מדדי שרת: צריכת CPU וזיכרון ממוצעת לכל מחשב מארח, מספר משתמשים בו זמנית לכל שרת, רוחב פס של הרשת וכו'. השוואת ערכים אלה לפני ואחרי החלת מדיניות הרחבה, אחסון במטמון, אופטימיזציית משאבים והדרכת משתמשים תעזור לכם לכמת את החיסכון בפועל.
הקלטת מסך והדגמת שיפורים
בנוסף למספרים, ראיות חזותיות משכנעות מאוד: הקלטות מסך, סרטוני טעינת דפים וצילומי סרטונים . הצגת התנהגות המערכת למנהלים לפני ואחרי אופטימיזציה שווה לעתים קרובות יותר ממאה שקופיות.
ניתן להשתמש בכלי הקלטה למחשב או למכשירים ניידים כדי להקליט את טעינת היישומים המרכזיים שלכם, ולהוסיף נקודת זמן (כגון טיימר על המסך) במידת הצורך. שמירת הקלטות אלו תאפשר לכם להדגים בבירור לצוותים אחרים ולהנהלה את ההבדל בחוויית המשתמש לאחר ביקורת ביצועים יסודית.
גישה זו שימושית במיוחד כאשר רוצים להצדיק יוזמות כמו הגבלת הרחבות, שינוי מדיניות סטרימינג, השקעה ב-CDN או הקדשת זמן פיתוח לעיבוד מחדש של JavaScript כבד . ראיית האופן שבו דף משתנה מחמש שניות לפחות משנייה להצגה מסייעת רבות בקבלת החלטות.
בסופו של דבר, ביקורת ואופטימיזציה טובים של ביצועי Chrome ב-VDI משלבים התאמות תשתית, מדיניות שימוש, שיפורים עמוקים באתרי האינטרנט ובאפליקציות האינטרנט שלכם, ושכבה של מדידה מתמדת עם כלים כמו DevTools, Lighthouse, PageSpeed או ניתוחי עסקים משלכם; עבודה על כל החזיתות הללו בו זמנית מאפשרת לכם לשרת יותר משתמשים עם פחות משאבים, להציע הפעלות חלקות יותר, ומעל הכל, לקצץ בעלויות סביבת ה-VDI שלכם מבלי לפגוע באיכות החוויה.
