I have a complex web app, which is working fine in desktop browsers, as well as in the Android native browser (which is part of why I got so long into this project before noticing this problem). The server setup is using the Typesafe Stack (Play/Akka/Scala), but I suspect that's not relevant to the question. Suffice it to say, it uses bog-standard transient session cookies to keep your login.
The problem is, in Chrome and Safari, that transient session appears to be too fragile, and very unpredictably so. In both cases, so long as I am working actively in the browser, everything is fine. But if I switch away from the browser for a while and return to it, it often loses the session cookie, forcing a re-login. Sometimes it takes an hour or two, sometimes just a few minutes -- I haven't yet been able to figure out a pattern.
Note that this doesn't involve closing the tab with my app in it, or manually closing the browser process. I would expect to be able to switch away from Chrome and come back to it using the app switcher and still have my session there; for some reason, though, it seems to be frequently and quickly losing the session cookie. This is a killer problem: users shouldn't be forced to re-login too often.
Any ideas or pointers to why these browsers might be losing their session cookies so easily? I've done lots of web development, but this is my first time seriously targeting mobile browsers, and I'm clearly missing something...
Related
NB: since the answer to this could involve JavaScript or PHP programming, or general networking, or IT systems, I put it here, but if some mod thinks it's better suited for SuperUser or ServerFault, I won't object to it being moved.
I have a landing page to which I'm driving traffic through PPC. I've set up AWS CloudWatch to get RUM data, and the page is performing terribly — an average load time of 9.9s and max of 21.5!
I've done all of the "standard" optimization I can think of or research. The site is built with WordPress, running on Apache on an EC2 server. I've
Upgraded the EC2 instance to ensure I have enough memory
Written a custom plugin to filter out any other plugins that aren't explicitly used on the landing page in question
Customised my theme code so that it sets proper srcset and creates the correct image sizes on upload
Minified all the JS and CSS that I include through plugins or themes I've written
Put the site itself as a distribution to CloudFront
Installed the WP Super Cache plugin, and created a separate CDN distribution on CloudFront for it
Set appropriate cache control headers on CloudFront and told it to gzip everything
Put a facade in place of any videos
The site is blazing fast for me — "load" is less than 1 second. But my RUM says that's not the case for my users. So, I dug a little deeper. 70.2% of my visitors use Chrome, and 27.7% use other, of which almost 1/3rd are Android Browser — which as I understand it is just some sort of "Chrome Lite" — so nearly 80% of my visitors are using some Chrome variant.
Sure enough — if I load the page on Safari (to ensure nothing has expired on CloudFront), clear my browser cache, and reload the page, the first request shows a waiting time of 21.2ms, TTFB of 22.6ms, and download time of 4.8ms. The whole page shows that it's finished loading in 973ms.
Firefox is slightly slower, with the first request taking 100ms total, and the whole load about 1.75s — not blazing fast, but still within the understood "2 second" limit for good user experience.
On the other hand, for Chrome that same first request takes almost 570ms waiting and 208ms download. So, just the first request (which is 36k in size) takes almost as long to load in Chrome as the whole site takes in Safari. And that repeats for every single request, where both the waiting time and the download time are an order of magnitude slower on Chrome than on Safari (on the same device on the same network):
Whereas on Safari:
I would think "waiting" and "download" times would be primarily network driven, but I can repeat this all day long and the results are the same.
I might just assume that Chrome is not optimized for the Mac on which I'm running it, but, as I said, this all started with RUM data, so it's clearly not that. As much as I might like to, I obviously can't force all of my visitors to swap their Android devices for iPhones. Equally obviously, I can't have an average load time of 10 seconds.
So, why is my site so slow on Chrome? What else can I do to optimize this?
The landing page in question is here: https://www.chrisrichardson.info/lp/prague-b/
Note, a lot of the optimization I've done is for that page in particular, so other pages on the site might perform even worse, but I don't care about that, at least at the moment.
Hahahaha.
OK, just leaving this here for posterity's sake. The 10x latency was because Chrome had preserved in devtools from a previous session throttling to 3G. So, if you stumble upon this problem, check your throttling.
That still doesn't address my RUM issue, however, but I'll open that up as a different question.
I was checking the Application tab in the Chrome DevTools to debug an analytics issue and I noticed that the cookies section was empty, although the cookies menu under the lock icon in the chrome search bar seemed to show the cookie that I was interested in.
I did a bunch of refreshing, clearing site data, and restarting Chrome with no change in behaviour.
Is this a bug in Chrome? Why is there a discrepancy between the two menus? Does it have to do with httpOnly or secure cookies?
Not a very important question, mostly just curious!
I don't have an authoritative answer on this, but I think the explanation is in the language on top of this dialog: It says "The following cookies were set when you viewed this page". So it just shows whatever was set originally – or even "at some point" when you viewed the page. The message is not clear on this detail.
I can definitely confirm from my own tests that it will keep listing cookies that have since been deleted. Dev tools however always show the current state of cookie storage.
Whether it's a bug or not I suppose one could discuss at length, seeing as the behavior is not in conflict with the description. But it's certainly not expected behavior, and its usefulness for non-technical users is I think at least questionable.
This also lists "folder" type entries for indexed DBs, local storage and session storage which are not useful at all because you can't drill down. All of this and the missing punctuation on the message on top makes me think this is orphaned or forgotten code.
I also have no idea where that info is stored or how one might be able to purge it.
ETA: After some more experience with this discrepancy, I have since come to the conclusion that the list shown via the lock icon will show any kind of write access to the cookies. Since there is no dedicated "delete" operation for cookies, but you delete them by setting them with an expiration time in the past, deletions would still count as write access. So it looks pretty much like the dev tools seem to be only showing cookies that are still effectively there, i.e., would be sent to the server in a request, while the list in the lock icon is just a log of write accesses to cookie storage. This is still not definitive, but completely fits all my observations so far.
It is logical to run multiple processes when multiple tabs are there but in my Google Chrome i found multiple processes under single tab only. I thought it was some thread stuck so i restarted my PC and opened Google Chrome only and found same behavior. I am using Windows 7.
Chrome has plugins, web apps, rendering engines and others as separate processes from the browser itself.
That is done so that if one of those processes fails, it won't affect the whole browser, or even the whole tab, because those are separate processes too.
For example, Firefox doesn't have that, instead it detects the script in the page that should be causing the problem and shows you a dialog for if you want to stop it.
In summary:
Chrome treats these as different processes:
The browser
The browser (yes, again. Chrome by itself it's already 2 processes)
Each tab
Each extension (at least one per extension)
Each web app
Each plugin
Each whatever, everybody is a process, yay!
And that helps things can run in parallel and that that stuff doesn't end up crashing the whole browser.
Less crashes or at least when a process crash not all the browser crash, increase security, to make things run in parallel
Google Chrome takes advantage of these properties and puts web apps and plug-ins in separate processes from the browser itself. This means that a rendering engine crash in one web app won’t affect the browser or other web apps. It means the OS can run web apps in parallel to increase their responsiveness, and it means the browser itself won’t lock up if a particular web app or plug-in stops responding. It also means we can run the rendering engine processes in a restrictive sandbox that helps limit the damage if an exploit does occur.In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive. Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.
https://www.howtogeek.com/124218/why-does-chrome-have-so-many-open-processes/
On top of this, the parts of the browser that render HTML, JavaScript, and CSS have become extraordinarily complex over time. These rendering engines frequently have bugs as they continue to evolve, and some of these bugs may cause the rendering engine to occasionally crash. Also, rendering engines routinely face untrusted and even malicious code from the web, which may try to exploit these bugs to install malware on your computer.In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive. Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.
https://blog.chromium.org/2008/09/multi-process-architecture.html
this is one that is confusing me completely.
This issue doesn't happen with IE, Firefox, Safari ONLY with Google Chrome. (I haven't tested other browsers).
Basically I run my own web server, IIS 7.5, and have a number of development websites on it which will be published and used in production from the same server. As there are a number of websites I must use Dynamic Idle times for Application Pools as resources are restricted.
Usually this wouldn't be an issue and is the way to do things seemingly based on Microsoft's best practices however there seems to be a problem with Chrome loading pages once the application pool has timed out/gone idle.
Now I understand that it takes time for the application pool to restart, which they do within seconds and serve content not long after, but with Chrome the application pool takes close to a minute to start.
This doesn't happen on first load of the website however - it only happens with subsequent loads within the same browser/session.
As I said this does not happen with IE, Firefox or Safari, the other browsers I have tested, the application pool restarts almost immediately.
I had thought that maybe this was a server side issue but since the other browsers work fine I can only figure that it is Chrome at fault. Yet I still want to make sure it isn't actually a server side issue.
Any one have any ideas?
I've just realized I posted this on Stack where it should be on Server Fault.
Sorry.
Anyway, something I wrote in the question prompted me to investigate further and I found this doesn't seem to be an application pool issue, although it could be, but more so a PHP-CGI issue. It might even be localized to my own machine.
I have an HTML5/jquery mobile web app at http://app.bluedot.mobi. It is used for long distance races to track competitors via SPOT satellite tracking. The issue I have not yet resolved is that when loading the app when no data connection exists, the browser throws a "no data connection" alert popup as it is attempting to fetch the manifest during the checking event. Even when a data connection is present, loading the app can take a very long time. There are ~ 500 files to check. The fastest way to load the app (from a phone) is to be in airplane mode and dismiss the browser's alert - not so elegant.
Rather than force an update on users who tend to be in the backcountry with a spotty connection, I want to use applicationCache.update() programmatically, giving the user control over the process and speeding up app load whether on or offline.
Is this currently possible with the HTML5 spec and respective browser implementations?
Sounds like you need the abort() method. Unfortunately it is very new, and it will probably be a while before it is implemented by the majority of mobile browsers.
There are ~ 500 files to check.
It sounds like you're implying that the browser checks each file to see if there's any of them which has changed. This is not correct. The browser only checks the manifest file if that has changed, and that is a simple byte check. If the manifest file has not changed, the browser believes nothing has changed.
So if your application is slow to start, it might be your because your application is complex and there's alot of HTML and Javascript to parse. I would advise you to take a look at the application and see if there's anything you can optimize. In that case, you might want to take a look at Yahoo's Best Practices for Speeding Up Your Web Site page.
For example, I noticed you have a lot of Javascript code in the HEAD section. The beforementioned article advices us to move all Javascript (To the extent of what's possible) to the bottom of the page, so that the browser can start rendering the page as soon as possible. And there's a lot of other sound advice in the article. So take a look, I'm sure you'll find it useful. :-)