• All DML operations (INSERT, UPDATE, and DELETE) can cause index fragmentation.
• So far have you observed anything that can point in a direction where could be the problem?
• Have you checked application and web server to make sure problem does not lie there itself? How you came to conclusion that problem is with SQL Server?
• Do we have any baseline on the application performance or query performance like, how much time it used to take before and how much time it taking now?
• Have you performed any troubleshooting thus far and what are your findings, if any, so far?

How do you troubleshoot slowness with a specific Stored Procedure or a Query? 

• First, get more details like, how much time on an average this query was taking previously (baseline)?
• Were there any changes to the stored procedure or query recently?
•  How often this query does runs?
• Does the problem only happen on this server or other servers too, meaning can this be reproduced on Test or Dev servers?
• Check if this query is being blocked by other sessions.
• Check if this query is waiting some any resource using wait stats DMV’s.
• Check if statistics are up to date for the tables and indexes used in the stored procedure or the query.
• Check fragmentation of the objects in the stored procedure or the query.
• Collect execution plan of the Stored Procedure and the statements inside the SP or the query. Also collect Read/Write and Time execution statistics of the query.
• Check for any missing indexes based on the execution plan, based on table or clustered index scans.
• Try and suggest to developers if the query needs to be rewritten in a better way like replacing temp variables with tempdb tables or usage of functions in where clause.