If you look at the PageTest "waterfall" diagram for your page http://pagetest.patrickmeenan.com:8080/result/ZJ0/1/details/
You can see that a large proportion of the 15.183 seconds taken to display the initial page is consumed by loading a large number of small files. MSIE, in particular, is very inefficient at loading many small files. A CSS sprite system should massively improve the situation. Similarly, merging your small .js files into a few large files would speed them up. I've not looked deeply into your JS, but are you sure that you really need ALL those http://ajax.googleapis.com/ajax/libs/dojo scripts? Hint: You might possibly be able to merge the .js files by having a caching file concatenation server. Make one request to the concatenation server with a list of files that the client code wants. The server fetches any remote ones that haven't been loaded into its cache recently, adds any local files and cached files and returns a single reply containing all the data. The Sprite system that works inside the API is undocumented, so if you decide to use it, do lock into a specific API version in which it works. An alternative approach that will speed up the loading, but not so much, is to distribute the image files across several alias subdomains in order to subvert the browser connection limits. See: http://econym.org.uk/gmap/custommapparallel.htm for more detail (that page uses the technique for map tile images, as does Google, but it's applicable to your image files). PageTest only evaluates the performance of the initial page load. For a better analysis I suggest creating a temporary page that starts off zoomed in to where the markers start being displayed. You might consider only fetching markers that satisfy the selected categories, rather than fetching them all and hiding the visible ones that are not selected (which doesn't seem to be working quite right at the moment anyway) and starting up with fewer categories automatically selected. I suspect that your "custom padding size" is a bit large, resulting in there being typically eight times more markers concealed in the padding region than in the viewport. There's a trade off here - the smaller it is, the more often you have to reload from the database, but those smaller reloads are faster and dragging the map would be less sluggish. I'd also suggest ditching MarkerManager, since it looks like you're actually duplicating its functionality by making calls to your database. -- http://econym.org.uk/gmap The Blackpool Community Church Javascript Team --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Maps-API?hl=en -~----------~----~----~----~------~----~------~--~---
