Build your own OL?
OL provides a small Python program to enable you to build your own minimised version of OL with only those classes you use. (Since 2.11, this build program can optionally use Google's Closure Compiler, which reduces the size of builds by some 20% over a simple minimise.) You basically create a configuration file that determines which classes you want, and then run the build script with that file. On the face of it, this is a no-brainer. The full version of OL currently runs to nearly 1MB. The total size of a build including only those classes I use is less than a third of that; the minimal build for those pages that do not use vectors is around 150kB. There are however a couple of caveats:
- if you only have a modest server with limitations on downloads per month or whatever, you're probably better sticking with the build that OL kindly provides on its site
- your users' browser cache may mean that in some circumstances they are actually downloading more in total: by providing a different file you may be increasing the time taken to load a page rather than decreasing it. If they regularly use other sites which also use OL, they may well already have it in cache, but if you present your own build file this will not already be in cache and may therefore be duplicating what they already have. However, against this it must be said that you cannot rely on browser cache
There are a couple of other strategies more advanced OL users can use to reduce the size of build files:
- you can restrict your base build to the core classes, and then load the lesser-used ones as needed. For example, as Layer/EventPane, Layer/FixedZoomLevels and Layer/SphericalMercator in the current development version (2.12) are only used by Layer/Google, I compile these into a separate file, and only load this when the user requests a Google baselayer
- you can take this even further by using a modular loader like RequireJS to load classes on demand. The classes that benefit most from this are the vector renderers. As you don't know at build time which renderer will be supported by the browsers your users use, you have to include all three (SVG, VML and Canvas) to support all users. With load-on-demand, you first send a small piece of code to the browser to see which renderer is supported, and then load that
However, I wouldn't recommend using these techniques until you're familiar with OL's structure. Otherwise, you could end up with essential classes missing, and your scripts no longer working.
Overall design/architecture
As I said in the page on latency, it's better to do as much as possible on the server rather than the browser. I use the Symfony PHP framework on my server, and this controls what is sent to the browser. The url determines the base map and page/application to be used, and the framework includes the appropriate script tags in the output page. Data, calculated or configuration variables are passed by the framework to the browser in a script tag. Similarly, any processing of features should also be done on the server as much as possible, leaving the browser with only the rendering and the user interaction to look after.
