“I don’t like to waste bytes” isn’t exactly a great reason to write off a widely accepted and deployed spec for transmitting data in a trustworthy manner and instead write your own implementation, which most likely hasn’t considered all the attack vectors the JWT (and broader JOSE) spec has considered and accounted for.

I get the motivation — and I hesitate a little bit to say this — but it’s 2019, and a few “wasted” bytes on your auth token are less than inconsequential in a world where your front-end codebase mostly like “wastes” thousands (if not millions) of bytes.

When it comes to securely transmitting data, it most often pays to lean on the work and research of others.

I prefer to keep it simple. JWT does not look like a simple thing.

HTTP/2 HPACK compresses headers in such a way that the difference will be largely irrelevant.

Most connections nowadays are such that latency is overwhelmingly more important than that many bytes.

Also, IP address? You invalidate me every time I switch networks?

Absolutely, if hacker steals token, he'll likely using another IP address, so token is bound to IP address, it's a very important security measure. It's easy to issue new token anyway and address does not change often.

Signed how?

Using HMAC.