Hi Mike, On Feb 2, 6:32 pm, Mike Williams <[email protected]> wrote: > 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 will get the sprite side of things done and retest. Looking at the graph it certainly does stack up. > I've not looked deeply into your JS, but are you sure that you really > need ALL thosehttp://ajax.googleapis.com/ajax/libs/dojoscripts? With regards to the dojo scripts, they're referenced from a CDN and one of the first jobs the parser does is to work what is required and then only call the required files once, However, on further inspection of the page, I don't think I actually need those files. I am working with a system where some parts of code are pre-included and those dojo calls are in that space. I'll look to get them removed for that page. > > 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. I will have to look into this. > > 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. I would guess that the current version would suffice? > > 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). I do not think this will be practical for me atm, although I can see where you are coming from. > > 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 think maybe the ticked checkboxes are initimating that other markers are hidden. On the first request where markers are called for, only towns and attractions are pulled from the system due to the zoom level. I have tried to keep the marker load to a minimum by only making calls for specific marker types at certain zoom levels .e.g. towns and attractions at zoomlevel 6 and higher, fisheries at zoomlevel 9 or greater and so on. From the data, I know there are lots of markers that would be plotted so by breaking them down into zoomlevels I can manage (to some degree) the amount of markers displayed. Does this sensible to you? > > 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 will resize the custom padding size. I was using a suggestion from the mapWiki to preload markers, but I agree with your comments. > > I'd also suggest ditching MarkerManager, since it looks like you're > actually duplicating its functionality by making calls to your database. really? this statement surprised me. So, you're suggesting that I just recursively add the markers via addOverlay as opposed to building an array and then adding to the marker manager? Thanks for your feedback, it's been very valuable. Paul > > --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 -~----------~----~----~----~------~----~------~--~---
