6956 Characters added to DOM

Hi,

Sure!

It probably counts in when the results are displayed after a search query – for that it’s entirely possible (depending on the number of results etc..), but will not affect the page performance nor the SEO in any ways.

On it’s own the settings and the results container are moved to the document end on page load so they are correctly displayed in the overflow, but these are not visible and will not affect the page in any ways either.

All the best,
Ernest

Thank you for the reply, I understand these will not affect page use. Instead I am referencing the concern as flagged by SEMRush for SEO Standards: https://i.imgur.com/YraAxTt.png

Oh, I see – you don’t really have to worry about that. It likely counts when a user search is triggered and results are displayed, which is normal for live/ajax searches (it’s the principle of functionality). It does not affect the SEO in any way though.

All the best,
Ernest

Just to confirm, you are stating that SEMRush is wrong here in the 2nd paragraph: “Search engines have begun focusing on pages that contain more content. That’s why a higher text to HTML ratio means your page has a better chance of getting a good position in search”

No, not at all. That statement is correct. It’s always better to have the least possible elements that you can.

I’m stating that elements are added via user interaction, which does not affect SEO – because the count is different in that case, initially there is nothing added.

I just noticed that you are reffering to the Pro version here – please use the ticket system via this link, as it is unfortunately prohibited to discuss it in these forums (by forum rules).

All the best,
Ernest

This is NOT correct. The characters added to the DOM are on page load and NOT user interaction: view-source:https://ellasbubbles.com/accessible-showers/ella-roll-in-wheelchair-accessible-shower-base-48×37-center-drain/

My Pro support has expired…. so you essentially told me to stop talking ??

Noted, will review

It’s not me, unfortunately the forum rules are like that ??

I don’t see anything suspicious on that page, nothing extra seems to be added – I think the tool may detect some other attribute or other changes as well count that towards(?) the overall count. 26k characters is a lot, that would be visible somewhere on the DOM.

Previous product was deleted (took you to page not found)

Here you are: view-source:https://ellasbubbles.com/accessible-showers/wheelchair-accessible-and-ada-showers/

Thanks! The previous also worked, because the search was visible. Nothing suspicious here either, everything looks perfectly fine.

All the best,
Ernest

So if anyone plans on using your plugin on a page, they should be prepared for 26,000 characters of DOM code to be added to that page

Absolutely not – what I’m saying that I don’t see anything added on that URL, let alone 26k characters added to the page on page load. The counter may be triggering to attribute or node changes as well, which could explain that number, but there is almost nothing added on page load – you can check it yourself too.

The new page I referenced above has over 7,000 characters. You can simply search for “wd-asp-instances” on the view source page, see attached screenshot references: https://imgur.com/a/ClL0dfA

Oh I see what you mean now. That is however not injected by the plugin. You are using rocket loader, which removes the scripts and injects them later on, that’s why it’s probably reported as injected. Normally it’s on the page long before the page load event activates.

Usually inline scripts shouldn’t be defered, but I guess rocket loader takes care of that. It has ~7k characters for 2 search instances, which is perfectly normal. If you look at the woocommerce stripe init inline scripts, for each configuration they use around ~3k characters, and there is two of them. These are common and does not affect seo (as they are scripts to initialize data) nor the page load speed.

All the best,
Ernest

Great, thanks Ernest!