The showcontig result indicates some degree of index fragmentation which could be corrected by DBCC DBREINDEX, or DBCC INDEXDEFRAG. However, I doubt it will make huge difference because the fragmentation level isn't that great. There are a lot of reasons why a stored proc runs slow. First of all, take a look at the query execution plan and see if you have table/index scans.
The short answer is you don't. The numbers above look pretty good for read performance. Maybe not so good for update performance, but you can not have everything.
First thing you must do is determine where the bottleneck is. Is the CPU being railed by long running reports which are sucking the life out of the server? Do you have a lot of lost packets on the network? Or (as is most commonly the case in performance questions) is the application just not up to the job?
First place to start would probably be Performance Monitor, to check to see if the system is CPU bound or not. After that, you can run a profiler trace to see if you have a lot of one particular query running up a lot of reads, or a lot of CPU, or both. Note, however, that reads in Profiler are both logical and physical reads. It makes no distinction between reading from memory and reading from disk.