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

במדריך הזה מתוארות כמה אסטרטגיות לאופטימיזציה של השימוש בממשקי 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) שימושית במיוחד לשגיאות בטווח 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 כוללת אפשרויות ל:

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

צריכה

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