DEV Community

Matt Ryan
Matt Ryan

Posted on

10 Bad Habits That Can Slow Down Your JavaScript Applications 🐌

If your app feels more like a lumbering tortoise than a sprightly hare, it might be time to look for some pesky bad habits in your code. Let’s dive into 10 of these culprits that can make your JavaScript applications drag their feet.

1. Not Minifying or Compressing Your Code 📜

Example: You've got a main.js file that's as long as a Tolstoy novel.
Fix: Use tools like UglifyJS or Terser to minify your code. They'll squeeze out all the unnecessary bits and give you a sleeker, faster-loading file.

2. Overusing Global Variables 🌍

Example: var everythingIsGlobal = "Why?!";
Fix: Not only can global variables lead to conflicts and potential bugs, but they can also increase memory consumption. Stick to local variables and closures.

3. Not Taking Advantage of Caching 🔄

Example: Every time a user visits, you're fetching the same old data from your server.
Fix: Use service workers, local storage, or even simple variable caching to store data that doesn’t change often.

4. Using the Wrong Data Structures đŸ’Œ

Example: You’re using an array to manage a list of unique items instead of a Set.
Fix: Know your data structures! Using the right one for the job (like a Set for unique values) can speed things up immensely.

5. Bloated DOM Manipulation 🌳

Example: You're adding 1000 rows to a table one by one.
Fix: Batch your DOM changes, or better yet, use a virtual DOM solution like React to minimize direct DOM manipulation.

6. Not Debouncing or Throttling Events ⏱

Example: Your 'mousemove' event is firing a bazillion times a second.
Fix: Use debounce or throttle techniques to limit the number of times these functions execute, especially for events that can fire frequently.

7. Loading Everything on Page Load 🎒

Example: Your user lands on the homepage, and you’re loading every JS library known to humanity.
Fix: Use code splitting and lazy loading. Load only what's needed when it's needed.

8. Ignoring Console Logs in Production 🖹

Example: console.log("I forgot about this log!");
Fix: Clean up your debug statements before deploying. They can clog up the console and slow down your app. Use tools or build processes to strip them out in production.

9. Making Synchronous Calls 📞

Example: Your UI is frozen while waiting for a synchronous XMLHttpRequest.
Fix: Embrace the asynchronous nature of JavaScript. Use promises, async/await, or callbacks to ensure your UI remains snappy.

10. Not Profiling or Monitoring Your App 🔍

Example: You assume your code is efficient without any metrics to back it up.
Fix: Use tools like Chrome DevTools' Performance tab or Lighthouse to profile your application and find bottlenecks.

Wrapping It Up 🎁

JavaScript is powerful and flexible, but with great power comes... you know, the potential for sluggishness. By being aware of these bad habits and actively working to avoid them, you can keep your apps running like well-oiled machines. So go forth and code swiftly! 🚀

Top comments (7)

Collapse
 
juandadev profile image
Juanda MartĂ­nez

these are good advices to improve app performance!

I want to add another technique that blew my mind when I discovered it, it's event delegation: When you are displaying a large list of items, and each item has an event handler like an onClick event, you may want to apply event delegations, that means to add just one event handler on the PARENT component, container or wrapper of that list, with this, whatever item you click inside that container, you can access to its information with event.target.

What I like to do when implementing this approach is to set data-something attributes in the item, so I can access it via the parent event handler through event.target.dataset.something

Collapse
 
dshaw0004 profile image
Dipankar Shaw

Nice and informative post

Collapse
 
efpage profile image
Eckehard

It seems I need to add another one:

11. Avoid data Ping Pong

What does this mean? Each http-request takes some time to be answered, called the (Round Trip Time (RTT))[developer.mozilla.org/en-US/docs/G...]. The RTT is often more important than the file size, as it is a fixed time of some Milliseconds. Typically you will get between 20 and 50 ms as an RTT, but this may depend greatly on the data connection.

If an HTML page is scanned by the browser, all external data sources are identified and loaded, while the page is still scanned. As http-requests can be processed in parallel, you will get all data after the first Round trip.

But what happens, if you need to fetch some external addresses from a database?

  • 1RTT: Call your page
  • 2RTT: Wait until all ressources are fetched
  • 3RTT: fetch the external adress, Wait for the database to respond
  • 4RTT: Get the data from an external source

This adds up with the time to process the data, so you will end up with a reasonable delay.

Collapse
 
melphindev profile image
MelphinDev

Hmm...Looks like I have at least 2 bad habits (3. , 7.).
Nice article, by the way.

Collapse
 
jodoesgit profile image
Jo

Melphin, I'm not sure where you're on your dev journey. I would say if you're still learning, having bad habits isn't the end of the world. That as time goes on, you learn to refactor your code better and better. As well as keep redundant code/habits/practices away in general.

I'm still learning, and I don't fault myself for anything I do wrong. As long as I'm doing anything, I'm happy as a clam. Figured I would stop by this though, to see if there was anything I could immediately change. Just ended up bookmarking this for later.

Collapse
 
rejwanul313 profile image
Md Rejwanul Hoque

I remember your advice. Thank you for informative post.

Collapse
 
thecheapaudiophile profile image
Griff Polk

[In Leela Voice] Fry!?!?

Image description