API auxilliary JS files

bratliff

unread,

Mar 14, 2011, 11:00:14 AM3/14/11

to Google Maps JavaScript API v3

Esa

unread,

Mar 14, 2011, 11:21:52 AM3/14/11

to Google Maps JavaScript API v3

You have some control of the files by libraries parameter on url query
string.

libraries=geometry,adsense,panoramio

You can force any of those files to be loaded as a single file like:

libraries=common,util,onion,controls

as long as you know their undocumented names.

Chad Killingsworth

unread,

Mar 14, 2011, 11:41:18 AM3/14/11

to google-map...@googlegroups.com

Awesome. I've wanted that information for a long time.

Chad Killingsworth

bratliff

unread,

Mar 14, 2011, 11:44:53 AM3/14/11

to Google Maps JavaScript API v3

Hi Esa,

I suspect you are correct but I wonder how many other developers know
about it. Small files are more likely to be cached on the iPhone.
Several different applications from different developers are more
likely to be able to share the small individual files than the
combinations. I believe the bandwidth savings from fewer http
requests are insignificant. The number of bytes transmitted does not
change. Cacheability is sacrificed.

Chad Killingsworth

unread,

Mar 14, 2011, 2:24:46 PM3/14/11

to google-map...@googlegroups.com

It's less about bandwidth savings and more about the latency delay caused by individual connections - especially on a mobile device.

Chad Killingsworth

bratliff

unread,

Mar 14, 2011, 3:15:43 PM3/14/11

to Google Maps JavaScript API v3

On Mar 14, 6:24 pm, Chad Killingsworth

Hi Chad,

Do you happen to know the cache threshold on the iPhone. I believe
someone said it was 25K per file. Files exceeding 25K are never
cached. If true, Google ought to consider the following file sizes:

59,526 {common,map,overlay}.js
16,344 {util}.js
19,493 {onion}.js
50,071 {controls}.js
21,987 {stats,marker}.js

59,526 {common,map,overlay}.js
35,838 {util,onion}.js
50,071 {controls}.js
2,905 {stats}.js
19,081 {marker}.js

"common,map,overlay" can never be cached. With a little bit of
redistribution of functions, each of the following could be cached.

31,689 {common}.js
26,416 {map}.js
1,419 {overlay}.js

Similarly, "util,onion" is too large but the individual files are
fine. What about "onion,util" ? It is not the same file but the two
are interchangeable. Clearly, the names are not being sorted.
Otherwise, "util,onion" would be "onion,util" & "stats,marker" would
be "marker,stats".

Google ought to offer an option:

&files=combined
&files=separate

Usage could determine which was popular with developers. I would
always choose "separate". I suspect others would also.

Esa

unread,

Mar 14, 2011, 3:28:08 PM3/14/11

to Google Maps JavaScript API v3

We can see that the latest libraries (geometry, adsense, panoramio )
were introduced as 'manually addable' libraries.

Do you think it is good or bad?

What I think is bad, is that I have to make the decision before I can
see the client performance. That makes difficult the roadmap called
'progressive enhancement'. I am measuring certain parameters of the
client before deciding if I load certain scripts. With 'adsense' or
'panoramio' I cannot make the decision after I loaded the map script.
Or can I?

Nianwei Liu

unread,

Mar 14, 2011, 3:33:23 PM3/14/11

to Google Maps JavaScript API v3

I've seen mobile webkit only caches 20K or smaller files, but not from
official sources, and I suspect cache is probably not going to be very
consistent across browsers.
One of the bigger changes from v2 to v3 is that many modules were
broken away from the 100k+ main.js and make them load on a delayed
base, after the main map type is displayed, or even on-demand when the
module being is used first time.
Ideally the minimal code needed to show the first map type (events
like first "idle","maptypeid_changed") can be packed into one or as
few files as possible to limit the network connection latency, and put
everything else into smaller individual files for better caching and
load them as needed behind the scene.
It will be nice if Google can document the dependency of the modules
and allow more flexibility in loading them for developers.

bratliff

unread,

Mar 14, 2011, 3:40:18 PM3/14/11

to Google Maps JavaScript API v3

Also, for what it is worth, {control}.js contains too much stuff the
average user may never use. It contains support for SVG & VML
controls but both are "hidden" in the DOM. I can safely discard both
but I cannot prevent either from being built nor can I discard the
extra JS code.

