This can also be a simple issue of out of date statistics.

SQL servers build in auto update statistics (if its on in your database) does not always do the job when you want or need it for better query plans.

Is there a nightly job updating them?

Finally isolate the few queries that (likely) cause slowdown.

You might find that due to growing data volumes some specific indexes or SQL statement alterations are in order.

Always keep in mind that a database that works with small volumes can have drastically different behavior whith multiple times the data volumes.

A larger volume brings brings existing inefficiencies to light and makes them suddenly measurable/noticable.

And then one more thing. Is the load of the system increased and do you use ad-hoc queries?

You should make sure that you use parameterized queries whenever possible and in some situations even make sure the optimizer knows to make a generic plan, instead of focusing all its smartness around the first parameter values it encounters and then stick to that (i am referring to option( optimize for unknown ) that is available since 2008).

Then there is yet one more possibility. many developers use the SQL Server management studio to alter databases, sometimes just to place a new column in an estatically pleasing position withing the table.

DON'T EVER!!

I tell you why...management studio contains bugs that when a table needs to be rebuild lets filters on indexes suddenly disappear!

Oh...and don't forget disk, file and log (number of virtual log files) fragmentation.

The defaults (on earlier versions at least) set auto growth in percentages and is very nonsensical, causing fragmentation.

As you can see, the list of things that can make a database go south with respect to performance are numerous, in this regard its not even clear i am helping here other then to relay just this fact.