API 金鑰是以專案為主的憑證，應將其視為使用者 ID 和密碼，採取同等的安全防範措施。請詳閱 API 安全性最佳做法，避免因不小心誤用金鑰而不當耗用配額，導致帳戶產生非預期的費用。
使用 API 金鑰存取 Maps API
我們建議以 API 金鑰做為存取 Google Maps API 時的驗證方式。儘管目前仍支援使用用戶端 ID，但 API 金鑰能提供更精細的安全控管機制，且可搭配特定網址、IP 位址和 Mobile SDK (Android 和 iOS) 使用。如要瞭解如何建立及保護 API 金鑰，請前往各個 API 或 SDK 的「使用 API 金鑰」頁面 (例如，針對 Maps JavaScript API，請前往其使用 API 金鑰頁面)。
成效
採用指數輪詢策略來處理錯誤
如果您的應用程式在短時間內嘗試呼叫 API 的次數過多，導致發生錯誤 (例如配額錯誤)，不妨採用指數輪詢，以便系統處理要求。
指數輪詢最適合用於 500 層級錯誤。
具體來說，請調整查詢速度。在程式碼中新增每次查詢的間隔等候時間 (S 秒)；如果還是發生配額錯誤，請將等候時間延長一倍，再傳送下一個查詢。繼續調整等候時間，直到查詢未傳回錯誤為止。
隨需傳送使用者互動要求
內含使用者互動的 API 要求應隨需傳送；也就是說，等候使用者執行特定動作 (例如「on-click」) 來啟動 API 要求後，才根據結果載入地圖、設定目的地或顯示適當資訊。採用隨需模式可避免對 API 發出不必要的要求，從而降低 API 用量。
您可進行最佳化處理來將多個標記算繪為單一靜態元素，藉此提升效能；這個做法在需要使用大量標記時相當實用。根據預設，Maps JavaScript API 會決定是否對標記進行最佳化處理；若有大量標記，Maps JavaScript API 會嘗試在算繪標記時進行最佳化。不過，並不是所有的標記都能最佳化；在某些情況下，Maps JavaScript API 可能需要以不經最佳化處理的方式算繪標記。若您使用 GIF 動畫或 PNG 圖片，或是每一個標記都必須算繪成個別 DOM 元素，請停用最佳化算繪。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[[["\u003cp\u003eThis guide provides strategies for optimizing Google Maps APIs usage, focusing on security, performance, and cost management.\u003c/p\u003e\n"],["\u003cp\u003eSecure your API keys by reviewing security best practices and using them as the preferred authentication method.\u003c/p\u003e\n"],["\u003cp\u003eImprove performance by utilizing techniques like exponential backoff for error handling, sending user-interaction requests on demand, and optimizing marker display.\u003c/p\u003e\n"],["\u003cp\u003eManage costs by setting budget alerts, capping daily API usage, and strategically using different Google Maps Platform products based on your needs.\u003c/p\u003e\n"],["\u003cp\u003eUnderstand Google Maps Platform quotas and how they apply to your API usage to avoid unexpected limitations.\u003c/p\u003e\n"]]],["Optimize Google Maps APIs usage by securing API keys, using them instead of client IDs, and implementing exponential backoff for errors. Enhance performance by sending requests on demand, avoiding overlays during map movement, using raster images for markers, and optimizing/clustering markers. Control consumption by setting budget alerts, capping daily usage, using static images when user interaction isn't needed, using the embed API for basic maps, and using mobile SDKs for mobile. In addition, you can reduce costs with optimized routing, limited waypoints, and cost-effective autocomplete and geocoding options.\n"],null,["# Optimization Guide\n\nThis guide describes several strategies to optimize your Google Maps APIs\nusage in terms of security, performance, and consumption.\n\nSecurity\n--------\n\n### Reviewing security best practices\n\nAPI keys are project-centric credentials that deserve the same precautions\nas user IDs and passwords. Review the\n[API Security Best Practices](/maps/api-security-best-practices) to secure your keys from\nunintended use which could lead to undue quota usage and unexpected charges\nto your account.\n\n### Using API keys to access Maps APIs\n\nAPI keys are the preferred authentication method for accessing\nGoogle Maps APIs. While using the client IDs is still\nsupported, API keys support finer-grained security controls and can be tuned to\nwork with specific web addresses, IP addresses, and mobile SDKs (Android and\niOS). For information on creating and securing an API key, go to the \"Using an\nAPI Key\" page for each API or SDK. (For example, for the\nMaps JavaScript API, visit its page on [Using an API\nKey](/maps/documentation/javascript/get-api-key).)\n\nPerformance\n-----------\n\n### Using exponential backoff to handle errors\n\nIf your apps experience errors from excessive attempts to call an API\nwithin a short period of time, such as quota errors, consider using\n[exponential backoff](http://en.wikipedia.org/wiki/Exponential_backoff) to let the requests process.\nExponential backoff is most useful for errors in the 500s.\n\nSpecifically, adjust the pace of your queries. In your code, add\na waiting period of **`S`** seconds between queries. If the query still results\nin a quota error, double the waiting period and then send another query. Continue\nadjusting the waiting period until the query returns without an error.\n\n### Sending user-interaction requests on demand\n\nRequests to APIs that include user interaction should be sent only on demand.\nThis means waiting for the end user to perform an action (such as `on-click`)\nto initiate the API request, then using the results to load a map, set a\ndestination, or display appropriate information. Using an on-demand approach\navoids unnecessary requests to the APIs, reducing API consumption.\n\n### Avoiding displaying overlay content when a map is moving\n\nAvoid using `Draw()` to display custom overlay content on a map at the same\ntime that a user might be moving the map. Since the map is redrawn every time\na user moves the map, placing overlay content on the map at the same time can\nintroduce lag or visual stuttering. Only add or remove overlay content from a\nmap once the user stops panning or zooming.\n\n### Avoiding intensive operations in `Draw` methods\n\nAs a general rule, it is good practice to avoid performance-intensive\nnon-drawing operations in a `Draw()` method. For example, avoid\nthe following in your `Draw()` method code:\n\n- Queries that return a large amount of content.\n- Many changes to the data being displayed.\n- Manipulating many Document Object Model (DOM) elements.\n\nThese operations can slow performance and introduce lag or visual stuttering\nwhen the map renders.\n\n### Using raster images for markers\n\nUse raster images, such as images in .PNG or .JPG format, when adding\nmarkers to identify a location on a map. Avoid using Scalable Vector\nGraphics (SVG) images, since rendering SVG images can introduce lag when\nthe map is redrawn.\n\n### Optimizing markers\n\nOptimization enhances performance by rendering many markers as a single static\nelement. This is useful in cases where a large number of markers is required.\nBy default, the Maps JavaScript API will decide whether a marker\nwill be optimized. When there is a large number of markers, the\nMaps JavaScript API will attempt to render markers with\noptimization. Not all Markers can be optimized; in some situations, the\nMaps JavaScript API may need to render Markers without\noptimization. Disable optimized rendering for animated GIFs or PNGs, or when\neach marker must be rendered as a separate DOM element.\n\n### Creating clusters to manage marker display\n\nTo help manage the display of markers to identify locations on a map,\ncreate a marker cluster using the\n[Marker Clusterer](https://github.com/googlemaps/js-marker-clusterer) library.\nThe Marker Clusterer library includes options for:\n\n- Grid size, to specify the number of markers to group together in a cluster.\n- Maximum zoom, to specify the maximum zoom level in which to display the cluster.\n- Image paths, for the graphics images to use as marker icons.\n\nConsumption\n-----------\n\nFor information on managing your Google Maps Platform costs, including\ncreating budgets, modifying quotas, and setting alerts, see\n[Manage costs](/maps/billing-and-pricing/manage-costs)."]]
