Use Maps in Lite mode
support.google.com
support.google.com
While these 'modern' services might be more flexible with their largely client-generated UI, I feel that this comes at too high a price. This problem is not just limited to Google services, other sites and services are similarly hampered. Thing is, I'd have expected better performance from Google.
Anyway, to answer your question: youtube-dl can perform the page fetching and the download in the context of an authenticated user (for example for age-limited videos), so I assume that any advantages associated with a youtube account would most likely work with it.
When things were HTML, like most things "back in the days", thing were fast. Frames, maybe iframes, and ready-to-consume HTML.
Does Squirrelmail rings a bell? It was one of the earliest popular webmails in PHP, and it run every machines I accessed internet with, including 96MB RAM Pentium I MMX laptop.
The current trend of outsourcing rendering to the client is not really a gain for anyone: the server side still does a lot of arranging and magic on that data which is served, while it could just generate HTML. Serve the already done HTML, replace the parts in the DOM like we did in the beginning of the AJAX days, and things would be much faster.
Out of curiosity, I installed a lesser known browser, Dillo. It's dumb: it can parse a minimal amount of CSS and probably HTML ~4; the rest, it drops. And voilá: the internet - well, the ones that are still serving a viable miminum HTML without JS - became instant. Using the word "fast" would be an understatement.
We need to go back to the roots, otherwise we're using a lot of CPUs as heaters.
I've been using umatrix for this effect. I have some sites that unfortunately I need to use JS on. Sure, some sites fail to the point of not even working, but overall, I find sites faster, more user friendly, and more responsive than pre-umatrix.
There's a lot broken with the recent model of browsing, essentially, applications rather than content.
If we were still stuck with terrible standards implementations and lack of processing power, I would side with the "Lets do everything on the server again!" argument, but we're not. For most use cases only privileged information has the requirement of server processing, and if thats not a requirement, why not take advantage of the device requesting the service?
Set aside the 5 second delay user experience annoyance, and realize that as a business there is no way to scale your services profitably without offloading as much work as possible to the web client.
A significant part of that 3.4 billion are on mobile, which is even deeper prone to the overused JS problem.
> terrible standards implementations
Ah, you mean IE6. In it's prime time, it was a brilliant browser, standards or not; it was a necessary evil to forcefully move things ahead. It has XHR, webfonts, a gazillion things none of the browsers had yet. It indeed stuck around for too long, but this was not the case in it's initial state.
> lack of processing power
https://hackernoon.com/10-things-i-learned-making-the-fastes... -> Read the paragraph "#2 Do mobile first. Like, really do it." We do lack processing power on mobile, so for that 2-3billion people, who are using mobile _only_ or mobile first, we need economical solutions.
> why not take advantage of the device requesting the service?
Because you can't assume the device is powerful enough to do so. Why do you think https://mbasic.facebook.com still exists?
> Set aside the 5 second delay user experience annoyance
You go against one of the initial hard rules of the web with that. I wonder if is the importance of speed had changed, but judging by the grouchy voices all around, it did not. People only keep using the services because they deliberately made it hard to leave or because they learned tactics from Microsoft and are constantly eliminating competitors.
> and realize that as a business there is no way to scale your services profitably without offloading as much work as possible to the web client.
Now, this is complete nonsense; there is no money you save there. How is generating all those React apps, shuffling all that data is better then generating HTML? :)
Of course, there are exceptions, there are always exceptions, but most of the things would not need mammoth sized invisible JSONs to be parsed in the browser while the pre-rendered HTML could be served and manipulated only when needed.
Usually these applications are compiled once, and delivered by CDN. That's a huge savings.
Also I'm not saying the speed of Google Maps in your browser is acceptable, but with tools like Webpack Chunking, you can optimize even the initial load to nothing. This is a software architecture problem, not a javascript problem.
So with that in mind, I believe that Google Maps is purposefully not optimized for most mobile clients. It's designed as a fallback if you don't install the app (which they are deeply incentivized to peddle).
I also think other web applications that get to the point of ~5 seconds of loadtime need to rethink their compiling strategy (if at all possible). I mentioned webpack before, but spreading out the work of large payloads is a well documented issue with many different solutions. If it's the CPUs fault, you should be using Web Workers.
My original point stands though, processing on the client is free, scalable and an effective solution even considering the harm it could inflict on UX, and those harms can be mitigated.
Read the paragraph "#2 Do mobile first. Like, really do it."
We do lack processing power on mobile, so for that
2-3billion people, who are using mobile _only_ or
mobile first, we need economical solutions.
Or use an older, 'underpowered' (by modern standards) machine for development, like I do. A Thinkpad T42p will give you a 1600x1200 screen, one of the best mobile keyboards available, 5-6 hours of autonomy with an extended battery and... the awesome power of a 1.8 GHz Pentium M... well, not so awesome maybe but if it works on that machine it flies on anything more up to date.[1] https://en.wikipedia.org/wiki/Talk%3ADillo#Frames.2C_Tabs.2C...
Also, from https://support.google.com/maps/answer/6291838?co=GENIE.Plat....
> Note: Downloading offline areas isn't available in some regions because of contractual limitations, language support, address formats, or other reasons.
Yes, Google can't provide offline maps in some countries. This is true of all mapping applications, though some have better offline coverage than others, nobody has everywhere. For example HERE does not offer offline maps in Japan or South Korea.
Compare that to the 179mb/113mb that I need with OSMAnd/Maps.me for the whole country without fiddling. Add to that the fact that OSM's data is significantly better than Google Map's for my country (YMMV) and that there's no such thing as "offline mode not available in some regions" with OSM.
I feel like one word is a rudely short answer but that's it. Offline maps, open data, open source application... that's my thing.
- When I deactivate all my addons it still does.
- When I try a new profile it no longer does.
-> If not an addon, to my knowledge of Firefox, the cause has to be a changed Firefox preference (right?). But if right, I changed so many of them, I have no idea which one causes the behavior. Before I binary-search that, any clue what the culprit pref might be?
The support page doesn't answer this question; its only relevant snip is that "Maps will take you to Lite mode and your maps won't have 3D images if you have the following cards: [...] Intel GMA 3600", which I have (GMA3600 == HD520), but it must be outdated documentation, as Maps stays non-Lite with a fresh profile.
It's probably a preference, and you might start with something obvious like webgl.disable=true. However, you might rather just try Refresh Firefox, which resets your profile while keeping your bookmarks/history/open tabs.
https://support.mozilla.org/en-US/kb/refresh-firefox-reset-a...
For some reason, here Google Maps force lite mode, no matter how hard I try to force normal mode.
Still, even in lite mode, it is incredibly slow, if it was slower it would go backwards.
And it is missing basic features that classic maps had, like latitude and longitude lines, and measurement.
The other big difference is that zooming in with the lite version takes me to aerial photos which look infinitely better than the weird 3D interpolated pictures of the full version (Earth view). I'd like to get that as a default in Earth.
This compares to full version which uses Javascript to render some of the roads and symbols as some kind of vector drawing on top of less detailed map tiles.
I'd expect the Full version to require slightly less data transfer and behave better when zooming in and out rapidly. When you zoom in on a vector drawing it still looks sharp, so you just have to wait for more detailed roads to appear. Whereas in Lite mode, you'd zoom in and stare at a blury tile until the higher resolution one loaded.
I'd expect Lite to work better in a browser or network that just can't cope with a web application. Old versions of IE, weird embedded browsers in smart TVs, that sort of thing. Given what it is, I wouldn't expect it to work better.
The big differences excluding 3d features are things like
* you can rotate the map
* zoom is continuous
* the map can be customized on the fly to make it more relevant to your search. So for example a road can be highlighted for one search vs a different road highlighted for a different search. Different buildings/roads get labelled etc.
This was all covered to Google I/O when the current version of Google maps was released 4 years ago
There is no longer tweening between the start/end zoom level, so the incremental redraw of the map feels very choppy. I suppose on a low powered device, the former could less performant. However, having experience g-map in browser on even several generations old iPhones and Android, I have to imagine this lite mode is targeted at devices even older than that!
I won't go as far as to say I've never encountered bugs that I've noticed in the dev channel release but anything that serious is usually fixed within a matter of hours and it's happened to me like maybe twice in all the years that I've been using it.
It's the great equalizer.
- Consistent UI. Sometimes back erases stuff, sometimes it doesn't. Sometimes clicking on the map area on the top resizes the window, sometimes it doesn't. Sometimes dragging the screen down moves me back, sometimes it doesn't. There's a lot of "I hope clicking on this does what I want!".
Currently there's a bug on my phone where GPS usually doesn't work with gmaps. If I click on the "find me now with gps" button, sometimes something happens, sometimes nothing happens.
- The ability to lock the map to keep it from spinning when trying to zoom in/out.
- The ability to restrict searches to a specific radius. If I am zoomed in on the middle of Berlin and type "Burger", don't back out and show me results outside of the area I was searching in. Additionally it would be nice to be able to type a number in.
I'm sure there's more. Every time I use gmaps it's an exercise in keeping calm because the UX is so terrible compared to what it used to be.
Sometimes Google maps on PC is that bad I have to get phone out.
Anyone else seeing this? I'm currently on the Kindle web browser, and it definitely seems faster, but I can't tell want mode it's in except by diggimg around the URL.
Will try on desktop Chrome.
I was assuming they would be using the same data as regular Maps.
Does anyone know more?