Google - you ought to make SVG & VML controls optional - only loaded
on demand in separate modules. Why clutter the DOM with extra
"style.visibility=hidden" elements ? Why load the extra JS code if it
is not being used ?

bratliff

unread,

Mar 14, 2011, 3:50:42 PM3/14/11

to Google Maps JavaScript API v3

I believe the API ought to decide what to load to give Google the
flexibility to make changes. I believe cacheability ought to be
favored over latency for first time users of any mapping application.
I believe users of different mapping applications from different
sources ought to expect to be able to share cached files. I believe
"odd-ball" features like SVG & VML controls ought to be segregated in
there own JS files.

Esa

unread,

Mar 14, 2011, 3:51:35 PM3/14/11

to Google Maps JavaScript API v3

As Nianwei put it:

"It will be nice if Google can document the dependency of the modules
and allow more flexibility in loading them for developers. "

I agree and I understood that Barry and Chad agree. It would be
ubercool if you provide a method to load those libraries by
javascript;

google.maps.downloadLibrary("adsense");

I know that this should be processed via issue tracker but let's have
some discussion before filing a feature request.

Chad Killingsworth

unread,

Mar 14, 2011, 4:05:14 PM3/14/11

to google-map...@googlegroups.com

Allowable cache sizes have dramatically increased on the iPhone: http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Chad Killingsworth

bratliff

unread,

Mar 14, 2011, 5:40:14 PM3/14/11

to Google Maps JavaScript API v3

On Mar 14, 3:00 pm, bratliff <bratl...@umich.edu> wrote:
> Grouping of API auxilliary JS files is inconsistent. Two different
> runs of the same application resulted in the following:
>

>
> Some of the files cached in one run are not available to the other
> run. Grouping reduces the number of http requests slightly but it
> also reduces the ability to reuse previously cached files.

I just ran the same application again. The combined JS files are:

maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/4/4a/
{common,util}.js
maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/4/4a/
{map,overlay}.js
maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/4/4a/{onion}.js
maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/4/4a/{controls}.js
maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/4/4a/{stats}.js
maps.gstatic.com/cat_js/intl/en_us/mapfiles/api-3/4/4a/{marker}.js

The grouping seems to be totally arbitrary. The chances of a cache
hit are very slim. I guess if I run it enough times, I will have
enough permutations in my browser cache to stumble upon a previously
cached file.

Esa

unread,

Mar 14, 2011, 9:12:43 PM3/14/11

to Google Maps JavaScript API v3

I just filed a feature request

http://code.google.com/p/gmaps-api-issues/issues/detail?id=3138

Esa

unread,

Mar 14, 2011, 9:24:00 PM3/14/11

to Google Maps JavaScript API v3

I got your idea bratliff.

However I see that even more important that I don't load 'adsense' or
'panoramio' for visitors with a small phone. I don't know how to do
that.

en4ce

unread,

Mar 15, 2011, 8:19:43 AM3/15/11

to Google Maps JavaScript API v3

maybe check the bowser with your server like in php
($_SERVER['HTTP_USER_AGENT']) and place different parameters to the
map js script depending on the browser, its not the best way but
something that can work with enough testing

Chad Killingsworth

unread,

Mar 15, 2011, 8:28:43 AM3/15/11

to google-map...@googlegroups.com

On Tuesday, March 15, 2011 7:19:43 AM UTC-5, en4ce wrote:

maybe check the bowser with your server like in php
($_SERVER['HTTP_USER_AGENT']) and place different parameters to the
map js script depending on the browser, its not the best way but
something that can work with enough testing

I'd prefer to let the maps team decide what script gets sent for each browser. We're talking about restricting/requiring specific features. These wouldn't be browser specific (ex: adsense works on all browsers, but none of my maps use it).

Chad Killingsworth

Reply all

Reply to author

Forward

API auxilliary JS files - cacheability

bratliff

Esa

Chad Killingsworth

bratliff

Chad Killingsworth

bratliff

Esa

Nianwei Liu

bratliff

bratliff

Esa

Chad Killingsworth

bratliff

Esa

Esa

en4ce

Chad Killingsworth