IssueTracker

Thank you for posting.

We are currently looking into this and will get back to you as soon as we have an update.

Thank you for posting.

The issue has been logged internally. Please note that we cannot give you any timelines, but you can star the issue to get notifications when the fix is released.

According to Google Support, Autocomplete (NEW) Requires BOTH: Places (New) API + Places Legacy to be enabled (who knows why?) -- I was instructed to enable Legacy by going to: https://console.cloud.google.com/apis/library/places-backend.googleapis.com

Once that is enabled, the Autocomplete element worked as expected when using their Sample code: https://developers.google.com/maps/documentation/javascript/examples/place-autocomplete-element

Just to clarify: the issue is not specific to Vue or React. If you want to use a Places Autocomplete widget UI, there are two options:

• The Preview Autocomplete widget. This widget requires the alpha version of the Maps JavaScript API, and uses the Places (New) API. This is a Preview version which is not suitable for production use
• The GA Autocomplete widget, which uses the Places API (Legacy) service.

Given that the new API does not yet support an Autocomplete widget as a GA feature, it is appropriate to enable the Legacy API in this case. The link to enable the Legacy API is https://console.cloud.google.com/apis/library/places-backend.googleapis.com .

Once the new Autocomplete widget is GA, and the frameworks of your choice support them, it is recommended to migrate to the new Autocomplete widget.

We'll be updating the docs shortly to clarify this. Sorry for the confusion!

Re: #7, Have you tried the direct link https://console.cloud.google.com/apis/library/places-backend.googleapis.com ?

Thanks for the report #10 - would you mind filing a support case with the issue you have experienced when enabling both APIs? That is definitely not expected and not a known issue. Thanks!

Perhaps Legacy markers should not be marked Deprecated if they are a valid long term option and new markers are not yet viable/ready? Deprecation causes issues/warnings with linters and static analysis tools.

And it's also the high CPU usage dom rendering requires. Since browser runs does it all in a single thread, it can easily sit at 100% core usage. The rendering itself is simply not multithreaded.

It seems the limit is at around 200 before performance starts to drop. With 2.5k markers, i get around 3.6GB memory usage and CPU is stuck at near 100% for quite a while. Map drag triggers dom updates (because positioning is by translate), yet again killing CPU.

Thank you for the feedback! The team is trying to investigate the Advanced Markers performance issue, our initial focus is on scenarios involving the rendering of several hundred markers, as this represents the most common use case reported by our users.

To better assist us in our investigation efforts, we kindly request that you provide us a JSFiddle and/or the following information:

1. How many Advanced Markers are you creating?
2. Do you use the default Advanced Markers or custom content? Does the custom content have SVGs?
3. Are you using Raster or Vector Maps?
4. Do you remove the old Markers and create new Markers when panning or zooming the Map?
5. What FPS, CPU and memory usages are you observing when you navigate the Map?
6. If you don't use Advanced Markers, do you use the legacy Marker or the OverlayView for your use case? (This will help us compare the performances)
7. Which OS and browsers are you using for testing?

Any additional code samples or details you can provide about your specific use case would be extremely helpful. This information will allow us to better understand the circumstances under which performance issues occur and guide our investigation efforts more effectively. Thank you!

1. with old markers, we allowed up to 1500 without clustering. With new ones i find 200-250 is equivalent in performance, 500 has some short freezes already and increased memory usage.
2. Custom SVG/html - but overall the complex of these elements is equivalent to the default google markers - and i get similar performance drops with default markers.
3. No markers are manually removed right now when testing (unless using SharedSuperClusterViewportAlgorithm - which is a fixed version that better handles out of view markers, from clustering git repo).
4. With 500 markers - the tab is at around 350mb of memory (~120 without marker). CPU usage on that tab remains consistently high (chrome dev tools hovers at around 60-110, 150 when panning). If i try 1500 markers, it jumps to over 1gb memory and panning is a < 1 update/s slideshow. Likely getting limited by a single threaded nature of JS. I can get memory usage down but not keeping any local copy/array of markers, but now i have no access to them past init (due to large dom objects in each markers, the marker array itself also consumes a substantial amount of memory).
5. Legacy markers for roughly similar amount (also custom SVG content), sit almost idle - 0-0.9 CPU and extra 20-40mb of ram consumed.
6. Windows Chrome/Firefox. Hardware is substantially above what the average user would have (5800x3d or 12900).

Markers themselves are generated with minimal config. The content generation in total is highly optimized and the actual marker generation in code is relatively quick. For testing, using https://github.com/lmfmaier/cities-json cities data.

const marker = new google.maps.marker.AdvancedMarkerElement({
  position: { lat: conf.lat, lng: conf.lng },
  map: this.#map,
  content: await this.#getContentElement(conf),
});

Example of the dom element on screenshot - and a quick dump from chrome with 1500 markers visible.

Thanks for providing the detailed description of your use cases! I can see that the custom content is a fairly complex SVG which has an inner SVG element, would you mind attaching that SVG file here for us to take a look?

Also, how do you create the legacy Markers with this SVG content? Do you pass the SVG URL or its data URI to the legacy Marker's icon.url property? By default, those 1500 legacy Markers will be rendered inside canvases which produce much better performance than DOM Markers.

If you set the legacy Marker's optimized option to false, the SVG will be rasterized to a single <img> element which is much simpler than the SVG element in terms of the DOM structure, and this is what we try to determine: if using <img src="svg"> is performant with Advanced Markers, or you have a use case where you need users to interact with the inner elements of the SVG, please let us know, thank you!

