0

As discussed in this question in Mauvis Ledford's answer and Pumbaa80's answer, Pushstate has many advantages in comparison to hasbangs. But I would like to discuss a single disadvantage Pushstate has, and then propose a solution. My question is whether that solution is SEO-friendly or not, and if not, what other solutions are there.

The problem with pushstate

The pushstate disadvantage relevant to me is the fact that whenever one opens a new page, a full page load must be done. With hasbangs this is not the case.

Consider this: One opens up example.com/gallery, if one just clicks a photo, Pushstate works great. One's browser makes an ajax call, fetches some JSON, renders the picture, updates the URL to example.com/photo1. Everyone is happy.

But if one right clicks a photo and opens example.com/photo1 in a new tab, a full page is requested and one does not enjoy the benefit of Pushstate. If one does the same with example.com/photo2 and example.com/photo3. And all the way up to example.com/photo10. 11 full page requests will be made.

Now consider the hashbang alternative: One opens up example.com/#gallery, now one rights click a photo and opens example.com/#!photo1 in a new tab. One does the same with example.com/#!photo2 and example.com/#!photo3. And all the way up to example.com/#!photo10. only example.com was requested, and it was cached. Then 11 tiny json requests were made. This is much better than fetching 11 full pages.

In conclusion: When visiting a website and opening many pages in multiple tabs, hashbangs are more efficient.

The solution

I found a solution which would make Pushstate as efficient as hashbangs even when opening a website's pages in multiple tabs, but I wonder how it fairs when it comes to SEO.

When a user opens example.com/gallery, this is what they get.

<html><head><meta name="fragment" content="!"></head><body>
<script src=”App.js”></script>
<script>function initialJson(){Some JSON here}</script>
</body></html>

The first line tells the web crawlers that this is an ajax page and that they should fetch a prerendered page somewhere else, please see this for more info.

The second line loads the ajax app.

The third line provides some JSON which is immediately consumed by the App.js and then the dom is generated. Thus only a single request was needed to render a full page.

Now that the user has example.com/gallery, when they decide to click something which leads to example.com/photo1, the user's browser makes an ajax call, fetches some JSON, renders the page, updates the URL. Everyone is happy.

Here's the magic: If a user decides to open example.com/photo2 in a new tab, they will get this:

<html><head><meta name="fragment" content="!"></head><body>
<script src=”App.js”></script>
<script>function initialJson(){Some JSON here}</script>
</body></html>

And since App.js is already cached, this is as good as a normal ajax request. We just let App.js consume the JSON and render a full page.

The Question

Is this SEO friendly? Are there any better alternatives? Is there a catch here? Are there any well known websites which do this?

  • 1
    I don't understand your "efficiency". It is most efficient and SEO friendly to do the whole page load for the first page. Requiring a page load and an AJAX call onload is less efficient. It then also requires special handling from crawlers. – Stephen Ostermiller Jul 4 '14 at 12:29
  • 1
    If your site is serving the right headers, all page requests after the first will pull back relevant external resources (scripts, css, fonts, images etc) from the browser cache anyway, which probably nullifies a big chunk of any advantage you'd gain by using ajax. Incidentally, your ajax method is how Twitter.com used to work. IIRC they moved away from it (back to server-side rendering) because client-side performance was terrible. – Olly Hodgson Jul 4 '14 at 14:06
  • @Stephan Ostermiller: "Requiring a page load and an AJAX call onload is less efficient." Please note that no ajax call is made upon the first time a page is loaded. I may have chosen a bad name for the js file (ajaxApp.js). The first time a page is loaded, this js file uses the json at initialJson() in order to render the page and no ajax call is needed. I edited the question slightly to avoid further confusion. – Hello World Jul 4 '14 at 14:52
  • @Olly Hodgson: Thanks! Any reference regarding Twitter's old method? – Hello World Jul 4 '14 at 14:52
  • 1
    @HelloWorld I can't get to the actual article right now (at work) but it seems to be linked from openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering – Olly Hodgson Jul 4 '14 at 14:58
1

Your logic is incorrect. When someone requests a page (hasbang or pushstate) in the same exact tab then the request can be done via ajax and less resources are loaded. When the page is loaded in a new tab (hasbang, pushstate) then the full request cycle starts from scratch and the whole page is requested. My point is there is no difference in regards to saving resources if you go with html5 history (pushstate/replacestate) versus rolling some sort of hasbang.

The main issues with PushState are that browser support is not 100%, and that some browsers have buggy support (fixed if you use history.js). Pushstate solves the problem of having SEO friendly urls because Google will request pages directly.

  • "When the page is loaded in a new tab (hasbang, pushstate) then the full request cycle starts from scratch" - Your logic incorrect. You are assuming that the cache does not exist. Ajax enjoys cache benefits which pushstate does not. – Hello World Sep 19 '14 at 11:08
  • Pushstate or Hasbang are both the same. It has nothing to do with caching, they are just different URL routing schemes. With Hashang you use javascript to update the url, and with pushstate you use HTML5 history to change or update the url. As for Ajax being cached, that will happen regardless based on cache headers you set. So if an ajax response is set to cache in the browser for 1 hour, it will cache 1 hour regardless of it its request is via hashbang url or from a pushstate url. New Tab, the request cycle starts again, and then the requests are aborted if an item is cached. – Frank Sep 21 '14 at 7:29
  • Yes it does have to do with caching. Here's a thought experiment: Bob navigates to eg.com/pushstate, a full, non cached page is downloaded and cached. Bob clicks a button, eg.com/ajax/pushstate2 is downloaded and cached. pushstate then changes the displayed browser address to eg.com/pushstate2 Bob closes the browser, then re-opens it and directly visits eg.com/pushstate2. A full, non cached page is downloaded and cached. – Hello World Dec 8 '14 at 10:42
  • Alice navigates to eg.com/#!page1, eg.com/ is downloaded and cached. eg.com/ajax/page1 is downloaded and cached. Alice clicks a button, eg.com/ajax/page2 is downloaded and cached, the displayed browser address is changed to eg.com/#!page2 Alice closes the browser, then re opens it and directly vists eg.com/#!page2. NOTHING is downloaded and everything is loaded from cache. – Hello World Dec 8 '14 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.