This course is intended to instruct users on how to manage Client-side Performance.
What is Client-side Performance?
What is DNN Support's role in troubleshooting Client-side Performance?
With Client-side issues, it is easier to identify as we can identify most Client-side performance issues through the browser itself. It is our job to identify these issues and provide suggestions or solutions to remedy them.
Here are some performance tools that will be useful to be familiar with when dealing with issues regarding client-side performance:
- Fiddler - Web debugging proxy tool to log all HTTP(S) traffic between your computer and the Internet. Inspect traffic and set breakpoints to analyze the requests that are logged in the client session.
- Browser Developer Tools - These are the browser developer tools that can analyze any client-side errors and requests that can be very helpful in analyzing client-side issues.
- Google PageSpeed Insights - This is a tool developed by Google that analyzes a page and provides a report of page speed improvements that an administrator can perform.
How do I determine if a performance issue is a Client-side issue?
When a customer first submits a performance issue ticket, you will need to make sure you've gathered all the information necessary to narrow down the issue:
The key information required:
- Log4net files from the time when the issue occurred.
- IIS logs from the time when the issue occurred.
- A Fiddler trace of the page when the issue occurs.
- Site_Evaluation.sql script results.
After evaluating the above information, you can then determine the next troubleshooting step by reviewing the DNN Performance Issue Map KB.
DNN Composite files and Client Resource Management API
You can see from the above image that the left side is before the JS and CSS were minified and the right side is after Composite files were enabled.
So how does CRM API know which files to minify?
- You will need to first register the theme's ascx file to the CRM using:
<%@ Register TagPrefix="dnn" Namespace="DotNetNuke.Web.Client.ClientResourceManagement" Assembly="DotNetNuke.Web.Client" %>
<dnn:DnnJsInclude runat="server" FilePath="jquery.cycle.min.js" PathNameAlias="SkinPath" />
<dnn:DnnCssInclude runat="server" FilePath="DNNMega/dnnmega.css" PathNameAlias="SkinPath" />
The above controls expose the following key properties that can be set:
- FilePath is the path to the file to be loaded
- PathNameAlias is a reference to a common folder location. Right now we have established two: "SkinPath" (the path to the current skin) and "SharedScripts" (~/Resources/Shared/Scripts/).
- Priority is an integer-based scheme for determining the file load order. The default priority is 100. See the Relative Order section below for more information.
- ForceProvider is a string value that specifies what provider to be used. This corresponds to the location on the page where the script will be rendered. See the Providers section below for more information. ForceProvider can have the following values:
- DnnPageHeaderProvider: adds the file to a specific location within the head
- DnnBodyProvider: adds the file to the top of the body (most framework-level files are loaded here, as that is how it has always worked in the past and there are several dependencies within the body on the framework-level files).
- DnnFormBottomProvider: adds the file to the bottom of the body (primarily for scripts that have a dependency on the ClientAPI's
__dnnVariablewhich is rendered at the bottom of the page).
NOTE: For a skin, it should register the skin.css file from the skin folder to the CRM automatically and if there is a css file that has the same name with the skin file, it should register automatically to the CRM as well.
Please review the Client Resource Management API.