Defining Ignored Server-Side Code-Blocks

[Steven G]

Im trying to figure out if there is some easy way to define blocks of server-side code that PageSpeed should simply ignore and leave as is. That is, Id like to mark a single image that isnt lazy-loaded without disabling lazy loading for all images; Id like to leave a single javascript code-block as is without disabling rewrite_javascript.

Im envisioning that this would be an open/close marker-set thats defined in the .conf file and used by placing before and after the server-side code to mark the blocks that should be ignored.

The reason for my needing this functionality is because PageSpeed appears to break tracking functionality across several trackers by removing required line-breaks or by inserting code that interferes with proper loading.

Is the ability to simply leave a predefined block of code as is possible and, if so, how can this be achieved?

System Specs:

OS: CentOS 7

Server: Apache 2.4

Latest stable version of PageSpeed

[Jeff Kaufman]

This is something we've been meaning to add:
https://github.com/pagespeed/mod_pagespeed/issues/1320

On the other hand, if there are trackers that we're breaking in our
default configuration, that's also a problem and we'd like to fix
that. Are you up for sharing any details about which ones or how we
break them?

> --
> You received this message because you are subscribed to the Google Groups
> "mod-pagespeed-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mod-pagespeed-di...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mod-pagespeed-discuss/99701a92-2cea-4849-b1f6-60902b5190ca%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Steven G]

Sure, at this point its removing line breaks from Googles remarketing tag, which is definitely a problem as it looks like it turns the closing script tag into a comment by removing the line break between it and the previous line, and appears to change the comment type ( from /*[code]*/ to //[code] ), which may or may not be a problem on its own. 

Ive been working on implementing a marketing automation system called Mautic and it uses a tracking .gif, which is placed before the closing body tag. It appears that this tag is lazy loaded, which means a user visit wont be tracked unless the user scrolls to the bottom of the page.

Im willing to help any way I can, please let me know if theres any more info I can provide.

As a side note, I really like what PageSpeed offers and I appreciate the effort to be aware of all tracker configurations. It just seems to me like a highly complex project to be able to navigate the ever growing world of trackers. Just looking at Ghostery's data, there are already a ridiculously high number of trackers out there. Unless youre working with Ghostery-like companies and somehow automating tracker recognition->avoidance, Id be curious to know what the plan might be to achieve such a thing as "total tracker support".

[Jeff Kaufman]

On Thu, Aug 25, 2016 at 10:23 AM, Steven G <environ...@gmail.com> wrote:
> Sure, at this point its removing line breaks from Googles remarketing tag,
> which is definitely a problem as it looks like it turns the closing script
> tag into a comment by removing the line break between it and the previous
> line, and appears to change the comment type ( from /*[code]*/ to //[code]
> ), which may or may not be a problem on its own.
>

It sounds like you're saying it's turning:

<script>
/* <![CDATA[ */
document.write("A");
/* ]]> */
</script>

into:

<script>//<![CDATA[
document.write("A");
//]]></script>

(Normally PageSpeed removes all JavaScript comments, but if it can't
tell whether your page is xhtml or not it leaves in CDATA ones.)

This is a valid change to make because </script> can't be commented
out. In fact, it can't be included in an inline script at all. When
the browser sees <script> it scans ahead until it gets to the next
literal </script> and treats what's between the tags as JavaScript.
This is before it thinks about JavaScript comments!

Is this breaking something, or did it just look strange to you?

> Ive been working on implementing a marketing automation system called Mautic
> and it uses a tracking .gif, which is placed before the closing body tag. It
> appears that this tag is lazy loaded, which means a user visit wont be
> tracked unless the user scrolls to the bottom of the page.

Have you turned on lazy-load images? Or is this happening with the
default configuration?

>
> As a side note, I really like what PageSpeed offers and I appreciate the
> effort to be aware of all tracker configurations. It just seems to me like a
> highly complex project to be able to navigate the ever growing world of
> trackers. Just looking at Ghostery's data, there are already a ridiculously
> high number of trackers out there. Unless youre working with Ghostery-like
> companies and somehow automating tracker recognition->avoidance, Id be
> curious to know what the plan might be to achieve such a thing as "total
> tracker support".

Our general approach is not to special-case trackers and keep from
breaking them, it's to try to make safe changes that don't break
anything, which includes not breaking trackers.

Jeff

[Steven G]

Correct, the CDATA comments are changed and all the lines between them are merged into one line. It does appear to break the tag as Google Tag Assistant plugin states that removing the line breaks can cause problems and Im seeing a "not implemented" error related to the tag in the AdWords portal. I wasnt seeing these issues before installing PageSpeed. These things lead me to believe its related to PageSpeed. Im willing to accept that Im wrong if thats the case.

Ive not explicitly enabled or disabled lazy-loading. I am under the impression that onload="pagespeed.CriticalImages.checkImageForCriticality(this);", which is added to the image tag, is related to lazy-loading. If this is not the case, my apologies for the mistake. But I would like to confirm if that function can lead to any delays or prevention of that image being loaded properly.

Fully understood on the general "dont break things" rule :)

