I'm working on changing member profile UI on one site. Project page: http://design.vitalbmx.com/user_menu/member_profile2.html
Goals:
Usability: page load time must be optimized, especially images in the active tab
SEO: pagination links within tabs must be crawlable
Assumptions:
Most users will go to "All" tab by default
Most users will rarely click other tabs except "All"
Most users will not send links to paginated tabs, only to 1st page of any given tab
Implementation scenarios:
Content of all tabs is loaded at once on the same page. Pagination via Ajax (with URL's to existing pages for crawlers). Possible issues - lag for loading images for tabs other than first tab if it's set in page URL (e.g. #videos)
Content of first tab ("All") to load first. Load content of other tabs only when they are clicked. Issues - extra HTTP calls and also lag for loading images for tabs other than first tab
Content of all tabs is loaded on the same page BUT image sources are replaced with a generic image for tabs other than current tab before images begin loading. When another tab is clicked (or after current tab images are loaded) image sources are reverted to original and begin loading (somewhat like Mashable.com but without the annoying fade-in effect)
Ajax-less - dedicated page for each tab. Makes more sense for SEO than for usability. Easy to copy-paste-send URL's with pagination.
Which one would be the best? Or am I missing something?
I think you should go with no. 4, because that one uses less load from server and client.
Related
I was reading up on ajax and how it empowers us to exchange data with a server behind the scenes and consequently avoid full page reloads. My confusion lies here, I don't really understand what full-page reloads mean. I think it's probably cause I've been working with ajax/react since the start I guess and have not really seen any webpage of mine fully reload when I access stuff from a database or an api.
It'd be great if someone could explain what they are and why did we need them before ajax?
A full page load is where the entire page is downloaded from the server. A page typically consists of several sections: header, footer, navigation, and content. In a classic web application without AJAX, a user clicks on a link to another page, and has to download the full page, even though only the main content is changing. The header, footer, and navigation all get downloaded again even though they don't change.
With AJAX there is the opportunity to only change the parts of the page that will change. When a user clicks on the link, JavaScript loads just the content for that link and inserts it into the current page. The header, footer, and navigation don't need to reload.
This introduces other problems that need attention.
When AJAX inserts new content into the page, the URL doesn't change. That makes it difficult for users to bookmark or link to specific content. Well written AJAX applications use history.pushState() to update the URL when loading content via AJAX.
There are then two paths to get to every piece of content. Users can either load the URL containing that content directly, or load the content into some other page by following a link. Web developers need to test and ensure both work.
Search engines have trouble crawling AJAX powered sites. For best compatibility, you need to employ server side rendering (SSR) or pre-rendering to serve initial content on a page load that doesn't require JavaScript.
Even for Googlebot (which executes JavaScript) care must be taken to make an AJAX powered site crawlable. Googlebot doesn't simulate user actions like clicking, scrolling, hovering, or moving the mouse.
Content needs to appear on page load without any user interaction
You must use <a href=...> links for navigation so that Googlebot can find other pages by scanning the document object model (DOM). For users, JavaScript can intercept clicks on those links and prevent a full page load by using return false from the onclick handler or event.preventDefault() in the click handler.
I'm optimizing my site speed. One of the main issue I'm facing is the homepage.
In the homepage, each article has FB/TW share buttons.
I only inserted the scripts in the footer once but I'm getting bunch of FB/TW share button requests.
Is it normal or there is something I need to do?
For every Like/Share button that you have, your browser needs to make a request to get the content. This is only executed when the browser has received the page from your server, so it does not affect the initial load time.
As CBroe mentions, the button is displayed in an iFrame. These are loaded and depending on your browser settings all at the same time or consecutive. During this time, your browser is not blocked so your used can already interact with the page.
If you want to reduce load, the only option is to remove the buttons. I think you have some index/home page where you load all the articles and for each of those a button? You could consider only showing the buttons on the articles itself, if you are really concerned about this.
But, since this is normal behaviour and your page is not blocked by loading all the iframes, this is not a big issue nor can you optimise it yourself.
I have a bookmarklet that opens a dialog (in reality an iframe) and extracts some information. When the dialog is dismissed I want to put that information into edit text fields on the original page in the browser (like the way LastPass will automatically fill-in login forms on a page).
Is this possible? I'm thinking that same-origin-policy will prevent this, but maybe there is a way (without installing extensions such as greasemonkey, etc).
Edit: to be more precise: the bookmarklet appends a DIV to the original page; that DIV contains an IFRAME that loads my page; this page fetches some information; once this information is fetched within the IFRAME I want to remove the DIV and (somehow) put that information into the original page.
The issue I face is communicating the information in the IFRAME back to the original page.
What you are looking for are the functions addEventListener and postMessage.
Relevant links:
http://caniuse.com/#feat=x-doc-messaging
How do you use window.postMessage across domains?
I have a site running on WordPress with a custom post type called "Video". By defaults in the front page displays a random video and when the video ends, the page is reloaded and it displays another random one. The URL remains intact, save obviously when one use a permalink for an specific video. I want to tweak the site to use Ajax, yet I'm not sure of how to acomplish it well:
By default, the main page should display a random video and when it ends or when one reload the page (via a link in the site itself), it displays another random one, yet with ajax. The URL on the navigator don't change.
When one clicks the permalink of a video (attached to each random video), the URL on the navigator has to change but the page remains the same and when the video ends, it just loops (much like how it works right now, but without reloading the whole page).
HTML5 History API with hashbang (#!) URLs fallback
I am trying to implement a search page with 2 tabs: Basic Search Options and Advanced Search Options. The Search button is outside the tab at the bottom of the page.
I am trying to figure out which switchType to use on the rich:tab component. richfaces offers 3 switch types:
ajax
server
client
I don't understand when someone who use one over the other.
Can someone explain succinctly when/how you would use the different switchTypes?
Thanks in advance!
April26
Examples of the three types here.
Ajax - When the tab is clicked on the body of the tab is requested from the server without refreshing the entire page. This makes the initial load time of the page with tabs faster than client switching and allows the user to click between tabs without refreshing the entire page.
Server - When the tab is clicked on the entire page is refreshed to get the body of the tab. Use Server switching when you want to keep the tab page load time down but don't want any ajax code. Clicking between tabs is not very smooth looking.
Client - All tab bodies are loaded when the tab page is loaded. The initial load of the page is slower but switching between tabs is much faster for the user.
I've created several pages that use RichFaces tabs and they all have used client switching. It makes the tabs more usable if the user doesn't have to wait when they click on a tab.