Menu
this is what I see in my local log file when I make a single page request:
Started GET "/" for 127.0.0.1 at Mon Apr 25 22:12:22 -0700 2011 User Load (0.9ms) SELECT "users".* FROM "users" WHERE ("users"."id" = 2) LIMIT 1 Processing by PagesController#beta as HTML Rendered pages/beta.html.erb within layouts/beta (16.2ms) Completed 200 OK in 23ms (Views: 18.8ms | ActiveRecord: 7.7ms) Started GET "/" for 127.0.0.1 at Mon Apr 25 22:12:23 -0700 2011 User Load (0.6ms) SELECT "users".* FROM "users" WHERE ("users"."id" = 2) LIMIT 1 Processing by PagesController#beta as */* Rendered pages/beta.html.erb within layouts/beta (17.9ms) Completed 200 OK in 27ms (Views: 21.5ms | ActiveRecord: 6.6ms) Anyone have any ideas what could be causing this? the Processing line is interesting?
PagesController#beta as HTML PagesController#beta as */* What does that mean?
593
I've seen this happen because of an img tag with a blank src attribute. Giving an img, script, link or similar tag a src or href attribute ="" will resolve to the current page. So it will try to load the page a second time as it tried to load the asset. It could also be in a CSS url() property or an AJAX call.
One easy way to tell is to temporarily put something like <base href="http://example.com" /> in your <head> section. That will prefix any links on the page, which should prevent your local page from being called twice if it is that sort of problem.
I've also seen some browser extensions that query the page in a separate request. I've noticed this specifically with the Web Server Notifier and Web Technology Notifier extensions for Chrome. Try an "incognito" window or a separate browser and see if you get the same result.
177
I experienced this before and the culprit was poor implementation of Turbolinks (on my end).
I had to learn the proper way of getting Turbolinks to work (I've included my learning resources at the bottom) ... watch the Ryan Bates video to see what a properly working implementation looks like by the way.
Problem/Culprit:
Is Javascript. As described on the Turbolinks Github page ...
With Turbolinks pages will change without a full reload, so you can't rely on DOMContentLoaded or jQuery.ready() to trigger your code. Instead Turbolinks fires events on document to provide hooks into the lifecycle of the page.
Basically anything that implies 'run after DOM/page is loaded' will break/not-work-as-expected ... this will cause Turbolinks to not be effective. And since Turbolinks gracefully fails, your browser will load the page twice (check logs/console) to and hide the problem for you.
In my case I was able to notice the above behaviour when in 'incognito mode' ... all my Javascript that depended on document/DOM/page-ready .... broke. So ...
Solution:
If you have anything like this in your javascript (below) ...
$(function() { alert("DOM is ready!"); }); $(document).ready(function() { alert("DOM is ready!"); }); jQuery(document).ready(function() { alert("DOM is ready!"); }); Change to this ...
$(document).on('page:change', function() { alert("DOM is ready!"); }); Turbolinks don't actually don't request for an entirely new page so you'll notice your Javascript only works on full page loads but not when you click from a Turbolink enabled link.
Which means that we should rely on Turbolinks to detect what DOM ready actually is.
In my opinion the current answers are (could) wrong as I have Chrome extensions, blank-hrefs and my problems are gone.
Further reading:
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
