Closed GoogleCodeExporter closed 9 years ago
Original comment by jmara...@google.com
on 11 Apr 2013 at 12:52
The reason for this happening is that assets.aura.travel and
maps.googleapis.com are already present in the HEAD (link/script). But
assets.pinterest.com is only in the BODY in a div.
Currently insert_dns_prefetch filter ignores domains in HEAD and only inserts
prefetch tags for domains in the BODY. The reasoning for that is:
- Browser lookahead parsing downloads resources and does dns resolutions as
part of that. Inserting dns prefetch tags is redundant if we are doing it for
one of those early resources; but it is useful if we can do it for some
resource which will get downloaded later and the DNS lookup can be done apriori
- We want to make the bytes in the initial CWND useful. So allowing a resource
to be downloaded is better than sending out a DNS resolution
- HEAD is our heuristic boundary for this usefulness. Before HEAD - not useful;
after HEAD - useful.
Let me know if this sounds reasonable. If there is a good reason to insert dns
prefetch tags for HEAD resources we can do it.
Original comment by bharathb...@google.com
on 12 Apr 2013 at 12:53
What you are saying makes sense provided that the lookahead parsing behavior is
standard for the resource domain lookups in HEAD(I could not find an RFC or
standard for this in a brief search).
The second issue re: should the prefetch for the domains in the BODY be at the
beginning or the end of HEAD? I am still inclined to say "beginning" - and
speculate that the overall page load time is faster even if the first window of
usefulness is made less useful by the extra tags. Domain lookups could exceed
200ms, which is slower than the second window :) but then again... maybe
someone could do some stats on this.
Cheers,
Luci
Original comment by l...@aura.travel
on 13 Apr 2013 at 9:13
I don't think the lookahead behaviour is a standard. This was just from our
discussion of the usefulness of the dns prefetch tags.
Original comment by bharathb...@google.com
on 15 Apr 2013 at 7:14
Issue 717 has been merged into this issue.
Original comment by jmaes...@google.com
on 2 Jun 2013 at 10:29
insert_dns_prefetch's lack of coverage was also noticed on aamjanata.com.
Original comment by jmara...@google.com
on 3 Oct 2013 at 1:11
On aamjanata.com I see that there's a script in the body whose domain is not
referenced in the head:
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js">
any thoughts on why we don't add a DNS prefetch tag for that?
Also, I wonder if it's worth revisiting the policy in this filter. DNS
Prefetch is focused only on loading domains referenced in the body that were
not already referenced in the head. But if the head is quite large, then it
might take several packets to deliver it to the browser, so you could argue
that an early DNS prefetch would really help even in that case. But DNS
prefetch does not try to estimate that. It just assumes anything in the head
is early enough.
Original comment by jmara...@google.com
on 3 Oct 2013 at 1:19
Hmm, it seems to work fine when I tested. Loading
http://aamjanata.com/?ModPagespeedFilters=insert_dns_prefetch I see we insert
the following dns-prefetch links.
<link rel="dns-prefetch" href="//pagead2.googlesyndication.com"><link
rel="dns-prefetch" href="//ajax.googleapis.com"><link rel="dns-prefetch"
href="//s0.wp.com">
It looks like the filter isn't currently enabled on the site though, as just
loading aamjanata.com doesn't reveal any prefetch links. This filter does take
a page refresh to take effect, since we have to scan the whole HTML to collect
the domains to prefetch and store in the property cache.
Original comment by j...@google.com
on 3 Oct 2013 at 3:17
Hi,
I'm Vidyut. aamjanata.com is my blog.
The filters currently enabled are:
pagespeed EnableFilters
rewrite_images,insert_dns_prefetch,inline_preview_images,resize_mobile_images,ma
ke_google_analytics_async,extend_cache,lazyload_images,canonicalize_javascript_l
ibraries,rewrite_css,rewrite_javascript,collapse_whitespace;
As you see, insert_dns_prefetch is enabled, and the server is not throwing
any errors about unrecognized filters while restarting. The prefetch tags
are not getting added to the page with this configuration.
http://www.webpagetest.org/result/131003_C6_PKK/
However, I tried your link with the query adding the filter, and it did
work. This might help pinpoint the issue?
http://www.webpagetest.org/result/131003_AC_PN8/
As you see, the gaps in the waterfall are closing with DNS prefetch on, so
the filter is clearly useful when working.
It is strange that adding it as a query is working, but not adding it in
the configuration. I wonder what it is that I'm doing wrong... I'm hoping
it turns out to be some silly configuration goof up. Does the sequence in
which the filters are listed matter? Should I experiment with putting
prefetch last/first to see if that makes it work?
Vidyut
--
Vidyut
aamjanata.com
Twitter: @Vidyut
Diaspora: vidyut@ilikefreedom.org
Facebook: http://facebook.com/theVidyut
Phone: Allergic
Telephone: Forget it.
Mobile phone: Forgot
Original comment by wide.aw...@gmail.com
on 3 Oct 2013 at 3:47
Is it possible that you've turned it on in pagespeed.conf but off in a
Directory directive or .htaccess file?
Original comment by matterb...@google.com
on 3 Oct 2013 at 5:10
Ah, there's also the point that adding a query param won't serve cached content.
Perhaps you could try with some different, random parameter? ?cache=busted or
similar?
Original comment by matterb...@google.com
on 3 Oct 2013 at 5:11
Nope. There is no Pagespeed turned off on this server at all. I haven't
gotten around to doing it (for some subdomain pages with already optimized
static content).
Vidyut
Original comment by wide.aw...@gmail.com
on 3 Oct 2013 at 5:44
I am seeing dns-prefetch tags being inserted on aamjanata.com after
shift+refreshing a few times, but it is inconsistent. I have a suspicion that
this filter might be interacting poorly with your http cache setup. This filter
can take a page refresh or two before it starts inserting the tags, since
mod_pagespeed first needs to scan the html to collect the domains to prefetch.
I think varnish might have cached one of the first views of the page, which
won't have prefetch tags inserted yet. Can you try bypassing varnish and see if
the tags are being inserted consistently or not?
Original comment by j...@google.com
on 4 Oct 2013 at 2:46
Tags are being inserted inconsistently.
Varnish has been completely purged several times to be on the safe side in
last day or so and the filter has always been on. In theory, Varnish
shouldn't have had a version without prefetch to cache at all, since the
varnish was installed after the pagespeed.
Just to be clear that there is no question of an inefficient cache purge, I
had deleted the varnish cache physically and recreated it in another place
to rule that out for dead certain, yesterday.
Vidyut
Original comment by wide.aw...@gmail.com
on 4 Oct 2013 at 4:28
There is something strange going on with the filters. For example, if you
add the prefetch as a query on the url, the CDN rewrites don't happen, but
progressive jpegs work perfectly. This is also consistent.
http://www.webpagetest.org/result/131004_DZ_D2D/
The CDNs that ought to have been used are aj1-cdn.appspot.com and
aj2-cdn.appspot.com - you will see them being used without the filter added
as query along with inconsistent progressive jpegs and compressed images
results.
Am going to make the cache size really large to rule out insufficient space
leading to url being served fresh (and not completely written) each time.
Just to see what happens. In a few hours.
Vidyut
Original comment by wide.aw...@gmail.com
on 4 Oct 2013 at 4:34
Reviewing some old open issues.
Looking at aamjanata.com again, I'm not able to reproduce the flakiness with
insert-dns-prefetch. It looks consistent now. Did you find the situation
improved after increasing the cache size?
Please reopen if you still feel there are any issues with this filter.
Original comment by j...@google.com
on 14 Apr 2014 at 3:22
Yes, that problem was solved immediately. I think someone kept it because
it needed to be handled better anyway - or something. Don't recall.
--
Vidyut
aamjanata.com
Twitter: @Vidyut
Diaspora: vidyut@ilikefreedom.org
Facebook: http://facebook.com/theVidyut
Phone: Allergic
Telephone: Forget it.
Mobile phone: Forgot
Original comment by wide.aw...@gmail.com
on 14 Apr 2014 at 3:40
Original issue reported on code.google.com by
jmara...@google.com
on 21 Mar 2013 at 12:58