First off, gather a performance baseline in order to know what the situation is now. Keep monitoring the performance to see if there is a trend for degeneration. If the performance seems to become an issue, there are a few things to do.
Identify the root cause for lack of performance. Is the server expiring memory pressure, IO waits or high CPU usage? The word on the street is to look at Brent's performance tuning pages for a quick start.
Don't overlook good DB design. Check the DB against missing indexes, outdated statistics and poorly written queries. Any of these issues can eat up all the iron you got and then some.
Edit:
Using multiple file groups can - in certain situations - increase performance. Even Microsoft's documentation claims performance advantages. Alas, in your scenario they do not, as you do not have extra disks.
The idea of file groups is to divide database contents to multiple files. File groups make it possible to locate hot tables to high performance storage. This, requires advanced storage configuration your system is lacking. Partitioning tables can take advantage of storage this way too.
Administration tasks like backup/restore can be more manageable with filegroups. Usually a VLDB (very large database) is needed to get such an advantage. Another a classic example is handling read-only data and separating it to its own filegroup. As the data doesn't change, it can be backed up more seldom than the rest of the database.
If you deploy multiple file groups to single a disk, there is no performance bonus. The reason is that you still got a single disk, a single spindle, single set of read/write heads. In order to access data, the disk has to move heads to proper a location. They can't be at two locations at the same time, so extra file group doesn't increase performance.