Forum Moderators: open

Message Too Old, No Replies

Google, CSS and Android

         

lucy24

10:25 pm on Aug 6, 2017 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



anything Google not covered by another forum.
Well, I guess that's me.

Ponder these log selections. I've done pattern searches of saved logs; this is not a case of server hiccups (where Requests B and C are logged before Request A even though they came in later). The supporting files are genuinely getting requested before the page itself.

IPs are all different. Sometimes they are Googloid ranges like the one used by mobile-thingy-I-forget-its-name; more often they are not. UAs are not 100% Android, but far more often than not, say 5/6 of the time. I haven't fine-tooth-combed to see whether the residue are desktops or more obscure smartphones.

3.4.5.6 - - [29/Jul/2017:05:46:36 -0700] "GET /sharedstyles.css HTTP/1.1" 200 2068 "https://www.google.co.id/search?q=download+font+caps+lock+android&oq=download+font+caps+lock+android&{more-stuff-here}" "{Android}" 
3.4.5.6 - - [29/Jul/2017:05:46:36 -0700] "GET /fonts/fontstyles.css HTTP/1.1" 200 2370 "https://www.google.co.id/search?q=download+font+caps+lock+android&{more-stuff-here}" "{Android}"
3.4.5.6 - - [29/Jul/2017:05:46:36 -0700] "GET /fonts/fontcheck.js HTTP/1.1" 200 2211 "https://www.google.co.id/search?q=download+font+caps+lock+android&{more-stuff-here}" "{Android}"
3.4.5.6 - - [29/Jul/2017:05:46:36 -0700] "GET /fonts/font_input.html HTTP/1.1" 200 8927 "https://www.google.co.id/" "{Android}"
3.4.5.6 - - [29/Jul/2017:05:46:38 -0700] "GET /fonts/font_input.html HTTP/1.1" 200 8926 "https://www.google.co.id/" "{Android}"

1.2.3.4 - - [05/Aug/2017:23:24:56 -0700] "GET /sharedstyles.css HTTP/1.1" 200 2068 "https://www.google.co.in/" "{Android}"
1.2.3.4 - - [05/Aug/2017:23:24:56 -0700] "GET /ebooks/beeton/bohm6.html HTTP/1.1" 302 646 "https://www.google.co.in/" "{Android}"
1.2.3.4 - - [05/Aug/2017:23:24:56 -0700] "GET /ebooks/ebookstyles.css HTTP/1.1" 200 2186 "https://www.google.co.in/" "{Android}"
1.2.3.4 - - [05/Aug/2017:23:24:56 -0700] "GET /ebooks/beeton/beetonstyles.css HTTP/1.1" 200 2303 "https://www.google.co.in/" "{Android}"
1.2.3.4 - - [05/Aug/2017:23:24:57 -0700] "GET /boilerplate/redirect.php?newpage=/ebooks/beeton/bohm6.html HTTP/1.1" 200 1742 "https://www.google.co.in/" "{Android}"

5.6.7.8 - - [06/Aug/2017:11:12:23 -0700] "GET /ebooks/chapman/ HTTP/1.1" 302 630 "https://www.google.co.in/" "{Android}"
5.6.7.8 - - [06/Aug/2017:11:12:23 -0700] "GET /sharedstyles.css HTTP/1.1" 200 2068 "https://www.google.co.in/" "{Android}"
5.6.7.8 - - [06/Aug/2017:11:12:23 -0700] "GET /ebooks/ebookstyles.css HTTP/1.1" 200 2186 "https://www.google.co.in/" "{Android}"
5.6.7.8 - - [06/Aug/2017:11:12:24 -0700] "GET /ebooks/chapman/iliadstyles.css HTTP/1.1" 200 2324 "https://www.google.co.in/" "{Android}"
5.6.7.8 - - [06/Aug/2017:11:12:24 -0700] "GET /boilerplate/redirect.php?newpage=/ebooks/chapman/ HTTP/1.1" 200 1737 "https://www.google.co.in/" "{Android}"


Observation #1: Stylesheets and page-specific scripts are requested before the page itself, with Google Search rather than the page as referer.

Observation #1a: These CSS and JS files are requested even if
--the page itself ends up not being requested at all, or
--the page is requested but is redirected to a directory that uses a different set of stylesheets (it was this that first made me aware of the phenomenon)

Observation #2: This is an http site, meaning that query details (the referer's query string) are normally suppressed in the referer. In some but not all cases, these premature requests for CSS and JS include the full search term.

not2easy

11:35 pm on Aug 6, 2017 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



I don't know if users appreciate all the prefetching that goes on, but that is how they boost the page load speed that users find so great. I read recently that they prefetch .js, .css and related resources for the first few search results. A behavior I do not want on my browser. I'm thinking that some users have such a short attention span that if the selection doesn't load at warp speed, they're gone to try another. I have wondered whether the user has to cache these "just in case" files or if Google holds the cache.

I haven't seen the behavior described (yet). I am somewhat behind schedule on dealing with logs this month. It looks like the search term is a nice bonus for the site owners, consider it a payoff for the bandwidth assumptions. (?)

lucy24

12:34 am on Aug 7, 2017 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I wonder if users realize that this means they are expending bandwidth on material they may never actually see (in the case of pages that are either redirected, or not requested in the first place)? Strikes me as a “Thanks but no thanks” situation.

Belated thought: Since the supporting file requests come from the user's own IP, does that mean we're seeing a quasi-legitimate (ymmv) use of a fake IP in the request header? Ugh. Not sure I really like that.