NGINX Websocket initial communication delay

Question

I've created a Django server that is making use of django-channels for websocket communication. When I run the server with NGINX there is an initial delay in websocket communication between the server and the client. After the initial delay all the data that was missing arrives in a very short amount of time and then it begins to communicate in real-time.

I've tested the server stand-alone and with just a Daphne instance without NGINX proxying and there is no initial delay of communication.

Below is my NGINX configuration. If anyone has any idea as to why I would be getting an initial 10+ second delay on websocket communication it would be greatly appreciated.

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    map $http_upgrade $connection_upgrade {
      default upgrade;
      '' close;
    }
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  0;

    #gzip  on;
    # the upstream component nginx needs to connect to
  upstream django {
      server 127.0.0.1:8001;
  }
  server {
    listen 80;
    client_max_body_size 20M;
    server_name localhost;

    location / {
            proxy_pass http://django;

            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;

            proxy_redirect     off;
            proxy_buffering    off;
            proxy_set_header   Host $host;
            proxy_set_header   X-Real-IP $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Host $server_name;

        }

    }

}

Additional information: it takes the same number of messages everytime before the messages get sent regardless of how fast the messages are put into the queue meaning that the message delay isn't time based but seems to be buffer overflow based? As in it won't send any data until a buffer of some sort is filled?