Thanks for the responses so far.. Really appreciate it.

Steven

[Jeff Kaufman]

On Thu, Aug 25, 2016 at 11:45 AM, Steven G <environ...@gmail.com> wrote:
> Correct, the CDATA comments are changed and all the lines between them are
> merged into one line. It does appear to break the tag as Google Tag
> Assistant plugin states that removing the line breaks can cause problems and
> Im seeing a "not implemented" error related to the tag in the AdWords
> portal.

Are you saying that the AdWords portal is scanning your site, and is
not recognizing that you have the tag installed? That would make
sense, if PageSpeed's optimization is changing the tag so that the
portal can't recognize it. If so, can you give me some sort of
screenshot of the error you get in the portal so I can follow-up
inside Google with the AdWords team?

Or are you seeing the tag actually not working, in the sense of not
dropping the remarketing cookies you're trying to drop?

>
> Ive not explicitly enabled or disabled lazy-loading. I am under the
> impression that
> onload="pagespeed.CriticalImages.checkImageForCriticality(this);", which is
> added to the image tag, is related to lazy-loading. If this is not the case,
> my apologies for the mistake. But I would like to confirm if that function
> can lead to any delays or prevention of that image being loaded properly.

The critical image beacon is on by default in order to figure out
which images it should inline. The idea is that we should probably
only inline images that are visible on the first load, and to do that
we need to find out where these are in real browsers. If lazyloading
is enabled, though, then we'll also use the beacon to see which images
not to lazy-load, since ones typically visible on the first load are
likely going to be needed right away. Inlining doesn't break beacons
because PageSpeed doesn't inline things from other sites by default,
and a beacon is going to be loaded from a different domain.

(I think we do check images for criticality even if they're third
party, because it means the inlining and lazyloading can share more
code, but it's slightly inefficient and can be confusing.)

Jeff

[Steven G]

Are you saying that the AdWords portal is scanning your site, and is
not recognizing that you have the tag installed?  That would make
sense, if PageSpeed's optimization is changing the tag so that the
portal can't recognize it.  If so, can you give me some sort of
screenshot of the error you get in the portal so I can follow-up
inside Google with the AdWords team?

Or are you seeing the tag actually not working, in the sense of not
dropping the remarketing cookies you're trying to drop?

Yes, AdWords is scanning my site and producing an error, under the Shared Library > Audiences section, pertaining the remarketing tag, which wasnt being produced before PageSpeed was installed. The exact error is:

We haven't detected the Google Analytics remarketing functionality on your website

We didn't find the Google Analytics remarketing tag on any of your pages. Check that the remarketing tag is implemented. Learn more about the remarketing tag.

 

The critical image beacon is on by default in order to figure out
which images it should inline.  The idea is that we should probably
only inline images that are visible on the first load, and to do that
we need to find out where these are in real browsers.  If lazyloading
is enabled, though, then we'll also use the beacon to see which images
not to lazy-load, since ones typically visible on the first load are
likely going to be needed right away. Inlining doesn't break beacons
because PageSpeed doesn't inline things from other sites by default,
and a beacon is going to be loaded from a different domain.

(I think we do check images for criticality even if they're third
party, because it means the inlining and lazyloading can share more
code, but it's slightly inefficient and can be confusing.)

 

Just to clarify, this tracking gif lives on my server; the entire marketing automation platform is on my server. Im not sure if that makes a difference based on what youre saying here.

Steven