Following is a list of questions which can be useful aid for investigating SharePoint latency/slowness issues…
When did the issue start?
How many users are experiencing the issue?
• Are all users affected, or just some?
• What is user login account of an affected user?
Is the issue specific to only one computer?
• What is public IP address of the affected computer?
• Is the user is behind a firewall or proxy?
For a user experiencing slowness, does same user experience same slow performance when using a different PC or device to access SharePoint?
Is the issue specific to one geographical location?
What kinds of users are experiencing the issue?
• Are AD managed user accounts affected?
• Are federated user accounts affected? If so:
o Are you using Active Directory Federation Services (AD FS)? If so, how is your AD FS setup? DirSync?
o Are you using any third-party solutions like Ping federated?
Does the specific network affect the performance? For example,
• Is the issue occurring from the office network?
• Is it occurring on cellphones or mobile devices that aren't connected to Wi-Fi?
• Is it occurring from home?
• Is it occurring from a free Wi-Fi hot spot?
What is URL of site where slowness observed?
What is URL to one particular page exhibiting slowness? Can you screen capture page?
What authentication types and providers are configured for the SharePoint web application?
Can you clarify the particular type of SharePoint Online slowness observed? For example:
• Site pages are slow to display?
• Slow response from dialog windows?
• File uploads or downloads are generally slow?
Is the performance problem intermittent, or constant? If it's intermittent,
• Have you identified any pattern with the behavior?
• Does the time of day make a difference?
• Are all pages in a site exhibiting slowness?
• Is only a specific page exhibiting slowness? If so:
o What's located on the affected Page?
o When you browse to the slow page, add ?Contents=1 to the end of the URL. The Web Part maintenance page will appear. Can you screen capture?
• Are all sites in the site collection exhibiting slowness?
• Are multiple site collections exhibiting slowness?
• Does the issue occur only on a new or on an existing site collection, or both?
• If you add a new page to the site, is that new page also slow?
Is the site customized? If so:
• Has the customization ever worked, or is this a new feature?
• Could the customization be involved in degrading performance?
• What is the goal or purpose of the customization?
• How are you customizing site?
Are publishing features enabled for the site?
Has anything changed since the time that the page worked correctly and now?
• Have you migrated any content to the site collection? If yes, are you still migrating content?
• Have you on-boarded lots of new users?
• Have you created lots of content recently?
If the slow page displays a view of a list/library, how many items are in current view?
TOOLS YOU CAN USE TO COLLECT DIAGNOSTIC DATA
Fiddler trace (http://www.fiddler2.com/fiddler2/): Fiddler is a free web debugging tool which logs all HTTP(S) traffic between your computer and the Internet. Recommend you capture a Fiddler trace while doing following:
• Browse to your site where experiencing slowness and perform actions that are taking longer than expected.
• Browse to multiple libraries or lists on the site. View at least 2 to 3 libraries and or lists.
• Have you seen issues with Searching performance? If so, run a search query.
• Upload a document. To limit the time that is required to test, use a file that is approximately 1 megabyte (MB), but no larger than 10 MB.
• Download one or more files.
• In the Fiddler trace you should see http status codes of 200 or 401. You shouldn’t see a 304 error. A 304 error indicates you are using the local copy. If you see 304 errors, that means the Fiddler trace has to be rerun after clearing local browser cache. There is a clear cache button in Fiddler that can also be used. The goal for a good Fiddler trace collection is to capture all the CSS files, JS files, and so on, to help diagnose the issue.
• When collecting a Fiddler trace, it's ideal to obtain a Fiddler trace where the issue reproduces. However, this isn't required. If the issue is intermittent, collecting a Fiddler trace correctly can be very important for understanding your general code flow and page request and can help facilitate troubleshooting
PathPing to the site (http://technet.microsoft.com/en-us/library/ff963096.aspx)
• Can help diagnose network connectivity and congestion issues. PathPing is a command-line route tracing tool that combines features of the tools Ping and TraceRt with additional information. PathPing sends packets to each router on the way to a final destination over a period of time, and then computes results based on the packets returned from each hop. PathPing shows the degree of packet loss at any given router or link, allowing you to pinpoint which routers or links might be causing network problems.