Update readme with browser support and FAQ section about analytics and personalization #1155
Conversation
Co-authored-by: tunetheweb <[email protected]>
westonruter
added
[Type] Documentation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Co-authored-by: tunetheweb <[email protected]>
westonruter
force-pushed
the
add/speculation-rules-faq
branch
from
272a47b to
27b1773
Compare
Co-authored-by: Barry Pollard <[email protected]>
westonruter
changed the title
There was a problem hiding this comment.
@westonruter I realize this was merged, but had it open for a while and wanted to take a look now. Leaving a bit of feedback. If there's consensus, we should be able to quickly address in a follow up PR.
cc @tunetheweb
|
|
||
| For client-side JavaScript, is recommended to delay these until the page clicks and some solutions (like Google Analytics) already do this automatically for prerender. See [Impact on Analytics](https://developer.chrome.com/docs/web-platform/prerender-pages#impact-on-analytics). Additionally, cross-origin iframes are not loaded until activation which can further avoid issues here. | ||
|
|
||
| Speculating on hover (moderate) increases the chance the page will be loaded, over preloading without this signal, and thus reduces the risk here. Alternatively, the plugin offers to only speculate on mouse/pointer down (conservative) which further reduces the risk here and is an option for sites which are concerned about this, at the cost of having less of a lead time and so less of a performance gain. |
There was a problem hiding this comment.
I find "over preloading without this signal" complicated to understand. What's a "signal"? I definitely think the language here can be simplified.
Is this supposed to mean "speculating on hover increases the chance ... over speculating on eager"?
Also since "speculating on hover (moderate)" is the default in this plugin anyway, I think it's worth formulating this response with that context, just to reiterate here that this is the default that the plugin uses.
There was a problem hiding this comment.
It's supposed to me "speculating on hover increases the chance of the page actually being visited, and so reduces the chance of any negative impact on analytics due to pages being prerendered (and being included in analytics) but not actually being seen by a user".
I agree the wording could be clearer.
And btw, it may should a bit dismissive to say "hey, if there's a bigger chance of a page being visited, then it's OK if your analytics are off sometimes", but the reality is this already happens in many cases. For example, people opening in a new tab and not actually visiting it. Or open a link, not reading it, but intending to come back to it (but never doing that).
|
|
||
| Prerendering can affect analytics and personalization. | ||
|
|
||
| For client-side JavaScript, is recommended to delay these until the page clicks and some solutions (like Google Analytics) already do this automatically for prerender. See [Impact on Analytics](https://developer.chrome.com/docs/web-platform/prerender-pages#impact-on-analytics). Additionally, cross-origin iframes are not loaded until activation which can further avoid issues here. |
There was a problem hiding this comment.
What is "until the page clicks"? Is that the most suitable term here? I would assume there's an easier-to-understand way to indicate that the page has actually become active / that the user is actually visiting the page.
There was a problem hiding this comment.
Fair point. The term we usually use is "when the prerender is activated"/"activation" since this matches the activationStart time in the Performance Navigation Timing API
| For client-side JavaScript, is recommended to delay these until the page clicks and some solutions (like Google Analytics) already do this automatically for prerender. See [Impact on Analytics](https://developer.chrome.com/docs/web-platform/prerender-pages#impact-on-analytics). Additionally, cross-origin iframes are not loaded until activation which can further avoid issues here. | |
| For client-side JavaScript, it is recommended to delay these until the prerender is activated (for example but clicking on the link) and some solutions (like Google Analytics) already do this automatically for prerender. See [Impact on Analytics](https://developer.chrome.com/docs/web-platform/prerender-pages#impact-on-analytics). Additionally, cross-origin iframes are not loaded until activation which can further avoid issues here. |
|
|
||
| Speculating on hover (moderate) increases the chance the page will be loaded, over preloading without this signal, and thus reduces the risk here. Alternatively, the plugin offers to only speculate on mouse/pointer down (conservative) which further reduces the risk here and is an option for sites which are concerned about this, at the cost of having less of a lead time and so less of a performance gain. | ||
|
|
||
| A prerendered page is linked to the page that prerenders it, so personalisation may already be known by this point and changes (e.g. browsing other products, or logging in/out) may require a new page load, and hence a new prerender anyway, which will take these into account. But it definitely is something to be aware of and test! |
There was a problem hiding this comment.
What can be done if the test leads to discovering problems? I think something should be included about that, e.g. something about modifying the personalization logic or, if that's not possible/feasible, excluding the relevant pages from speculative loading (via the filter the plugin provides).
There was a problem hiding this comment.
The options (from best to worse IMHO) are:
- Cancel speculations on personalization changes (note this happens automatically on navigations anyway, which is probably when most personalization signal changes and other state changes happen anyway).
- Update on page activation with client-side JS (plus: also could handle stale background tabs, negative: can lead to a flash of old content(
- Don't speculation on hover and only do on mousedown / "conservative" eagerness. (negative, less gain).
- Exclude personalized pages (but if this is a loging widget for example that might be ALL pages)
- Don't use speculation rules on those types of sites.
Probably not a bad idea to spell these out.
|
@felixarntz I'll defer to @tunetheweb as he's the wordsmith here. |
|
Maybe we should copy the readme into a Google Doc to better collaborate on the copy (and leverage the new Copy/Paste as Markdown feature!) |
|
I created a doc and shared it with ya'll. |
|
I've opened #1459 to track this work. |
Added FAQ lifted from @tunetheweb in a support topic reply: https://wordpress.org/support/topic/how-does-this-affect-pageview-tracking/#post-17686997