Significant slow down with adobe type kit

Hi @delanthear,

complianz.js doesn’t load any files from third-party services. It either blocks, allows services based on the user preferences. The services are loaded per default, but some integrations require a different reload of scripts that Complianz might handle.

If this is the case for Adobe, I don’t know. Do you have the exact implementation of Adobe Fonts, and if Complianz blocks Adobe prior to consent on your system? So I can check?

I would guess the delay is only experiences when you’re a new visitor, any subsequent visits should be handled by caching to optimize the experience.

This is true for page speed tooling as well.

regards Aert

Hi! We’ve using the Custom Adobe Fonts (Typekit) plugin by the Astra team and Complianz successfully blocks loading the fonts until the cookies are agreed to.

I was talking about Complianz delaying the load based on seeing this in the inspector. I’m probably misunderstanding how it works though ??

More mystery. I think the delay appears to be because when you have both Complianz AND Custom Adobe Fonts (Typekit) activated, the front page is loaded twice, once as the initial request, and then later on again while loading the stylesheets. If you deactivate one of those plugins, the issue goes away.

Hi @delanthear,

I’ve set this up with the aforementioned theme and plugin, and blocked Adobe Fonts in Complianz. Although I am not sure what the issue would be yet, because on my test environment, the font sources seem to load almost instantly (between 20 and 39ms) after providing consent in the Cookie Banner.

Example: https://filthy-fox-xogo.instawp.xyz/

Hi, you can see in your example the front page being loaded twice. See image. If it’s a large html file, it has to load the file twice before continuing with some of the other things like font loads.

I found if you disable either of the two plugins, this double load disappears.

Hi @delanthear,

I would say that the way that this is being displayed in the Network tab when blocking Adobe Fonts, is mainly because of how the Cookie Blocker has to operate.

You will find that this behavior doesn’t occur anymore as soon as you stop blocking Adobe Fonts, by deactivating its’ integration slider under Complianz > Integrations > Services, while both the Custom Adobe Fonts plugin and Complianz are still enabled.

Kind regards, Jarno

So is it working as designed for the browser to have to load the html page twice when adobe fonts are used? That adds a significant amount time to the load, especially if it’s a big page.

Why does it need to load the page again?

Hi @delanthear,

Please feel free to elaborate on how you’ve discovered that blocking Adobe Fonts results in “loading the HTML page twice”, because I haven’t been able to confirm that this is in fact what’s happening here.

The first instance visible in the Network tab is of type “document” while the latter is a “stylesheet”.

Kind regards, Jarno

I might be misinterpreting the inspector, but take a look at this image

You can see right at the far left of the timeline, a load line. This is for the html docment at the top of the list.

Then I’ve clicked on the second entry load as the stylesheet. The inspector has highlighted a different section in the timeline where this occurred on the right

On the right, it shows how that second load was initiated, and you can see it came from the original page load.

It’s easier to see the impact on my affected site, because it’s a much larger page:

Instead of the initiator chain, which looks the same, I’m showing you the timing screen. This shows that the second load was queued almost a 1 second after the first load, waited half a second for a response from the server and loaded in 5ms. Without the combination of custom fonts and complainz, this section of the load never happens.

I might be misunderstanding what’s go on here, and this actually is representing it reparsing the file. I’ll see if I can see a double load in apache logs.

• This reply was modified 1 year, 5 months ago by delanthear.

Just checked in server logs and it does look like the page is requested twice.

You can see the second load having the first load as the referrer:

my-ip xxxxxxxxxx.com - [23/Jun/2023:13:55:29 +0000] "GET /double-load/ HTTP/1.1" 200 40841 "https://xxxxxxxxxx.com/double-load/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0" | TLSv1.2 | - - 0.000 HIT 0 NC:000000 UP:- cdnreq
?
my-ip xxxxxxxxxx.com - [23/Jun/2023:13:55:29 +0000] "GET /double-load/ HTTP/1.1" 200 40841 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0" | TLSv1.2 | - - 0.000 HIT 0 NC:000000 UP:- cdnreq

Hi @delanthear,

I can’t say what the exact reason is; but with the Adobe Fonts integration enabled in Complianz, the plugin just blocks the known Adobe Fonts/TypeKit sources before consent is obtained.

Which in this case blocks a stylesheet with ID “custom-typekit-css-css” from use.typekit.net.

I’m not sure if there’s much I can do on our end to change that. If blocking these fonts does not yield the desired behavior on your website, you could decide to disable the Adobe Fonts integration instead.

Kind regards, Jarno

Hi, I think you need to try and get to the bottom of this. Running the custom fonts plugin on it’s own doesn’t cause this issue, but when Complianz is enabled it happens. It’s a bit concerning that it causes a second page load as that is extra load on the servers, as well as the performance hit of both loading and parsing the second page. Speed is important!

I guess it might make sense for me to try with a different adobe fonts plugins to see if a combination stops it happening ??

Hi @delanthear,

Does the behavior still occur when you have both Complianz and the Adobe Fonts plugin enabled, but when you disable the Adobe Fonts slider under Complianz > Integrations > Services?

If the above resolves the described behavior, it means that the behavior is the sole result of Complianz blocking the Typekit CSS file (because it doesn’t happen anymore even though both the Complianz & Adobe Fonts plugins are still enabled).

And in this case, the only change made as a result of enabling the Adobe Fonts integration is that it adjusts the following line that contains the stylesheet import:

<link rel="stylesheet" id="custom-typekit-css-css"  media="all">

So that it uses the following syntax, which results in the CSS file being blocked before consent is obtained:

<link data-service="adobe-fonts" data-category="marketing" rel="stylesheet" id="custom-typekit-css-css" href="#" data- media="all">

We’re always open to contributions and suggestions from the open-source collaborators of the WordPress Community, so please feel free to submit a pull request on GitHub, if you wish to suggest an alternative approach.

Kind regards, Jarno

Hi, sorry for the delay in replying. Been busy!

Disabling the Adobe font integration in Complainz DOES prevent the reloading of the whole page again and resolves the very slow load of the font files meaning there isn’t an obvious page change.

Something about that integration is causing both Chrome and Firefox to reload the entire base html page again as a style sheet :/

This really feels like an unintended buggy behaviour somewhere, but I’ve no idea where to start to even work out why! I guess we need to ask someone who knows how the rendering spec works as it’s in both Chrome and Firefox, which are different engines? Far beyond me!

Hi @delanthear,

I see that you’ve marked the thread as unresolved; we currently have no known alternative to block these Typekit fonts that also prevents the described behavior.

You can disable the Adobe Fonts integration to restore the original state of the fonts, if needed.

We would still gladly review pull requests on GitHub suggesting a different approach.

Kind regards, Jarno