First I would suggest removing all console.log and try using the browser's debugger instead. The debugger allows you to plant breakpoints which allow you to inspect the immediate area of the breakpoint (see variables, climb the scope, view values, run commands at that point etc.)

I also notice you bind click handlers after the AJAX responds. Instead of doing this every time, try to use event delegation. It takes advantage of the fact that events emitted by elements also get intercepted by its ancestors due to "event bubbling". In jQuery, you can use on

$('.ancestor-already-on-page').on('click', '.dyncamic-descendant', function(){
  // This would execute in the context of the descendant, like you normally
  // attach it to the descentant directly
});

DOM operations (retrieving elements, modifying values, changing properties etc.) are slow. You should avoid DOM operations, especially in "hot" code (code that gets executed all the time). If the elements don't change over the lifetime of the page, you can just fetch them once and store them in variables which you can reuse later.

Also, a comparison is already a boolean by itself. Also, there's no need to write down all the possible arguments of a callback. Most IDEs will warn you of such. I read somewhere that it also affects performance, as the engine provides reference to the value, but the code isn't using it, wasting the effort.

var results = data.filter(function(element){
  return element.name === content;
});

I also notice this:

$('#term').keypress(function(event){        
  if(event.which == 13){
    displayContent();
  }
  console.log("SEARCH");
});

Instead of detecting a keypress (which can fire any time you actually press a key), wrap the input in a form, and handle the submit event of the form instead (which also fires when pressing ENTER). That way, jQuery isn't listening, creating event objects, and firing the handler every time you press a key.

First I would suggest removing all console.log and try using the browser's debugger instead. The debugger allows you to plant breakpoints which allow you to pause running code and inspect the immediate area of the breakpoint (see variables, climb the scope, view values, run commands at that point etc.) Another quick way to do breakpoints is to use the debugger; statement. It's similar to adding console.log (thus you shouldn't forget it's there) but it pauses the code when it is reached, allowing you to inspect the code like you would have when using breakpoints.

I also notice you bind click handlers after the AJAX responds. Instead of doing this every time, try to use event delegation. It takes advantage of the fact that events emitted by elements also get intercepted by its ancestors due to "event bubbling". You'll only set the handlers once, and on an ancestor element that already exists on the page. In jQuery, you can use on

$('.ancestor-already-on-page').on('click', '.dyncamic-descendant', function(){
  // This would execute in the context of the descendant, like you normally
  // attach it to the descentant directly
});

DOM operations (retrieving elements, modifying values, changing properties etc.) are slow. You should avoid DOM operations, especially in "hot" code (code that gets executed all the time). This means every call to jQuery with a selector (like $('body') and so on) and calling methods that change the DOM is slow. If the elements don't change over the lifetime of the page, you can just fetch them once and store them in variables which you can reuse later. If DOM operations can't be avoided, then at least batch them up (do them closely to each other) so they render together rather than have them all over the code.

Also, a comparison is already a boolean by itself. Also, there's no need to write down all the possible arguments of a callback. Most IDEs will warn you of such. I read somewhere that it also affects performance, as the engine provides reference to the value, but the code isn't using it, wasting the effort.

var results = data.filter(function(element){
  return element.name === content;
});

I also notice this:

$('#term').keypress(function(event){        
  if(event.which == 13){
    displayContent();
  }
  console.log("SEARCH");
});

Instead of detecting a keypress (which can fire any time you actually press a key), wrap the input in a form, and handle the submit event of the form instead (which also fires when pressing ENTER). That way, jQuery isn't listening, creating event objects, and firing the handler every time you press a key.