מדריך אופטימיזציה

במדריך הזה מתוארות כמה אסטרטגיות לאופטימיזציה של השימוש ב-Google Maps API מבחינת אבטחה, ביצועים וצריכה.

אבטחה

בדיקת השיטות המומלצות לאבטחה

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

שימוש במפתחות API כדי לגשת לממשקי Maps API

מפתחות API הם שיטת האימות המועדפת לגישה לממשקי Google Maps API. אפשר עדיין להשתמש במזהי לקוח, אבל מפתחות API תומכים באמצעי בקרה מפורטים יותר על האבטחה, ואפשר להתאים אותם לעבודה עם כתובות אינטרנט ספציפיות, כתובות IP וערכות SDK לנייד (Android ו-iOS). כדי לקבל מידע על יצירה ואבטחה של מפתח API, עברו לדף "שימוש במפתח API" של כל API או SDK. (לדוגמה, ל-Maps JavaScript API, היכנסו לדף שימוש במפתח API).

ביצועים

שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) לטיפול בשגיאות

אם באפליקציות שלכם יש שגיאות שנובעות מניסיונות רבים מדי לשלוח קריאה ל-API בפרק זמן קצר, כמו שגיאות שקשורות למכסות, כדאי להשתמש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לאפשר את עיבוד הבקשות. השהיה מעריכית לפני ניסיון חוזר (exponential backoff) שימושית בעיקר לשגיאות בטווח של 500.

באופן ספציפי, צריך להתאים את קצב השאילתות. בקוד, מוסיפים תקופת המתנה של S שניות בין השאילתות. אם השאילתה עדיין גורמת לשגיאת מכסה, מכפילים את תקופת ההמתנה ואז שולחים שאילתה נוספת. ממשיכים לשנות את תקופת ההמתנה עד שהשאילתה חוזרת בלי שגיאה.

שליחת בקשות לאינטראקציה עם המשתמשים לפי דרישה

צריך לשלוח בקשות לממשקי API שכוללים אינטראקציה של המשתמש רק על פי דרישה. כלומר, צריך להמתין עד שמשתמש הקצה יבצע פעולה (כמו on-click) כדי להתחיל את בקשת ה-API, ואז להשתמש בתוצאות כדי לטעון מפה, להגדיר יעד או להציג מידע מתאים. שימוש בגישה על פי דרישה מונע בקשות מיותרות לממשקי ה-API, ומפחית את צריכת ה-API.

הימנעות מהצגת תוכן בשכבת-על כשהמפה זזה

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

הימנעות מפעולות אינטנסיביות בשיטות של Draw

ככלל, מומלץ להימנע מפעולות שאינן קשורות לציור ודורשות ביצועים גבוהים בשיטת Draw(). לדוגמה, הימנעו מהפעולות הבאות בקוד של השיטה Draw():

• שאילתות שמחזירות כמות גדולה של תוכן.
• שינויים רבים בנתונים שמוצגים.
• שינוי של הרבה רכיבי Document Object Model ‏ (DOM).

הפעולות האלה עלולות להאט את הביצועים ולגרום להשהיה או לריצוד חזותי בזמן עיבוד המפה.

שימוש בתמונות רסטר לסמנים

כשמוסיפים סמנים כדי לזהות מיקום במפה, צריך להשתמש בתמונות רסטר, כמו תמונות בפורמט PNG או JPG. הימנעו משימוש בתמונות בפורמט Scalable Vector Graphics ‏ (SVG), כי רינדור של תמונות SVG עלול לגרום לעיכוב כשהמפה משורטטת מחדש.

מתבצעת אופטימיזציה של חומרי ההדפסה

האופטימיזציה משפרת את הביצועים על ידי עיבוד של סמנים רבים כרכיב סטטי אחד. האפשרות הזו שימושית במקרים שבהם נדרש מספר גדול של סמנים. כברירת מחדל, Maps JavaScript API יקבע אם תתבצע אופטימיזציה של סמן. כשיש מספר גדול של סמנים, Maps JavaScript API ינסה להציג אותם בצורה אופטימלית. לא את כל הסמנים אפשר לשפר. במצבים מסוימים, יכול להיות ש-Maps JavaScript API יצטרך לרנדר סמנים בלי אופטימיזציה. השביתו את העיבוד המותאם לקובצי GIF מונפשים או PNG, או כשצריך לעבד כל סמן כרכיב DOM נפרד.

יצירת אשכולות לניהול התצוגה של סמנים

כדי לנהל את התצוגה של סמנים לזיהוי מיקומים במפה, אפשר ליצור מקבץ סמנים באמצעות הספרייה Marker Clusterer. הספרייה Marker Clusterer כוללת אפשרויות ל:

• גודל הרשת, כדי לציין את מספר הסמנים שצריך לקבץ יחד באשכול.
• ‫Maximum zoom (מרחק התצוגה המקסימלי), כדי לציין את רמת הזום המקסימלית שבה יוצג האשכול.
• נתיבי תמונות, לתמונות הגרפיות שישמשו כסמלי סמנים.

צריכה

במאמר ניהול עלויות מוסבר איך לנהל את העלויות ב-Google Maps Platform, כולל יצירת תקציבים, שינוי מכסות והגדרת התראות.