A VM snapshot preserves the state and data of the VM at a specific point in time (the snapshot creation time).

The data includes all the files that make up the VM. This includes disks, memory (if the VM is powered on and you enable also memory snapshot), and other devices, such as virtual network interface cards.

A VM provides several operations for creating and managing snapshots and snapshot chains. These operations let you create snapshots, revert to any snapshot in the chain, and remove snapshots. You can create extensive snapshot trees.

Snapshot Formats

When you take a snapshot of a VM, the state of the virtual disk is preserved, the guest stops
writing to it, and a delta or child disk is created. The snapshot format chosen for the delta disk
depends on many factors, including the underlying datastore and VMDK characteristics, and has a
profound impact on performance.

• SEsparse: is the default format for all delta disks on VMFS6 datastores. SEsparse is a format similar to VMFSsparse (also referred to as the redo-log format) with some enhancements.
• vSANSparse: introduced in vSAN 6.0, is a new snapshot format that uses in-memory metadata cache and a more efficient sparse filesystem layout; it can operate at much closer base disk performance levels compared to VMFSsparse or SEsparse.
• vVols/native snapshots: In a VMware virtual volumes (vVols) environment, data services such as snapshot and clone operations are offloaded to the storage array. With vVols, storage vendors use native snapshot facilities, hence vSphere snapshots can operate at a near base disk performance level.

Basically for non vSAN or vVols snapshots, the used files are very similar to thin provisioned disks with some performance impact.

Snapshot best practices

VMware has collect some tips in the VMware KB 1025279: Best practices for using snapshots in the vSphere environment (http://kb.vmware.com/kb/1025279):

Follow these best practices when using VMware snapshots in the vSphere environment:

• Do not use VMware snapshots as backups.
  The snapshot file is only a change log of the original virtual disk, it creates a place holder disk, virtual_machine-00000x-delta.vmdk, to store data changes since the time the snapshot was created. If the base disks are deleted, the snapshot files are not sufficient to restore a virtual machine.
• Maximum of 32 snapshots are supported in a chain. However, for a better performance use only 2 to 3 snapshots.
• Do not use a single snapshot for more than 72 hours.
  The snapshot file continues to grow in size when it is retained for a longer period. This can cause the snapshot storage location to run out of space and impact the system performance.
• When using a third-party backup software, ensure that snapshots are deleted after a successful backup.
  Note: Snapshots taken by third party software (through API) may not appear in the Snapshot Manager. Routinely check for snapshots through the command-line.
• You cannot increase the size of the Virtual Machine disk while the VM is running on snapshot during powered ON/OFF status. Increment of VMDK disks running on snapshot should never be attempted even using CLI. 
• Increasing the virtual machine disk size or virtual RDM.
  Increasing the disk size when snapshots are still available can corrupt snapshots and result in data loss.

There is also a specific official document: VMware vSphere Snapshots: Performance and Best Practices

This document demostrate the performance impact of snapshots (minimal in vVols and moderated in vSAN):

But also you have to consider the STUN problem of snapshots (https://kb.vmware.com/kb/2039754): ESXi pause the execution of the VM at an instruction boundary and allow in-flight disk I/Os to complete.

The STUN operation itself is not normally expensive (typically a few 100 milliseconds, but it could be longer if there is any sort of delay elsewhere in the I/O stack).