[ads] Optimize ads tab helper innerText/HTML performance

[tmancey]

No description provided.

[atuchin-m]

From DMs:

AdsTabHelper seems to:

• fetch the text from a renderer process to the browser; Raised [ads] Refactor AdsTabHelper::MaybeNotifyTabTextContentDidChange/document?.body?.innerText and [ads] Refactor Tab::reportPageLoad/document?.body?.innerText on iOS
• do it always even ads/rewards are disabled; Resolved by [ads] Optimize javascript requests for non rewards users #35205 for text. HTML is required for verifiable conversions and will be resolved by [ads] Only call AdsTabHelper::MaybeNotifyTabHtmlContentDidChange for URL redirect chains that match view-through or click-through conversions #38497 and [ads] Refactor Tab::reportPageLoad/XMLSerializer().serializeToString on iOS
• capture all the text (it could be dozen MB); Raised [ads] Restrict the amount of innerText captured for text classification purposes #38911
• doesn’t reused the captured text with the other features. Raised [ads] Refactor AdsTabHelper::MaybeNotifyTabTextContentDidChange/document?.body?.innerText #38796 and [ads] Refactor Tab::reportPageLoad/document?.body?.innerText on iOS

It also:

• it gets the serialize document as XML in addition to a text form: new XMLSerializer().serializeToString(document) , that takes even more MB; Raised [ads] Refactor AdsTabHelper::MaybeNotifyTabHtmlContentDidChange/XMLSerializer().serializeToString(document) #38794 and [ads] Refactor Tab::reportPageLoad/XMLSerializer().serializeToString on iOS
• do capturing multiply times for one page: after DidFinishNavigation + after DocumentOnLoadCompletedInPrimaryMainFrame (onload). Raised [ads] AdsTabHelper::ProcessNavigation called several times

As for Chromium it looks they prefer to:

• capture text in renderer process and consume it here if possible (try to avoid send it over IPC); This will partially be resolved by [ads] Refactor AdsTabHelper::MaybeNotifyTabTextContentDidChange/document?.body?.innerText #38796
• limit capturing only when related features are enabled; This will be resolved by [ads] Optimize javascript requests for non rewards users #35205 and [ads] Refactor AdsTabHelper::MaybeNotifyTabHtmlContentDidChange/XMLSerializer().serializeToString(document) #38794
• limit the number of captured symbols;
• reuse the captured text for multiply purposes.
  https://source.chromium.org/chromium/chromium/src/+/main:chrome/renderer/chrome_render_frame_observer.cc;l=668-713. This will be resolved by Building on Windows in Release mode with official_build=false fails.  #3879, [ads] Refactor AdsTabHelper::MaybeNotifyTabTextContentDidChange/document?.body?.innerText #38796, [ads] Refactor Tab::reportPageLoad/document?.body?.innerText on iOS and [ads] Refactor Tab::reportPageLoad/XMLSerializer().serializeToString on iOS

Also we can take a look at Chromium/Brave page distillers (used in Speedreader) as an alternative.

[tmancey]

regarding do it always even ads/rewards are disabled;, we need HTML for both users who have/have not joined Rewards. innerText is not required if a user has not joined Brave News ads or Brave Rewards.

[aseren]

Regarding do capturing multiply times for one page: after DidFinishNavigation + after DocumentOnLoadCompletedInPrimaryMainFrame (onload). concern.
We are doing JS requests in DidFinishNavigation only in case of same-page navigation. So we will run our JS requests twice if the web page loads and then does the same navigation for some reason. This was done to support Single-Page-Applications, in which the web page content can be changed with the same-page navigation.
We need to find better ways of handling this page content change for Single-Page-Applications rather than listening for each same-page navigations.

[tmancey]

Closing issue as a duplicate of #35205

[bridiver]

I am reopening this issue because it's not clear what #35205 is supposed to be since it does not contain any details at all and the PR that closed it does not address all of the issues here. In particular we're still calling XMLSerializer on every page load with or without rewards and that needs to be changed.

[bridiver]

also do we need a similar ticket on ios? Are we doing something similar there @brave/ios and if so, can we consolidate this logic for what should get injected and under what conditions?

[tmancey]

@bridiver see description for links to issues for each of the bullets.

[atuchin-m]

any progress here?

[tmancey]

@atuchin-m These calls were refactored to occur only for Rewards users. We've had a few other priorities, but we plan to return to them soon. They're part of this quarter's goals.