Question

I am working on PHP wrapper for Google Image Charts API service. It supports serving images from multiple domains, such as:

http://chart.googleapis.com
http://0.chart.googleapis.com
http://1.chart.googleapis.com
...

Numeric range is 0-9, so 11 domains available in total.

I want to automatically track count of images generated and rotate domains for best performance in browser. However Google itself only vaguely recommends:

…you should only need this if you’re loading perhaps five or more charts on a page.

• What should be my strategy? Should I just change domain every N images and what would good N value be in context of modern browsers?

• Is there point where it would make sense to reuse domain rather than introduce new one (to save DNS lookup)?

I don’t have specific number of images in mind – since this is open source and publicly available code I would like to implement generic solution, rather than optimize for my specific needs.

Answer 1

Considerations:

• Is the one host faster than the other?
• Does a browser limit connection per host?
• How long does it take for the browser to resolve a DNS name?

As you want this to make a component, I’d suggest you make it able to have multiple strategies to find the host name to use. This will not only allow you to have different strategies but also to test them against each other.

Also you might want to add support for the javascript libraries that can render the data on the page in the future so you might want to stay modular anyway.

Variants:

1. Pick one domain name and stick with it, hardcoded: http://chart.googleapis.com
2. Pick one domain name out of many, stick with it: e.g. http://#.chart.googleapis.com
3. Like 2 but start to rotate the name after some images.
4. Like 3 but add some javascript chunk at the end of the page that will resolve the DNS of the missing hostnames in the background so that it’s cached for the next request (Provide the data of the hostnames not used so far).

Then you can make your library configureable, so you don’t need to hardencode in the code the values but you provide the default configuration.

Then you can add the strategy as configuration so someone who implements can decide over it.

Then you can make the component offer to load the configuration from outside, so let’s say, if you create a WordPress plugin, the plugin can store the configuration and offer a plugin user an admin-interface to change the settings.

As the configuration already includes which strategy to follow you have completely given the responsibility to the consumer of the component and you can more easily integrate different usage-scenarios for different websites or applications.