1. ROWCOUNT:

Slow running queries have an impact on the instance performance by occupying a thread until the query has completed.

The 'rowcount' property impacts many areas of the platform:  all list, homepages, related lists, reports, etc

Therefore modifying the 'rowcount' value can have a direct impact on the instance.
The ServiceNow default 'rowcount' value is 20.  ServiceNow's recommendation is 20, or 50 if needed.

For more information, see
https://community.servicenow.com/community/blogs/blog/2014/12/03/displaying-just-enough-data-helps-performance

To see all users in an instance that have modified this property you can visit the following URL (replacing __INSTANCE__ with your own instance name):
https://__INSTANCE__.service-now.com//sys_user_preference_list.do?sysparm_query=name%3Drowcount%5Evalue!%3D20%5EORvalue%3DNULL%5Evalue!%3D15%5EORvalue%3DNULL%5Evalue!%3D10%5EORvalue%3DNULL

Depending on your use case, you could test in a sub production and remove 100+ from the list, understanding that list performance will be slower using 50+

These are the steps to remove the choice of "100 rows per page":
i. Log in to your instance (as an Administrator)
ii. On the left side navigation panel, search and open  "All Properties"
iii. On the properties page, search and open name='glide.ui.per_page'
directly via - https://__INSTANCE__.service-now.com/nav_to.do?uri=sys_properties.do?sys_id=fc794773c0a80169017b5179c629af26
iv. You will see 10,15,20,50,100.. in the Value field.
v.Modify the value to 10,15,20,50 and click update.

While this will restrict the list moving forward, existing users with 100+ will need to be modified.

You can visit https://__INSTANCE__.service-now.com/sys_user_preference_list.do?sysparm_query=GOTOnameLIKErowcount&sysparm_first_row=1&sysparm_view= and then modify the filter to include 100+ and then right click and multiple update the Value for all records. eg users with 100+ set to 50.

2. HOMEPAGES vs DASHBOARDS

In regards to Homepages, The ServiceNow platform will run a query for every widget and once all querying have returned data THEN it will process the page and render it back to the client browser.

Should you have 10 widgets on a homepage, and only see 2-3 before scrolling down the page it would still query all 10 widgets and then present it back to the client.

By creating dashboard versions of a homepage, the platform will only run queries for the widgets displayed on the client browser.  For example, in the 10 widget example you would initially see 2 widgets on the dashboard before scrolling down but the platform will only query for the widgets that are visible (the first time they are viewed) ... keep scrolling and you'll trigger the next queries and so on.  

Dashboards also allow you to introduce 'tabs' to the dashboard. This is significant because widgets within sub tabs do not run queries until you view that active tab. Only the queries from the active tab widgets run.

A dashboard does not make slow widgets faster, but it does change the user experience. Instead of waiting on a slower homepage to load you are only presented with the data that you can see.  

Therefore if you only review a widget once a week / month etc - users can consider moving that to it's own Dashboard sub tab - thus speeding up their initial dashboard view.  See: [Doc] Create a dashboard version of a homepage

3. DEFERRED RELATED LIST LOADING

In addition to the rowcount setting, there is also another variable that can be set: ‘glide.ui.defer_related_lists'.
You can easily test this recommendation by setting it to 'deferred’ for troubleshooting purposes, and for longer term health this can be se to “ondemand” so that related lists only load if the users clicks on the "load related lists" button.

This loads the related lists after the form has loaded. This greatly increases the response time of forms.
This is a true / false setting.  By setting related lists to load after a form loads, the user will see the form and by the time they scroll down to the related lists they are likely to be loading in the background.

You can set properties at the global level, which are then overridden by the user preference (if a user has explicitly chosen a different setting).

i. Go to the system properties, and see if it's set;
https://__INSTANCE__.service-now.com//sys_properties_list.do?sysparm_query=name%3Dglide.ui.defer_related_lists
- we can see ‘glide.ui.related_list_timing’ is not set.

To set the variable;
ii. click the NEW button, and give it a name of 'glide.ui.related_list_timing', of Type=string,
For the value, you have three options;
Value=default (loads inline with the form),
Value=deferred (loads AFTER Form loads), << select this
Value=ondemand (loads when the user clicks the button),
(leave all other values set (Application=global), then SAVE.
Now that if it is set, all users will pickup this setting moving forward (logout / login again)
This will not affect users that have made a choice and have a value set.

You can review those users (and update those users to also use ‘deferred') by visiting this link and bulk updating those records to ‘deferred / ondemand';
https://__INSTANCE__.service-now.com//sys_user_preference_list.do?sysparm_query=name%3Dglide.ui.related_list_timing

i. Common Admin Tasks
See https://community.servicenow.com/docs/DOC-7348
This document begins the conversation on reviewing performance data within the instance, looking over slow transactions / jobs / scripts and trending top transactions. It also discusses reviewing table data growth within an instance and how to review the Performance Metrics dashboard. For more information see https://docs.servicenow.com/bundle/madrid-platform-administration/page/administer/platform-performance/concept/c_PerformanceMetrics.html

ii. Performance Best Practice for Efficient Queries - Top 10 Practices
https://community.servicenow.com/community?id=community_article&sys_id=0c3c6661dbd0dbc01dcaf3231f961947

iii. KB0750239 Monitoring Performance Metrics in your ServiceNow Instance