The number of names is a very small amount of data overall; if it pushes delivering the certificate over a packet size threshold, the added delay won't perceptibly impact human users that have broadband or other high speed connections. The receiving computer will have up to 14 extra strings to scan; again, an imperceptible amount of overhead to any particular human user.
Qualys SSL Labs did a certificate survey a few years ago, and presented their findings at Blackhat. They found many issues that contributed to performance problems. In the case of multiple domain names, they found one certificate with 354 unrelated domain names, and the certificate was 8.2KB long! So yes, there is a line you probably don't want to cross, and 354 appears to cross it.
Another common problem they found impacting performance was that some validation chains were too long. A long time ago, some PKI architects were advocating a multi-tiered approach, where every certificate would be signed by a root CA, one or two Subordinate CAs, and one or two Policy CAs. Running through the RSA math on four different validation steps is what bogged down the clients, much more than the size of the certificates. (Qualys found 8 certificates that had a signing depth of 6!) To keep performance as high as possible, keep the signing chain as short as possible.
They also saw 43% of servers were sending too many certificates. Normally, you would include the server's cert and any intermediate signing certificates needed to validate it up to the root (the root cert is normally contained within the browser, unless it's a self-signed cert.) Many sites were wasting bandwidth by including additional certificates not needed to validate their site. One site sent a certificate file back that contained 116 certificates!
Finally, they found lots of certificates that were just plain bad. They were self-signed, expired, used weak algorithms, or had other flaws that meant their protection was less than optimal. Of all the things you need to achieve with a certificate, security is number one - performance is not. So I'd recommend using their analysis tool and finding out what they think of your setup. https://www.ssllabs.com/ssltest/index.html . I run this check every time I change my server's configuration and after updating my certificate.
UPDATE: I've switched to using an nmap script to check my server. Make sure you're running an up-to-date version of nmap, then run
nmap --unprivileged -sV --script ssl-enum-ciphers -p 433 example.org. This will list the ciphers supported by the server, and provide a letter grade indicating the security of each, and an overall grade for your server. Good for finding things like out of date and insecure versions of SSL/TLS, 64 bit ciphers, etc. And you can run it on any host and port, so you can test app servers, web services, internal servers that are behind your firewalls, etc.