I’m making app-ish gatsby website with authentication.
Im displaying user menu in header if user is logged in, and login button if not.
Until session is checked, I dont know if I should show menu or login button. Because of that I decided not to show website at all initially (if session cookie/token is not detected, website is loaded almost immediately, but initially its blocked too), until session information comes back from backend.
I did this by simply creating session reducer with initial state variable „checked” set initially to false - website shows content only when this variable is set to true, what happens after session check or after token/cookie presence check.
But, from what I understand, if I block website until session is checked and no content is shown I lose all static seo power of gatsby. I mean google bots won’t scan my website if theres no content shown initially. Am I correct?
What would be your approach to this problem? Changing from „log in” button (or not showing it at all initially) to usermenu in header looks weird.
In order for SEO to be correct, you can add loading in the menu and login button areas when detect.
But, from what I understand, if I block website until session is
checked and no content is shown I lose all static seo power of gatsby.
I mean google bots won’t scan my website if theres no content shown
initially. Am I correct?
Yes and no. If you block all your website before you check the cookie, yes. However, if you are only blocking the header part to show/hide one button or another, you are not blocking the statically of Gatsby. In addition, keep in mind that Google bots always make various crawls; one the check the "static" content (without JavaScript) and one of them awaiting the JavaScript response/rendering.
In your case, if you are only checking a local variable to decide which component render, you are not losing the SEO power of Gatsby, since you are only rendering (or not) a small piece of code.
In the worst case that the crawler wasn't able to detect that small piece of code, the SEO impact is meaningless, it won't affect the overall performance only to show/hide a component.
For further details about Google's crawlers check the docs.
What would be your approach to this problem? Changing from "log in”
button (or not showing it at all initially) to usermenu in header
looks weird.
I would say the best approach is the best UX response, since the SEO impact is meaningless. It may not be intuitive for a user to see a "Log in" button and once the cookie/reducer is checked change it suddenly to another content. I would prefer to awaiting the variable.
Related
I am developing a PWA using react JS
There is a requirement that we need to display the add to Home screen even after the App has been added to the Home screen for the first time
Can any body suggest if this is possible and how?
INFO: Mostly this app will be run on Google Chrome and Safari
Refer to this answer. You simply can't do that, unless you want to do it in specific development/test machines where you can set the below chrome flag,
chrome://flags/#bypass-app-banner-engagement-checks
You can't expect all your end users to set this flag, so this can't be a solution for all the real users.
I also don't see why you would have to show the banner even after adding to home screen, for any other use case. Browsers don't allow this for obvious reasons. It will be annoying the user, if the prompting is left to developers. Linked answer have more clarification on the same.
I'm using the history fragment to capture the url after the hash for an angular-based site we've built.
Not all my pages are showing up under All Pages in Google Analytics - but DO show when i add page as a secondary dimension to events.
I think this is to do with using the history change trigger to send url fragment as a pageview, but I can't figure out how to make it work.
How do I make sure an exit page is captured, even though it isn't reloaded hence no new history fragment?
(register.creditunions.com = tracks fine, but when someone completes, it goes to /confirm, which they leave, and which is not tracking. I have the confirmed sign ups in my CMS, and they HAVE to go through to that page to get signed up, hence i know i'm not just asking about a page that isn't being seen.)
Google Analytics doesn't detect URL fragments as a part of page path out of the box. You need some tweaks to force tracking of anything after the hash. There is a lot of recipes all over the web. Try this one https://www.simoahava.com/gtm-tips/track-url-fragments-as-pageviews/
What's the best practice of loading data at launching Chrome App?
The landing page of my Chrome App is dependent on some configuration data, which I've stored in the chrome local storage. However, reading chrome local storage is an asynchronous process. Hence, after the App has launched, there is a period of time when the landing page doesn't show correctly.
To avoid this blank time (due to the asynchronous process of reading local storage), I'm thinking about reading data at background JS. However, I haven't googled out what's the best practice to do it.
Anybody has any comments? Thanks.
just listen to the onLaunched event
chrome.app.runtime.onLaunched.addListener(function() {
// load your data
});
Here's one piece of helpful suggestion I've got from the Google Group. Share here so that someone with the same problem might refer to it:
You can read from chrome.storage in the background page and open the window when the data is ready. However, the user experience might be even worse, because instead of the incorrect landing page, you have no user feedback at all.
The usual (and easy to implement) solution is to show your landing page with some visual feedback during data loading, like a spinning wheel with a "Loading" label. If you UI really requires the data to show up, you can add this visual indicator as an opaque div on top of the whole window.
Some people use splash screens, but I don't think it adds to the user experience.
The problem I am having is filtering out the users that come to our homepage just to login, since we have the client button on the homepage (and yes I've tried to get them to put it somewhere else).
I can't think of a way to do it because they don't look any different than potential clients, other than that they may visit more often and click on the button. Any ideas or software that might accomplish this?
one way, is to associate a cookie with those users and either a) don't load the tracking code when cookie is present, or b) in Analytics Settings -> Filter Manager, add an exclusion pattern matching the cookie name. a) would be more flexible.
now, there's no way to tell if the user is going to stay on the main site or hop to the client area... so it might undercount in some cases. but you might find that better than the overcount showing up now...
a slightly more intrusive option, would be a JavaScript overlay / splash screen that shows up when you detect a user returning that asks them, "Would you like to go directly to your client area? [YES] [NO, TAKE ME TO THE MAIN SITE]". in that case, the tracking code wouldn't be loaded unless, they say are going to the main site...
if using the filter manager method, you'll want to register the variable like so:
<body onLoad=”javascript:pageTracker._setVar('my_cookie_name_guid')”>
I have one problem with IE7. Let me explain the scenario
I have opened my web based application in IE7 browser in TAB1 by using normal login feature. After successful login, i entered to the application home page and i do with my normal transaction say Trans1. Now i want to open my application again in another tab TAB2 in the same browser window.. what happens IE7 won't allow me to login on my application in the login page, it directly enters to the home page and when i do one transaction say "Trans2" it is going smoothly. Now when i again went to the TAB1 and doing one transaction it is opening the TAB2 page that i opened in TAB2.
It seems IE7 is sharing same session cookie in multiple tabs. Is there a workaround for the same scenario.
Anyone have any solution for this problem.
Appreaciate your help in this regard.
Thanks,
Manoja Swaro
It seems IE7 is sharing same session cookie in multiple tabs. Is there a workaround for the same scenario.
Well no. Cookies are by design shared between all instances of the same browser, whether in multiple tabs or multiple windows. You can only get two separate sessions by using different browsers, like an instance of IE and one of Firefox.
This changes a little in IE8, but in quite a complicated way you probably don't want to rely on. See http://blogs.msdn.com/ie/archive/2009/05/06/session-cookies-sessionstorage-and-ie8.aspx
This is why you should generally not be using cookies/sessions for keeping track of partially-completed transactions; one transaction will always interfere with the other. Better to either:
keep track of all incomplete transaction data in page/form data, like hidden fields
if that's too much data to keep passing back and forth, create an ID for the transaction that is remembered through page data, and store the actual data in the database.
You can also use a unique ID tied to the page to generate more unique cookie names, eg. 'preference.1234=foo' instead of just 'preference=foo', so that each instance will have its own cookies.
Yes. IE shares session/cookie between tabs.
Try to run a new browser (i.e. from Start menu) -- it helped with older versions of IE
and it works with my IE7.
AFAIK This happens with all tabbed browsers (FF for example).
Indeed, this is how all tabbed browsers work. Cookies are shared among all tabs. However they are not shared among multiple instances of the same application, but I doubt this will help you.
This is actually a serious problem for many applications. It is very difficult to keep track of the tabs - which are open, which are closed, when a new tab opens, and when an existing one makes a request.
There is one workaround I have found, but it's pretty messy. The idea is that you have to assign a unique ID to every tab yourself. Then, when a tab performs some actions, this ID has to be posted back to the server. Depending on the architecture of your application, the ID can be passed around in URLs or hidden form fields. If you're doing AJAX, this can make it easier to find a common place to add the ID. ASP.NET also has just one form at all times, so the hidden field is easy to do.
Naturally, on the server side you must check this ID and implement your own "tab sessions" based on it.