最佳化指南
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本指南會針對安全性、效能與耗用量提供幾種最佳化 Google Maps API 用量的策略。
安全性
詳閱安全性最佳做法
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 用量。
避免在地圖移動時顯示重疊內容
在使用者可能會移動地圖的時候，請避免透過 Draw() 方法在地圖上顯示自訂疊加層內容。這是因為使用者每次移動地圖，系統就會重新整理；這時如果在該地圖上疊加內容，可能會產生動作延遲或視覺效果不流暢的情況。因此，請務必只在使用者已停止平移或縮放時，才新增或移除地圖上的疊加層內容。
避免以 Draw 方法進行大量作業
一般而言，建議盡量避免在 Draw() 方法中使用需要大量效能的非繪圖操作。舉例來說，請避免在 Draw() 方法程式碼中：
- 進行會傳回大量內容的查詢。
- 針對顯示中的資料執行大量變更。
- 操控許多文件物件模型 (DOM) 元素。
這些作業會降低效能，並在地圖算繪時造成延遲或視覺效果不流暢。
針對標記使用光柵圖片
新增標記時，可使用光柵圖片 (例如 .PNG 或 .JPG 格式的圖片) 在地圖上標示位置。請避免使用可擴充向量圖形 (SVG) 格式的圖片，因為在重新繪製地圖時算繪這種格式的圖片可能會導致延遲。
對標記進行最佳化處理
您可進行最佳化處理來將多個標記算繪為單一靜態元素，藉此提升效能；這個做法在需要使用大量標記時相當實用。根據預設，Maps JavaScript API 會決定是否對標記進行最佳化處理；若有大量標記，Maps JavaScript API 會嘗試在算繪標記時進行最佳化。不過，並不是所有的標記都能最佳化；在某些情況下，Maps JavaScript API 可能需要以不經最佳化處理的方式算繪標記。若您使用 GIF 動畫或 PNG 圖片，或是每一個標記都必須算繪成個別 DOM 元素，請停用最佳化算繪。
建立叢集以管理標記顯示方式
為協助您管理在地圖上用來標示位置的標記，請使用 Marker Clusterer 程式庫建立標記叢集。Marker Clusterer 程式庫提供下列選項：
- 格線大小 - 指定叢集中標記群組的數量。
- 最大縮放等級 - 指定顯示叢集時適用的最大縮放等級。
- 圖片路徑 - 要當做標記圖示使用的圖形圖片所在路徑。
觀看長片
如要瞭解如何管理 Google 地圖平台費用，包括建立預算、修改配額及設定快訊，請參閱「管理費用」。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-31 (世界標準時間)。
[null,null,["上次更新時間：2025-08-31 (世界標準時間)。"],[[["\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)."]]