The *SVG elements are combined in code (the marker has three states - hover/focus/normal), the inner icon in the center can change. Markers can have different color combinations too. It is not a single reused static marker.

The legacy did use optimize. Users specifically do not interact with the inner element itself - however, in some cases it does have to allow rotation (like a directional arrow).

img src svg requires the use of data URI, which in our case may conflict with SCP.

Simplifying the marker content to just a single path element, reduced memory usage by 200-300mb for 1500 markers, and reduced cpu usage - but when panning, it was consistently above 100.

The memory cost is directly proportional to the dom size. cpu usage relates to the complexity (more elements to draw - svg filters etc) and any content updates in viewport/elements that require a redraw causes a massive spike.

Similar performance spikes also happen with default marker (the red pin). Hover or pan can spike CPU a lot. These spikes also happen when i set content to an empty <img> element. Most likely due to the frequent transforms on the parent elements.

So it seems there are two separate issues:

1. the inner content raw dom adds to the memory size and extra calculations/rendering. will-change for transform in large numbers is also a potential cause for memory bloat.
2. the CSS transforms to position elements (does advanced marker make use of requestAnimationFrame to sync with rendering cycle?)

I have considered potentially prerendering to canvas and running position calculations in a worker (but you can't get the actual x y position from the marker for that). Or even webgl for even more performance. Using overlays. Both relatively complex and time consuming to implement that do not justify switching away from legacy markers. And overlay based approach would further lack native clustering support.

1. Usually around 400 in a small geographic area (telephone poles on a street), but in some use cases we have up to 4000. Furthermore, clustering does not benefit our use case.
2. We only use custom content and the custom content is an SVG
3. We use Raster Maps, but would be open to using Vector
4. We currently do create and remove markers based on the user’s map bounds, but we have also tested disabling this and either way Advanced Markers were noticeably worse than optimized Legacy Markers
5. We don’t have specific metrics but even with just 400 markers there is noticeable jank and stuttering when panning and zooming the map
6. Currently we use optimized Legacy Marker’s for our use case
7. Our users mostly use Chrome on Windows and Android mobile devices but some use Safari on iOS

The number of nodes generated even with default red pin is around 10x the number of markers. at 10k markers it's at around 100k and CPU/thread can't handle it anymore. Even if i were to try and optimize custom marker content, it would not help if even the default marker itself does not perform.

I have looked at alternatives - like maps webgl overlay. Creating SVG based markers is possible (three.js SVGLoader) - but difficul. Also, would need a complete new webgl based clustering.

Switching to DOM based as a "new future" is an architectural and engineering oversight - it is well known that DOM and JS are performance limited.

I feel like WebGl should have been the approach for AdvancedMarkers, the performance would be magnitudes ahead of what you can do with dom. But it requires much more support and support from google maps own side - including vector map layering. The vector map does not allow controlling zindex/layer order (so your markers are on top of map street names etc), orthographic camera support (so markers do not grow smaller/larger when zooming), SVG and other similar rendering support, clustering with webgl "markers" etc.

In my basic test i could render a million markers with decent performance (an example included).

webgl/three.js example

We appreciate your feedback regarding the performance issues you’ve encountered with the Advanced Markers JavaScript API. While Advanced Markers are easy to use, accessible, easy to customize, we take your concerns seriously and would like to offer some suggestions as we investigate this further.

Please note that our aim is to provide you with options to help mitigate any immediate issues while ensuring that we continue the investigation in Advanced Markers JS API based on your needs and feedback.

Thank you for your understanding and continued feedback. Suggestions below.

Optimized legacy Markers (for raster maps)

For use cases involving a very high number of markers, the legacy Markers API in its optimized mode is still available. While legacy Markers are not receiving new feature updates, they are still supported and there are no plans to remove them at this time. This approach is well-suited for scenarios where performance is critical, especially when rendering numerous markers on a Raster Maps and when customizing markers with simple images or SVGs.

Data-Driven Datasets

If your use case involves creating data visualizations on Vector Maps, we suggest exploring the Data-driven Datasets API. It is designed to efficiently handle large sets of geospatial data and interactive elements and may help with your use case. You can read more at https://developers.google.com/maps/documentation/javascript/dds-datasets/overview.

WebGLOverlayView

If your project would benefit from more flexibility in rendering complex shapes on Vector Maps, we suggest exploring WebGLOverlayView. While it uses WebGL drawing (instead of custom HTML elements) and requires some modifications to your existing code, it can significantly improve performance and provide enhanced control over custom visuals. You can read more at https://developers.google.com/maps/documentation/javascript/webgl/webgl-overlay-view.

3D Maps (Experimental)

For developers who want to see our ongoing investigation and work into more performant Markers, please take a look at Marker 3D Elements on 3D Maps (currently in the experimental launch phase). You can read more at https://developers.google.com/maps/documentation/javascript/3d-maps-markers, we would love your feedback on that via https://issuetracker.google.com/issues/new?component=1502222.

Legacy markers will continue to work until further notice. The deprecation of legacy markers is intended to help guide people to what we think is the best option for most developers (i.e. Advanced Markers), and manage expectations on what level of support legacy markers will receive going forward. (While google.maps.Marker will continue to receive bug fixes for any major regressions, existing bugs in google.maps.Marker generally won't be addressed.)

More info available at https://developers.google.com/maps/deprecations#google-maps-marker