Automatic scroll randomly stops before highlighted text

Hi,

Does this happen for the same search phrase all of the time, or sometimes it scrolls and sometimes stops?

If it’s inconsistent, then it’s very likely a conflict with a 3rd party script, which may also tries to scroll the page – maybe to reset to the top position or something similar. The inconsistency could be due to the fact that on each page load the scripts are fetched a bit faster/slower depending on the client and server load and response times. When the other script executes during the scrolling, then it overrides and stops. At least that’s what I am guessing.

Best,
Ernest M.

wpdreams the search engine always scrolls. The problem appears rarely, but when it does, the search engine stops before the highlighted words and they are not displayed on the monitor, so you have to scroll manually, but I doubt our users will know that. We are using the search engine in a manually started autocomplete search mode only. The issue never happens in standard text only pages created with text blocks, where the text is copy pasted from a document. The issue started happening on pages with custom html blocks where the text is imported with HTML + CSS code.

I don`t think it is script loading related because the issue never happens two times in a row or more. If I click the same search result a second, third, fourth, fifth etc. times the auto scroll runs correctly. If I then search for another string, the issue might happen again, but only the first time and it normalizes when you click again the same search result.

• This reply was modified 1 year, 8 months ago by dhampius.

Thank you for the clarification!

?If I then search for another string, the issue might happen again, but only the first time and it normalizes when you click again the same search result.

That tells me it has something to do with page/script loading. The second time the browser may serve the page from the local cache and it’s loaded differently (usually faster).

Maybe the styling of the blocks is not yet applied (if the CSS is in the footer) or a script needs to do something to the blocks – inject text, before or after or within. At that time the browser already tries to scroll to the calculated location, but after a modification that is no longer the correct “y” coordinate. That could very well explain why it happes only on the first click, as on the second the browser uses the local cache and pre-applies everything.

If it is styling related, then make sure all CSS is within the header, and none in the site footer. Lazy style loaders (like Cloudflare rocket loader etc..) can also delay the styling, and apply them too late. If there are any custom animations for displaying the blocks (especially tempering with the height), that could also affect it, as well as any scripts which may change the structure, add text, elements etc.. to or inbetween the blocks.

Thank you for your answer!

We are using WP 6.1.1 with the free version of Cloudflare and WP-Optimize as a cache plugin. The CSS is set within the HTML with the style tag, so the CSS is loaded along with the HTML.

Is there possibly a way to avoid the issue with the search engine from happening again with some kind of configuration?

Otherwise, maybe we should drop the Cloudflare or the cache plugin to fix this?

Thanks in advance for your answers.

I honestly don’t know, the exact cause of the issue would have to be located first, which is not known yet. The big problem is, that these are extremely hard to find. Scripts and styles have to be removed one-by-one to see which may actually cause the conflict, as there is no way to debug the browser scrolling behaviour.

If you find any configuration or setup that prevents this from happening, then I suggest sticking to it, because even with that it is very hard to determine what line of code or event causes the issue.

All the best,
Ernest M.

I have a testing instance on a virtual machine. I cannot reproduce the issue there at all, which means that you are correct, indeed. It is something external that messes with the automatic scroll. However, me or people from my team cannot reproduce the issue on production too, at the moment.

Which leads me to 3 possible reasons that might be root cause of this. 1. Cloudflare , 2. A specific Google font that loads at the beginning of the HTML. 3. The shared hosting server, sometimes this server tends to get attacked a lot, and when this happens it freezes and starts to lag, our website even gets down sometimes. So I believe in case of slowness, this issue could also occur.

I am thinking it is possible reason number 2 – the external google font we are using on our HTML+CSS pages – link href=’https://fonts.googleapis.com/css?family=Noto Serif’ rel=’stylesheet’ because never has the issue happened on the standard text only pages. Also the font is in the beginning of the html so it needs to be externally loaded and affects the entire text of the page. Wpdreams, what do you think?

• This reply was modified 1 year, 8 months ago by dhampius.

Hi,

wpdreams I confirmed that the issue comes from the external font load from fonts.googleapis.com/css?family=Noto Serif. After the user uses the search engine and lands on a page, cache is saved in their browser and the issue does not happen again.

I was wondering between installing “Optimize My Google Fonts” WordPress plugin to help optimize the loading of the Google Fonts or adding a script to load the fonts async. with all other scripts:

function load_fonts_asynchronously() {
wp_dequeue_style(‘notoserif’);
wp_enqueue_style( ‘notoserif’, ‘https://fonts.googleapis.com/css?family=Noto+Serif&display=swap’, array(), null );
}
add_action(‘wp_enqueue_scripts’, ‘load_fonts_asynchronously’);

However, I am aware that the async. script will always load and will not benefit from the cache plugin. So I decided to stick with the font plugin I mentioned above.

I would be very thankful, if you could share your opinion and approach based from the info I have provided and about my decision. You can also mark the topic as solved after you answer. Thanks.

Hi!

I would stick with the plugin in your case. Making the font loading asynchronous is not the best idea – as it will stay asynchronous even after the first load, while in the other case it is already loaded from the browser cache.

All the best,
Ernest