When I read about websockets, heartbeats are usually mentioned as a must have. MDN even writes about a special opcode for heartbeats.
But are heartbeats a mandatory part
Pings and Pongs are not mandatory. They are useful, since they allow the detection of dropped connections. (Without some traffic on the wire, there is no way to detect a dropped connection.)
Note that in the browser, WebSocket heartbeats are not accessible. If you require your browser client code to detect dropped connections, then you have to implement hearbeating on the application level.
It is mandatory or not depending on client and server implementations. If you are connected to a server that requires you to answer the PING with a PONG, you will be probably disconnected in case you don't reply. Same if you are the server and a client is sending you PING.
Server and client implementations vary (there are a myriad of them), but the browser´s javascript client do not send PING, and do not provide any API to do so, although It replies to PINGs with PONGs.
The RFC 6455, the current reference for the WebSocket protocol, defines some control frames to communicate state about the WebSocket:
0x8
0x9
0xA
Ping and Pong are used for heartbeat and allows you to check if the client is still responsive. See the quote below:
A Ping frame may serve either as a keepalive or as a means to verify that the remote endpoint is still responsive.
But when the client gets a Ping, a Pong must be sent back to the server. See the quote:
Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in response, unless it already received a Close frame. It SHOULD respond with Pong frame as soon as is practical.
When designing both client and server, supporting heartbeats is up to you. But if you need to check if the connection is still alive, Ping and Pong frames are the standard way to do it.
Just keep in mind that if a Ping is sent and a Pong is not sent back, one peer may assume that the other peer is not alive anymore.