Memory Consumption When Web Dependencies Not Available


Grammarly is a pretty good tool to possess for work, blogging, or writing general emails. I have found it to be that extra set of eyes to catch the obvious things in addition to those subtle nuances in writing that are easily missed. We started using Grammarly a few years ago, stopped due to pricing, and then started back up again about one month ago. They have two service tiers, broken down to Free and Premium offerings. The premium subscription is close to $12/Month when paid annually, so by no means is this a cheap service when comparing to the value one may extract from something like Netflix for a similar dollar amount.


One of the many functionalities offered is an extension for popular browsers, wherein it takes the texts from text fields on web pages and applies the same linguistic rigor as it would to your email, if you desire it to do so. To fully leverage this piece of functionality, you are directed to log in to, and the extension will recognize you are a Premium user.

The Problem

So now that we are trying to login to, it should be fairly simple, right? Well, if one of the dependencies on the website is not found, it begins to throw an enormous amount of exceptions, ultimately causing Chrome/Firefox/Brave to slow down to a crawl and consume insane amounts of memory. At one point, I let it keep going, and Chrome got to nearly 10GB of RAM consumed as a result of this issue.

After doing some digging, I noticed that a single exception seemed to repeat itself. The URL is inaccessible due to ERR_NAME_NOT_RESOLVED. This isn’t an uncommon occurrence and happens on nearly every website I visit. This is a consequence of employing selective DNS resolution using something like Pi-Hole. While I am not an expert on Front End web development, it’s just a wild guess that an unavailable dependency shouldn’t cause the entire browser session to slow to a crawl and potentially crash a system.

Google Chrome Incognito Screenshot – Over 100,000+ exceptions in <60 seconds – Impressive!

The Solution

The solution is fairly simple – Whitelist the given domain name in Pi-Hole. After doing this, I was able to perform the necessary actions on their website. If, in your case, you can’t/don’t have this level of knowledge or control, try another browser. I noticed that Microsoft Edge (non-Chromium) seemed to be fine when navigating their site.

Various entries appear showing the domain is being blocked by the DNS resolver

Support Engaged

While the solution is easy for me, being that I have control over name resolution, it may not be so easy for others. Additionally, what if that endpoint just so happens to be down for an extent of time? Everyone that attempted to visit the site in Chrome/Firefox-based browser would be immediately turned off. So I decided to let support know about the problem in hopes that they would be able to A.) understand it and B.) eventually resolve it. I imagine it’s a smaller team at Grammarly, and defects like this shouldn’t take too long to remediate. I opened a ticket, provided some details in addition to a screen recording of the tens of thousands of exceptions being thrown. The response was not that great, so I attempted to articulate the problem in another way. That also yielded nothing, hence this blog post. This isn’t like I am asking them to fix elements that aren’t displayed correctly because I am using 6 layers of advertisement blocking. No, this is causing the system to nearly crash, an effective denial of service.

Support Correspondence

Below is my first note to support upon opening the ticket:

My first response to support when opening the ticket!

And their response:

Grammarly Supports first response

And my inevitable followup:

My followup and second response.

And their final response in addition to closing the ticket!

Sure it is! | When it doubt, close it out!
Grammarly Supports second and final response


This is petty and likely didn’t warrant all of this. That said, I attempted to Google the problem twice over two weeks to no avail. There was also some chatter on Reddit about Grammarly crashing someone’s browser and some tin-foil hacking responses, so I figured this post might quell some of those fears and hopefully appear in one Google search; I can’t be the only one on planet earth experiencing this. Best case scenario, someone from Grammarly who can own the problem and bring to resolution sees this post! All of this said, Grammarly is an awesome product that has tons of potential ahead of it. The ability to positively impact someone’s writing is near limitless, while having writing samples from a large population of users enables some next-level data insights, further elevating the writing skill of people.


2 thoughts on “ Memory Consumption When Web Dependencies Not Available

  1. Well, they’ve earned an uninstall from my side.

    Just today I’ve realized Brave was consuming 40% CPU and 10.5 GB RAM (Brave, not Chrome, lol) and pinpointed the problem to the extension.

    Then I search for some solution and find this page… of January 2020.

    So yeah, good bye forever I say.

    Thank you for exposing the issue, man.


  2. Grammarly chrome extension was consuming 90% CPU on my Macbook Pro and rather than jump through those hoops I’ve uninstalled the extension.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: