How to stop removing preconnect & onload switching?

Many plugins sometimes add too many preconnect and preload headers, and there is such thing as having too much of those.

You likely have the header cleanup option enabled. You can disable that on the settings and it will stop.

Thanks. Disabling this helped a bit. Preconnect is back again.
But the second CSS link rel is still missing

FVM converts this

<link rel="preload" as="style" href="$fontlink" />

to

<link rel="preload" as="style" href="fontlink...." importance="auto">

And this one is missing completely
<link rel="stylesheet" href="$fontlink" media="print" onload="this.media='all'" />

The option to remove print CSS is not activated

For the media=”print” I’ll need to check, but it’s either merged or removed (it may be a bug).

If you have control over the link tag and considering the method you are using, you should change it to a preload instead, like this:
<link id="yourcssidhere" rel="preload" as="style" href="$fontlink" media="all" onload="this.rel='stylesheet'" />

It’s basically the same, except that it’s faster.
With your method, the file is only downloaded when javascript is available.
With my code the file starts to be downloaded earlier, and then it executes earlier when javascript is available.

yes I could merge those two links to one as you mentioned it.
But there is a reason why they are separated

N.B. We can’t go full preload as it isn’t widely enough supported. In fact, at the time of writing, about 20% of this site’s visitors would be unable to make use of it. Consider the print stylesheet a fallback.

Only since end of 2020 newer browser support the preload tag.
So as a fallback, it’s split into two requests.

Preload is pretty much supported everywhere now.
https://caniuse.com/?search=preload

Either way, it doesn’t matter. In the example I gave you, if a browser doesn’t support preload it will just ignore it and load it when JavaScript is available.

With your code you are only downloading the css file when the onload even triggers anyway.
With my code, the browsers that support preload will start download it async, then execute when the onload even triggers. Browsers that do not support, will ignore the file until when the onload even triggers, in which case will then load it just like your code.

You can try it and do a browser test.

I’ll check if the plugin is removing it by mistake, but it may take a while as I am busy at the moment. Sorry about that.

See the first post. I am not downloading it when JS is available.

1. Preconnect
2. Preload
3. Swap when page is loaded (as fallback)

Sorry about that, didn’t notice the preload + onload separately.

But you can still do the swap directly on the preload. If you swap preload with stylesheet onload, it should work exactly the same and avoid the extra link tag.
It’s just less code.

no problem. but unfortunately this is not the way it will work
preloading “print” styles have a lower browser priority, that’s why the first preload link is a normal one. the js fallback switch only works for “print” styles, so a combination is not possible.

I suggest – if you find the time – to check out the link I added in the first post. The speed analysis is very good and shows whats the best approach currently.

Will wait til you checked why the “print” stylesheet gets removed.
A data-field to exclude certain files/tags would be awesome data-fvm=”exclude” or something like this.

I have all the static output via cdn.
I manually added rel=”preconnect” at the very beginning to the file header.php. Including for the cdn domain. Your plugin truncates these entries.

After disabling the header cleanup function, the entries preconnect appear. But they appear below the first preload block generated by your plugin and other code (Before the second preload block).

That is, they go down lower in the code (although in the same header.php several preloads are registered and they are at the very top as a result). The meaning of preconnect is lost.

• This reply was modified 3 years, 4 months ago by eddie.

Maybe add the ability to manually prescribe the preconnect and preload, which will be displayed in the code above all the preloads generated by the plugin?

And if we are talking about cleaning the head, then it would be great to add cleaning:
1. feed of the type url/feed (3 lines);
2.

<link rel=”alternate” type=”application/json” href=”url/wp-json/wp/v2/posts/1222″ />
<link rel=”alternate” type=”application/json+oembed” href=”url/wp-json/oembed/1.0/embed?url=… />
<link rel=”alternate” type=”text/xml+oembed” href=”url/wp-json/oembed/1.0/embed?url=…&format=xml” />

Good suggestions @ediet

As you can see, there has been no response in three months.
So I assume the author has no priorities to “fix” this. Unfortunately.

@phloo Maybe when several people raise the problem, everything will change.

At the moment, you would need to disable the header cleanup option.

This option removes it, because a lot of plugins and themes add way too many preload headers, thus the browser is actually busy loading unnecessary stuff.

But I understand it breaks manual coding, sorry about that.
I will add a separate option for that soon.

Thanks for reporting

Thanks for replying @alignak but this suggestion was discussed 4 months ago.

See my reply: https://www.ads-software.com/support/topic/how-to-stop-removing-preconnect-onload-switching/#post-14202633

Plugin still modifies custom code even without header cleanup enabled.