[openstreetmap/openstreetmap-website] Reduce size of application.js by removing translations? (#1949)
notifications at github.com
Thu Aug 16 10:03:24 UTC 2018
As mentioned in https://github.com/openstreetmap/operations/issues/134 , the application.js bundle is enormous. A quick check shows that ~90% is translations for the browse interface. But nobody needs all of those translations, and at most will only need a couple of languages to show the page.
Even then, I bet that most people only need a few of those strings, unless they do a huge amount of using the browse interface. For example, it's very rare for me to need the "fire_pit" or "battlefield" translations. But all of these are needed for all visits to the website, even just to browse the map and sign up.
A bit of playing around with the interface shows that there's also room to improve the way it works, particularly for the query-feature functionality. It's most noticeable when you're a long way away from the European datacentres. For example, if you click here:
* You first get back a "placeholder" html response from osm.org. You need to wait for it to fully load until it fires off two overpass queries
* Each overpass query returns far more data than is required. For this example, it returns a hundred translations of Taiwan, all but one of which are ignored. Compare the amount of data in https://www.openstreetmap.org/relation/449220 to the output "Country Boundary Taiwan" on the browse pages.
The translations are also used for the regular browse pages, but these exhibit similar problems with requesting more data from the server than is required to show the page. For example, a "relation/full" call grabs all the node ids, way ids, associated usernames, node update timestamps etc as part of the call, and then throws this information away when building what's shown in the interface.
To cut a long story short - why do we do it this way? Could we instead build all of this html output server-side, and just return to the client the minimum of what is needed? This could remove the need for all the js-based translations, and it moves some of the heavy responses away from the end user's connection and keeps them on fast DC-DC links instead.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rails-dev