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

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

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

אבטחה

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

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

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

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

ביצועים

שימוש בהשהיה מעריכית כדי לטפל בשגיאות

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

השהיה מעריכית היא השיטה השימושית ביותר לשגיאות בסגנון 500. מידע נוסף זמין במאמר טיפול בקודי סטטוס של החזרת HTTP.

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

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

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

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

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

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

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

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

פעולות אלה עלולות להאט את הביצועים ולהציג עיכובים או הפגנות חזותיות במהלך עיבוד המפה.

שימוש בתמונות של רשת נקודות עבור סמנים

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

אופטימיזציה של סמנים

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

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

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

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

צריכה

כדי לתכנן את התקציב ולשלוט בעלויות, מבצעים את הפעולות הבאות:

  • הגדירו התראת תקציב כדי לעקוב אחר הצטברות העלויות לקראת סכום מסוים. הגדרת תקציב לא מכסה את השימוש ב-API – היא מספקת התראות רק כשהעלויות מתקרבות לסכום שצוין.
  • ניתן להגביל את השימוש היומי ב-API כדי לנהל את העלויות של ממשקי API לחיוב. על ידי הגדרת מכסות לבקשות ליום, תוכלו להגביל את העלויות שלכם. יש להשתמש במשוואה פשוטה כדי לקבוע את המכסה היומית, בהתאם לסכום שרוצים להוציא: (עלות חודשית/מחיר לכל אחת )/30 = בקשות למכסה יומית (ל-API אחד). ההטמעה הספציפית עשויה לכלול מספר ממשקי API שניתנים לחיוב, לכן יש להתאים את המשוואה לפי הצורך. בכל חודש תקבלו קרדיט בסך 200$USD לממשקי Google Maps API, אז קחו זאת בחשבון.
  • אתם יכולים להשתמש בכמה פרויקטים כדי לבודד, לתעדף ולעקוב אחר השימוש. לדוגמה, נניח שאתם משתמשים באופן קבוע בממשקי ה-API של הפלטפורמה של מפות Google בבדיקות שלכם. יצירת פרויקט נפרד לבדיקה, עם מכסות ומפתחות API משלו, תאפשר לכם לבצע בדיקה יסודית תוך הגנה מפני הפתעה מיותרת.

ניהול הצריכה במפות

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

שימוש בתמונות סטטיות

בקשות שמשתמשות בתמונות דינמיות (מפות דינמיות ו-Street View) עולות יותר מאשר מפות סטטיות ו-Street View סטטיים. אם אתם לא צופים אינטראקציה של משתמש עם מפה או Street View (בזום או בסיבוב), השתמשו בגרסאות הסטטיות של ממשקי ה-API האלה.

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

באמצעות Maps embed API

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

שימוש בערכות SDK של מפות לנייד עבור אפליקציות לנייד

לאפליקציות לנייד, השתמשו ב-SDK של מפות ל-Android או ב-SDK של מפות ל-iOS בעת הצגת מפה. השתמשו ב-Maps Static API או ב-Maps JavaScript API כאשר הדרישות נשלטות באמצעות ערכות ה-SDK לנייד.

ניהול הצריכה במסלולים

הגבלת ציוני הדרך של ה-API של כיוונים

כשהדבר אפשרי, יש להגביל את ערכי המשתמשים בשאילתה ל-10 ציוני דרך לכל היותר. בקשות שכוללות יותר מ-10 ציוני דרך יחויבו בתעריף גבוה יותר.

שימוש באופטימיזציה של כיוונים API לצורך ניתוב אופטימלי

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

הארגומנט של האופטימיזציה ממיין את ציוני הדרך כדי להבטיח ניתוב אופטימלי, כלומר שהמעבר מ-A ל-E מספק חוויה טובה יותר מאשר במהלך אופטימיזציה (A-B-C-D-E) לעומת הרצף האקראי של מסלול שלא עבר אופטימיזציה (כמו A-D-B-C-E).

שימוש במודלים של תנועה בזמן אמת ב-DIRECTION API וב-DISTANCE Matrix API

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

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

שימוש במסלול שבו עברת והדרך הקרובה ביותר כשנתוני GPS לא מדויקים

התכונות של Maps Roads API, 'מסלול הנסיעה' ו'הכביש הקרוב ביותר', נכללות ברמה המתקדמת והחיוב שלהן גבוה יותר. השתמשו בתכונות האלה כאשר נתוני ה-GPS לא מדויקים וה-Roads API יכול לעזור לכם לזהות את הכביש המתאים. מגבלות מהירות, תכונה נוספת של Roads API, זמינות רק ללקוחות עם מעקב אחר נכסים.

דגימת מיקומים של מגבלות מהירות במרווחי זמן של 5-15 דקות

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

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

ניהול הצריכה במקומות

אופטימיזציה להטמעות של השלמה אוטומטית במקומות

כדי לבצע אופטימיזציה של עלות השימוש בהשלמה אוטומטית של מקומות:

  • להשתמש במסכות של שדות בווידג'טים של JavaScript ב-JavaScript, ב-Android וב-iOS כדי להחזיר רק את שדות נתוני המקום הדרושים.

  • בחירת אפשרויות החיוב תלויה בתרחיש לדוגמה. בהתאם להטמעה שלכם, אם נעשה שימוש בסשנים של השלמה או לא, תחויבו במק"טים של השלמה אוטומטית - לכל בקשה או השלמה אוטומטית - לכל ביקור.

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

החזרת נתונים עבור שדות ספציפיים ב'פרטי מקום' ובבקשות 'חיפוש מקום'

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

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

הפחתת עלויות באמצעות Geocoding API

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

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

הסבר על המכסות של הפלטפורמה של מפות Google

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

רק בקשות מוצלחות ובקשות שגורמות לשגיאות שרת נספרות כחלק מהמכסה. בקשות שנכשלו באימות לא ייספרו במכסה.

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

ממשקי ה-API של GMP שבהם בוצעה אכיפה בשנייה אחת הם DIRECTION API, DISTANCE Matrix API, Elevation API, Geocoding API, Places API ו-Roads API.

הערכת העלויות של כל מוצר ב-GMP API, על סמך נפח הבקשות הכולל.