Anything that you do here will impact performance somewhere. But if it's a requirement then it's a requirement. The methods you've laid out in your question are the accepted, low impact methods of getting that.
You can mitigate the large log files by rolling over to a new file more frequently. By default it does that on every server restart, but you can add an agent job to run sp_cycle_errorlog every day, week or whatever. Then change the number of files to retain (limited to a max of 99).
--May need to adjust if running an instance.
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, 90
But that just tells you that the user in question logged on. If you need to do more with that information such as track what they did, then you will need to turn on Auditing (recommended if it's a legal requirement such as HIPAA/SOX; although only available in Enterprise) or you can just use Extended Events. Extended Events are as lightweight as you can get with tracking statements against the database.
There is one other option and that's a logon trigger, but I would strongly advise NOT to follow that route. If the logon trigger messes up for whatever reason then you could prevent anyone from logging into the database. But it only gives you slightly more information than you would get from turning on successful and failed login monitoring.