Using Marathon and Chrome Browsers With Disabled Plugins for the Wordpress Editor

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Something strange happened when using the WordPress Editor with Brave and testing different browsers.

Introduction

After having no problems for around a year using the Brave Browser, and having migrated from Chrome due to memory management problems, which we covered in the article The Enormous Difference in Memory Consumption Between Google Chrome, Microsoft Edge, and Chromium, we noticed a high degree of latency when using the WordPress editor with the Brave Browser. This caused us to begin testing different things and finally testing different browsers with the WordPress editor.

Where Was the Problem Coming From?

Our first step was to test different browsers on the WordPress editor. We tested Epic, Safari, and UR Browser, and, Interestingly, we found that we had the same performance problem in all of these browsers. This included slow, jagged scrolling and latency when typing or moving around the editor.

We checked the memory consumption, thinking it might be that, but the memory was only around 4/5ths consumed. We ran the memory recapture in MacCleaner but to no avail. Furthermore, this performance problem only occurred with the WordPress editor and not when browsing the web or using Google Sheets. This led us to restart the WordPress server and then reduce the number of elements shown in the WordPress editor.

However, none of these things that we tried worked. This was a problem because it was extremely cumbersome to use these other browsers with the WordPress editor, and we felt that our efficiency was being sucked away.

Trying Marathon

We had tried the Marathon browser in the past, and it had not made much of an impression on us. It has very limited customizability and does not allow either Chrome or Firefox plug-ins, and we rely on several plug-ins like Grammarly and Find and Replace.

However, when we tested the WordPress editor with Marathon, all latency issues disappeared. This meant there was something in all of those other browsers tied up with the WordPress editor. These browsers did not use to get tied up like this, and there has not been a new plug in that we installed at the WordPress server or in our browser, so we could not figure out where the issue is coming from which turned out to be the browser plug ins. And we learned this when we tried using a Chrome based browser but without our normally installed plug ins.

This gets to our testing of Vivadi and disabling Chrome plug ins.

Trying Vivaldi

Another browser we tried, which had good performance was Vivaldi. However, as soon as we installed our plugins, the performance began to suffer.

It turns out that the Chrome plug ins is what was slowing the Vivaldi and all the other browsers. And the issue was adding plug ins, which one could not do to Marathon.

However, when we deactivated all of the plugins, the performance was similar to Marathon, but when when we reactivated the plug ins one by one the performance stayed good again.

The Solution

We can’t edit this WordPress site without using several plug-ins. So there we found the following two options.

Option #1

Use Marathon for most of the writing, but then refresh the saved article into Brave and run the plug-ins there.

This causes some inefficiency because it means using two browsers and have to refresh several times. It is also a bit confusing and jumping back and forth between browsers makes the workflow messy.

Overall, we worked like this for a day when we did not know the cause of the latency but knew that Marathon did not have that latency. In fact, we could not have guessed that a few browser plug ins could have killed performance to that degree in the WordPress editor or in any other online application. However after we figured out that it was the plug ins that were causing the latency we moved to Option #2.

Option #2

Use Vivaldi (or other Chrome based browser) but with deactivated plug ins, until they are needed and then using them, and then deactivating the plug ins again before saving the article or page.

The good thing about this is that we only use plug ins for a very limited period of the overall writing and editing. Therefore it is easy to just disable the plug-ins, use them and then disable them again. As soon as the page refreshes from the WordPress Editor, the performance will be degraded one again. Therefore, one can enable the plug ins, use them, and then disable the plug in and save the article or page. This will keep the performance within the editor quite good.

Our Conclusion on Vivaldi

We weren’t looking for a new browser to use, but upon using Vivaldi, we came away impressed.

Vivaldi has a large number for settings that allows for a high degree of customizability of the browser.
One of these customizations is to place the tabs and the URL and search at the bottom of the page, which turns out to work very well for working in the WordPress editor.
Vivaldi has superior tools like how search and history works than Brave.
Vivaldi’s UI changes colors depending upon state, which turns out to be quite helpful in figuring out where one is in a process.
Furthermore Vivaldi seemed to run light on the memory consumption.
Vivaldi has a number of features that appear to us to be unique. The usability is both high, and the browser is also enjoyable to use.

The downsides of Vivaldi is that it still consumed a bit more memory than Brave, and it did not render sites and specifically text as nicely as Brave. This is probably the bigger issue. Secondly, when one increases the zoom in Vivaldi, the tabs increase to a ridiculous degree. This means Vivaldi can’t be used with a significant zoom, which is what we use. This is unfortunate as outside of that issue, it is really a great browser with a lot of reasons to use it.

Overall, it would seem to make sense to use Vivaldi for the WordPress editor, (and with mostly disabled plug ins). We preferred using Vivaldi with the WordPress editor, but also prefer using Brave for viewing pages or normal browsing and also for Google Sheets.

Furthermore, another reason use two different browsers is we like using different levels of zoom for the WordPress editor versus general browsing and also for using Google Sheets, which can be set at the level of zoom for the WordPress editor.

Therefore, by using two browsers, we can keep that setting different without having to switch the zoom back and forth.

Only Applicable on Mac?

All of this testing was performed on a Mac. However, when we replicated this test using Chrome on a Chromebook, we ran into the same latency problems when the plug-ins were active.

Overall Conclusion

For anyone with latency issues in the WordPress editor when using other browsers, we recommend using a browser with no plug ins, like Marathon for most of the work or even more preferably try using Vivaldi and then deactivating and reactivating the plug ins. One wonders how many people are using the WordPress editor with significant and efficiency sapping lag, without having figured this out.

The reason this is a problem in terms of trouble shooting is there are so many possible reasons for the lag. And secondly, we could not find anything published that addressed this issue. To be more specific, there are articles that discuss disabling browser plug-ins to improve performance, but nothing on the problem between browser plug ins and the WordPress editor specifically.

In retrospect it would have been great if we could have figured out to just disable the plug-ins, but at the time we did not know.

What this all means is that it makes good sense to have one browser that either does not have plug ins or has its plug ins deactivated most of the time for some tasks.