Performance impact of /iawp/search

Hi Christian,

Thanks for getting in touch about this.

It looks like the request is taking 893ms, which is a pretty normal time, so I don’t think anything is wrong. The only way to speed it up would be to increase how fast your site loads WordPress for Ajax and REST API requests, which usually requires faster hosting or reducing the number of plugins on the site. That might not be worth the hassle IMO.

Since Independent Analytics loads this request after the site is already finished loading, it doesn’t have any material effect on performance. It’s imperceivable to visitors, and it doesn’t affect any of the metrics that Google uses to gauge performance i.e. you can achieve a perfect 100 score in PageSpeed Insights without any change to the speed of this request.

Sorry, what? Almost 1 second of the page load time only for the analytics tool is normal? I have others (statify, burst, eTracker, …) in use they need max 200ms.

And in the mentioned thread/topic you are saying 200-400 ms should be the max.

The request takes place behind the scenes after the entire site is loaded, so it doesn’t affect the user experience. Similarly, it doesn’t affect any of Google’s CWV performance metrics. This is why we don’t view it as a major concern -> no effect on UX or SEO. I would recommend reviewing your site with the PageSpeed Insights tool, as there are plugins like the Supreme Modules that are impacting the performance.

Burst also uses the REST API, but it looks like they’ve found a way to ignore the response from the server and fake a 200 success code, so it appears much faster. I’ll see if we can figure out how to do this too, and then you’ll see the request from IA minimized to ~100ms. We don’t need the server response anyway, it’s just something we couldn’t figure out how to remove without appearing as an error message in the browser console.

I see it different. This affect SEO for sure because the page load time is bigger than without your plugin. But it is ok, we don’t have to agree on this.

When this is your internal view on this, I know and can decide if the plugin is the right for me or not. Just sad because you have a great plugin there in my eyes.

Just to compare: etracker needs 56ms and burst 70ms.

Hey, i use this plugin on many sites and on some sites it takes 150ms, sometimes 800ms, today i had 20.000ms.

Maybe some other things in the whole stack could impact this too.
Reinstalling sometimes helps me with this.

Else i use Koko, which is very lightweight too, but not as good as IA.

Hi Daniel,

Since Independent Analytics makes a REST API call, it requires WordPress to load. The process that IA runs is very fast, but it’s the loading of WP that slows things down. This is why the performance can change between sites. Sites that have a lot more plugins tend to load slower. You will see similar performance for all REST API and Ajax calls on each site.

For now, the only way to speed things up is to get WP loading faster, as that’s the main bottleneck. The best way to do this is to deactivate any plugins that aren’t crucial for the site. Changing to faster hosting can help too, but I understand that’s a major action to take for this one reason.

We’ve found that plugins with faster requests, like Burst, use a method (SHORT_INIT) to partially load WordPress, which is why their request is faster. We’d like to try something similar in a future update, and that would reduce the time each REST API request takes. We have some other more experimental ideas that we need to explore further as well.

I’d also like to reassert that since the request is non-render blocking and delayed until the rest of the site is loaded, it doesn’t impact how visitors see the site load, and it also doesn’t affect Google PageSpeed scores (CWV), which are the metrics Google openly states affect SEO.