Optimization Tips: Series changing channels

Much like the complexities of a broadcast TV network, sometimes popular shows get shuffled around to better align with the interests of the network. So it will be with my ongoing Optimization Tips blog series. From now on, all future posts in this series will be posted on my Telerik.com blog (yes, I have another blog there- subscribe now, if you haven't). With my access to the Telerik.com blogs restored, I'll return to trying to post more technical Telerik content there and more general .NET and Telerik news here. All of you still refusing to subscribe to RSS feeds, now might be a good time to subscribe to at least two.

To usher in the change, I've posted a new installment in the Optimization Tips series on the Telerik.com blogs. The latest installment shows you how to optimize custom skins for the RadControls for ASP.NET AJAX by turning them in to WebResources that can be combined by the RadManagers. We already know the positive effect combining has on page load time, so it is critical we apply it to our applications wherever possible. As a bonus, I've also created a cool new skin for RadTabstrip that you can download along with the associated Photoshop source!

Thanks for bearing with me during this programming change and enjoy the latest installment.

Optimization Tips: Using HTTP Compression

I know it has been a few weeks since the last installment in this series, and with TechEd on the horizon it'll probably be a couple 'til the next, but as long as there is some time in between let's explore another area of performance optimization with the RadControls for ASP.NET AJAX. This week, we're going to take a look at HTTP compression and how this simple technique can deliver a valuable performance boost to your website.

What is HTTP compression?
Since the turn of the century, almost all browsers have supported compressed content via the "content-encoding" (or "transfer-encoding") specs defined in HTML 1.1. When a browser requests a page from a server, it always tells the server if and what kind of content encoding it can handle. This information is communicated in the "accept-encoding" request header. If the server is configured correctly, it can respond to this header value and automatically compress (think Zip) the HTTP content before sending it to the browser. When the content arrives, the browser decompresses the content and renders the page.

The overall goal of HTTP compression is to reduce the number of bytes that must be transmitted over the tubes between your server and the user's machine. Since transmission time is often the slowest bottleneck in loading a page, and since bandwidth directly relates to your costs as a site operator, reducing the bytes you transmit to the user can save you money and improve your site's performance.

How do I use it with ASP.NET?
There are a number of ways to use HTTP compression with ASP.NET. If you have full access to your server, IIS 6 provides some basic compression support. Compression of static content is turned-on by default in IIS 6, but you'll need to take extra steps to enable compression of dynamic content. If you're already in a Windows Server 2008 environment, IIS 7 provides great HTTP compression support, enabling you to define which files get compressed based on their MIME type in your configuration files. Still, to use IIS' compression support, you need to have complete access to your server (specifically IIS), and to get great support in IIS you need to be running Windows Server 2008. (NOTE: For a good overview of compression features in IIS 7, see this blog post on the IIS blogs.)

Fortunately, there are alternatives for developers that want to deploy HTTP compression support with their applications (or for those devs that don't have access to IIS, such as in shared hosting environments). Several open source projects and commercial products exist on the interwebs that provide HttpModules to compress your content based on configuration rules. Once such commercial tool that I've used successfully in the past is ASPAccelerator.NET. By simply adding a HttpModule reference to my web.config and deploying a single assembly in my bin folder, I can instantly begin compressing my HTTP content (served by IIS6 or 7) based on an intelligent set of rules.

For today's tests, that is the approach that will be used to compress our test site. And since we're interested in seeing how HTTP compression helps "real world" site performance, we're going to be doing our testing a little differently this week than we have in the past.

Help Desk demo testing with Gomez
Have you heard of Gomez? If you work for a large, Fortune 500 company chances are you are using their services to actively monitor and measure your company's web performance. Gomez is one of the largest providers of website performance measurement and tracking, and as such, they have some of the best tools available for measuring a site's performance.

What you may not know is that Gomez provides a free "instant site test" that you can use to take one-off measurements of your site's performance as seen by one of Gomez's 12,000 test computers. The free service allows you to supply a URL and select a test city (L.A., New York, Chicago, Beijing, or London), and then Gomez generates a detailed report showing you how responsive your site is. This is a great (free) way to see the real world effects of latency and bandwidth on your site, which makes it a perfect way to measure the effects of HTTP compression on our test site.

And to conduct today's tests, we'll be setting-down our fun InterWebs demo in favor of using the slightly bulkier Telerik Help Desk demo. This demo displays a fair amount of data pulled from a SQL Server 2005 database, and it uses many RadControls, such as RadGrid, RadTreeView, RadMenu, RadCombobox, RadSplitter, RadAjax, and RadCalendar. RadWindow and RadEditor are their, too, but they won't have an impact on today's tests of the primary Help Desk landing page.

How will the tests be run?
To conduct today's tests, we'll start applying the techniques we covered in parts 1 and 2 of this series to the Help Desk demo, collecting 5 Gomez test results from their Chicago test server (the demo today will be hosted on a DiscountASP server in California). All tests will be run as if on empty browser cache (thanks to Gomez) and the average of the 5 tests will be reported. Once we've layered-on our previous performance improving techniques, we'll enable HTTP compression with ASPAccelerator and see what kind performance benefit it provides.

Make sense? Then let's run our tests and analyze the results.

The test results
With the tests run and the averages collected, let's take a look at the effect our different performance improving techniques had on our live test site:

While the absolute numbers here aren't great, they're also not important. This is a completely unoptimized application running on shared hosting with very little server resources, communicating from California to Chicago. What are important are the trends, and the they reveal some very interesting facts:

1. If you didn't believe the impact of leaving complication debug = true from part two of this series, believe it now. Simply setting debug to false reduced the time it took for our page to load by almost 30% (7 seconds)! ALWAYS set debug to false in production.
   
2. The same advice is true for the RadManagers (RadStyleSheetManager and RadScriptManager). By simply adding these to my page (and doing nothing else), I further reduce page load time by over 50%. Combined with the first step, 60 seconds of work has shaved almost 70% of the loading time off of my page.
3. Finally, adding the HTTP compression shaves another 30% off my page load time, producing a page that takes almost 80% less time to load than the original version! And I haven't changed any code.

The bandwidth comparison
Just as important as page load time in today's tests is measuring how much HTTP compression saves me on total bandwidth. If there is anything in this largely free marketplace we call the Internet that increases our costs as our sites become more popular it's bandwidth (and the servers required to fill it, of course). So if HTTP compression- in combination with our other performance improving techniques- can reduce the bandwidth we consume to send the same pages to our users, we'll directly impact our bottom line. Let's see how bandwidth varied over each stage of our test:As you can see, HTTP compression had a huge effect on the number of bytes we needed to send over the line to load the same exact page.

• With no "treatments" applied, we sent over 1 MB of data to our user's browser on the first visit! That's a lot of data.
  
• Setting debug to false reduced our bandwidth usage by about 15%, and adding the RadManagers only slightly lowered bytes sent from there.
  
• When we added the HTTP compression, though, we reduced the number of bytes sent over the wire by over 75%! That's a huge bandwidth savings that should directly translate into higher throughput on on our servers and improved page response times.
  

We can validate the improved page response times with the overlaid page load time stats. As the bytes are reduced with HTTP compression, we see page load time decrease. But notice how much page load time drops when the RadManagers are added to the page even though they don't significantly impact the page's footprint. Remember, all the Managers are doing are combining data, not compressing. They deliver huge performance gains by reducing the number of links on the page, thus reducing the number of requests the browser needs to make to load all of our images, stylesheets, and JavaScript.

Gotchas
As with all performance tips, you do have to be smart in your application. While HTTP compression is generally a very efficient operation that doesn't significantly task the CPU, you should be careful on high volume sites. The extra CPU cycles required to perform the compression could make site performance worse than it would with compressed traffic. In most low- to medium-volume scenarios, though, you can compress without concern. In the coming weeks, I'll highlight a hardware solution that can solve the woes of compression on high-volume sites (in addition to providing a number of other helpful performance boosters). If you want to explore the tool on your own in the mean time, visit the Strangeloop AppScaler website.

You also need to be careful with HTTP compression and Ajax. Some HTTP compression tools do not play nice with Ajax requests, breaking callback functionality on the page. ASPAccellerator provides support for the ASP.NET AJAX framework, but not all tools may be as helpful. Choose wisely.

Optimization Tip Summary
What have you learned today? Quite simply this:

• The rules from parts 1 and 2 of this series are still among the most important for improving page performance.
• Adding HTTP compression to your page with the RadControls for ASP.NET AJAX can measurably improve page performance and significantly lower bandwidth requirements.
  

Hopefully these tests help you understand and visualize the benefit HTTP compression can play in squeezing every bit of performance out of your site. In the coming weeks, I'll try to do some comparison tests of different HTTP compression methods- IIS 6/7, port80, ASPAccelerator, open source- to give you more guidance if you're trying choose a compression provider. Until then, compress away and do your part to help reduce the bits clogging the Internet's tubes!

Optimization Tips: Using RadAjaxManagerProxy Controls

In this installment of my ongoing series covering RadControls for ASP.NET AJAX optimization tips, I am going to take a short break from talking about how to optimize your page performance and instead cover a tip that will help you optimize your code. Specifically, we're going to take a look at the RadAjaxManager and the RadAjaxManagerProxy controls to see how they enable you to very easily ajaxify all parts of your application.

The ASP.NET AJAX Era
Long before ASP.NET AJAX was a gleam in Microsoft's eye, Telerik was providing robust Ajax tools to its customers. Telerik developed a full Ajax framework that made it very easy to implement Ajax in ASP.NET applications, the cornerstone of which was the RadAjaxManager control. When we began making the transition to ASP.NET AJAX, though, we decided to completely leverage Microsoft's framework in our RadAjax product. We wanted to deliver all of the time-saving benefits of the RadAjaxManager at design-time while relying on ASP.NET AJAX at run-time.

Needless to say, the RadAjax product that exists now does exactly that. It is built completely on ASP.NET AJAX and delivers all of the power of the Microsoft framework through Telerik's award winning tools. But the new RadAjax does more than change the underlying technology handling the Ajax "magic"; it also makes your Ajax configuration easier than ever.

The Old Days
Before RadAjax for ASP.NET AJAX, the task of defining Ajax settings in site's that utilized MasterPages and UserControls (read: almost all sites) was...a bit of a challenge. If you wanted the benefits of the AjaxManager's visual configuration tool (or even in-page IntelliSense mark-up), you had to place a RadAjaxManager on every ContentPage. This worked to a point, but if you wanted to also ajaxify controls on MasterPages, you were stuck with two RadAjaxManagers that wanted to control the same rendered page. To solve the problem, you could put a RadAjaxManager on your MasterPage, but then all settings in your ContentPages and UserControls had to be made programmatically- a laborious and code-cluttering requirement.

Enter the Proxies
With the advent of ASP.NET AJAX, Microsoft introduced the ScriptManager control. This control must be present on any page that uses ASP.NET AJAX and- like the RadAjaxManager- can only be on the page once. To work around the problem of ContentPages and UserControls, the ScriptManager introduced a companion control called the ScriptManagerProxy. This control enables developers to define settings for the primary ScriptManager that are rolled-up in to the primary manager at runtime.

RadAjax for ASP.NET AJAX mimics that architecture. You can now easily define a single RadAjaxManager in your application's MasterPage and then add RadAjaxManagerProxy controls to all ContentPages and UserControls. At runtime all settings in the proxies are rolled-up to the primary RadAjaxManager, but at design-time you get all of the benefits of Source View IntelliSense and the RadAjaxManager visual configurator. See Slide 1 of my embedded Google Presentation (below) to see this layout illustrated.



By utilizing the RadAjaxManager and RadAjaxProxy controls, you greatly simplify your ASP.NET AJAX ajaxification process. First, you don't have to clutter your markup with the UpdatePanels normally required by ASP.NET AJAX, making your code easier to maintain and read. Next, you don't have to manually think through how Triggers should be defined on your UpdatePanels. The RadAjaxManager automatically figures that out based on your simple definition the controls that should be updated after specific control events fire. And finally, RadAjaxManager provides a complete client-side API that makes it easy to perform advanced ASP.NET AJAX operations without having to write a lot JavaScript manually.
Client-side Support
Among the client-side support that the RadAjaxManager offers is the definition of two JavaScript events you can subscribe to: OnRequestStart and OnResponseEnd. You can see the code required to wire-up these client-side events on Slide 2 of my embedded presentation deck (see above). The events are very handy if you want to do anything on the client (such as validation) before an Ajax event fires. You can even cancel an Ajax request before it fires.

This is an extremely easy way to take more control over your application's Ajax, but what if you want to customize the JavaScript events that handle Ajax settings in your Proxy controls? Since the Proxy controls are not actual instance of RadAjaxManager, they do not expose ClientSettings directly. Instead, you need to work a little JavaScript magic to provide custom client-side event handlers for your primary RadAjaxManager that only handle controls ajaxified by your proxy.

Handling Client Events in UserControls
You recall that all ajax settings in the Proxy controls are rolled-up to the primary RadAjaxManager at runtime. That means there is only one point to define the JavaScript events that fire on Ajax requests: the primary RadAjaxManager. You cannot define JavaScript events for each Proxy control. You can, however, change the JavaScript events defined on the primary Manager in the PageLoad of any ContentPage or UserControl.

To change the events defined in the RadAjaxManager, the code shown on Slide 3 of my presentation should be added to the PageLoad event. Notice that the RadAjaxManager class exposes a very handy "GetCurrent" method that makes it very easy to get a reference to our primary RadAjaxManager from any position in our application (on a ContentPage, UserControl, etc.). With a reference to our primary Manager, we can quickly set the OnRequestStart and OnResponseEnd event names (just simple strings).

But wait! Now what happens when an ajax event defined in our MasterPage fires? It travels through our new JavaScript event handlers in our UserControl. That's no good. We only want controls ajaxified by our Proxy to get handled by our new JavaScript event handlers. Is there any way to "route" ajax events triggered in our UserControl to one set of JavaScript event handlers and ignore other ajax events? Yes, sorta.

Route the Events
Since there can only be one active set of JavaScript functions that handle RadAjaxManager client-side events, we have to manually provide support for "routing" events to the proper JavaScript functions. We can do this by inspecting the EventTarget property of the eventArgs passed to the OnRequestStart JavaScript function. That property will contain the full ClientID of the control that initiated the Ajax event. For example, if our button is located in UserControl "ProxyUserControl" on page "Default" in a MasterPage, we might see an ID like:

ctl00$ContentPlaceHolder1$ProxyUserControl1$btnUpdateTime

Ah hah! We have a way to tell where the Ajax event came from. By using some JavaScript to see if our UserControl name exists in this EventTarget string we can correctly route the RadAjaxManager client events. See Slide 4 in the embedded presentation for a complete look at the JavaScript code that handles this routing.

Gotchas
While this is a great solution for enabling custom handling of the OnRequestStart and OnResponseEnd events in UserControls, it does require a couple of assumptions that make our code a little brittle. First, you must know the names of the OnRequestStart and OnResponseEnd JavaScript functions in your MasterPage and you must assume those functions are present. Second, you must know the name of your UserControl so that you can correctly detect if the current Ajax event was fired from within the UserControl. Other than that, you're good to go.

Optimization Tip Summary
So what have you learned today? A few key points:

• RadAjax for ASP.NET AJAX implements ASP.NET AJAX (not proprietary Ajax). Spread the word.
  
• You can (and should) use RadAjaxManagerProxy controls to define Ajax settings in ContentPages and UserControls
• You can use JavaScript to "route" OnRequestStart and OnReponseEnd events to different client-side functions by interrogating the EventTarget property of the eventArgs

Hope this helps you develop ASP.NET AJAX-enable applications faster than ever and gives you the tools you need to take exacting control over your Ajax behavior. In the next installment in this series, we'll resume with our look at techniques that improve your page load performance when using the RadControls for ASP.NET AJAX.

Optimization Tips: Testing Page Performance

Welcome back to my new series covering optimization tips for the Telerik RadControls for ASP.NET AJAX. The last time we visited, I showed you how you can reduce your initial page load times 30%, on average, by simply adding the RadScriptManager and RadStyleSheetManager to your application's pages. In this installment, we'll look at two follow-up issues: how does the web.config debug property affect page load performance and how much slower is Cassini than IIS.

When I conducted the tests for the first installment, I made sure "compilation debug" was set to false in my web.config and I used IIS to get pretty accurate results (I add the qualification because I didn't run the tests on a high performance web server, but you can expect that would only improve the absolute values). What would have happened, though, if I deployed my test website and forgot to set the debug property to false? Or even more serious, if I had used the Visual Studio Web Server (Cassini) instead of IIS for my tests, how would that have impacted my perception of page performance? That's what we'll quantify in part two. The results may or may not surprise you, but they'll certainly prove to you why it's important to save your impressions of page performance until a site is running in IIS with "debug=false" in the web.config.

Simple property, big impact
One of the easiest ways to tank the performance of your fancy ASP.NET AJAX website is to forget to set the compilation debug property in the web.config to false. This property has been used by ASP.NET for years to control debug and release builds, but the introduction of ASP.NET AJAX and it's richer client-side programming environment has added a serious client-side page load penalty for sites running in debug mode. Specifically, when ASP.NET AJAX detects that a site is running in debug mode, it loads a special debug version of the ASP.NET AJAX client libraries tuned for maximum debugging- not performance.

This feature of the ASP.NET AJAX framework is great for development because it makes it much easier to debug client-side code without impacting the performance of "release" libraries. And when the time comes to move your application to production, a simple property change will let ASP.NET AJAX know that it should deploy the tuned-for-performance release versions of the client libraries and turn-off the excessive debugging. That is, of course, if you remember to change the property.

The compilation debug property is located in your application's web.config file within the system.web block. It is a boolean property that defaults to false, but if you develop with Visual Studio, it is very easy to set this property to true without thinking. If you've been developing with ASP.NET for any amount of time, I'm fairly certain you've seen this setting, but you may not fully understand how substantial the impact is of not setting this property correctly.

To answer that question, I turned to the same sample application we introduced in part one of this series. It consists of a page with RadGrid, RadTreeview, RadMenu, RadSplitter, RadAjax, and (for these tests) RadScriptManager and RadStyleSheetManager. I tested page load times using IIS and IE7/8 and FF2/3, loading the page 6 times in each browser: 3 loads with a primed cache, 3 unprimed. The key difference for these tests, though, is that I set debug in the web.config to true.

In the above chart, the "Unprimed" and "Primed" series are the same values from part one's page load tests with the Rad Managers. They serve as our baseline for the new tests. Next to the old results, you see "Unprimed+Debug" and "Primed+Debug." These series show the difference in page load times when you simply forget to set "debug" to false. From these results we learn a few things:

• On average, across browsers, debug = true makes initial page loads 27% slower
• On average, cached page loads are 23% slower
• Firefox is again the poor performer
• Initial page loads are almost 40% slower in debug mode with IIS!

The obvious point: don't deploy applications with debug still set to true! You can hurt application page load time by 25% if you miss this.

Convenient and slow
Do you remember when Visual Studio didn't have a web server built-in? I know it's been a while now, but there was a day when every web site developed in VS had to be manually setup in IIS just to see it run. Thankfully, those days are behind us and the Visual Studio Web Sever (originally Cassini) has made the process of quickly building and testing web sites as easy as a single keystroke.

While Cassini is great for rapid application development, it's far, far from being the robust ASP.NET server that is IIS. I think all ASP.NET web developers understand this fact casually (we'd never try to run an ASP.NET website in production on Cassini- if it were even possible), but I don't think the difference between Cassini and IIS performance is well understood- especially in the context of page load time with ASP.NET AJAX. To make that difference clear, I ran another batch of tests, this time testing page load times in Cassini, still with debug set to true.
As with the debug chart, this chart compares our baseline page load times to page load times for our test page (in debug mode) served by Cassini. The results are pretty dramatic:

• Firefox- even the new and improved Firefox 3- shot page load times through the roof
• On an unprimed cache, pages load 91% slower (FF2 & 3 avg.)!
• On primed, pages still loaded 72% slower
• Across all browsers, pages loaded on average 50% slower
• Excluding Firefox, pages loaded an average of 20% slower in IE7 & 8

So what? What are supposed to do about a slow development server? Nothing, really. The point here is that you should never make judgments about how long it takes your page to load if you're using Visual Studio's Web Server. When pages are in debug mode (which they usually are in Cassini), your page load time could take more than twice as long in development than it actually will in release mode served by IIS.

Optimization Tip Summary
This tip doesn't really provide you with anything you can specifically do to the RadControls to make them load faster, but it does drive home important points about measuring the performance of your pages that use the RadControls for ASP.NET AJAX. Now that you've seen the actual impact of compilation debug and the Cassini web server on page load time, you know that they can have a dramatically terrible impact on your page's performance and thus on your perception of the RadControls. Always make sure you test performance using IIS with pages running in release mode to get an accurate picture of how your pages are performing.

If you practice this tip, combined with the Rad Managers talked about in part one, and future optimization tips in this series, you'll be guaranteed to see page load times that make you smile- not scream!

Optimization Tips:The Rad Managers for ASP.NET AJAX

Today I am kicking-off a new series of blog posts that will focus on showing you specific ways you can optimize the performance of your applications built with Telerik's RadControls for ASP.NET AJAX. Whenever we use UI components to accelerate our web development, it is easy to forget that we still need to be "smart" developers when it comes to optimizing our web applications. Telerik tries to do as much as is possible at a component level to help with optimization, but as with any good thing like rich UI controls, too much is a bad thing. In this post and those that follow, I will delve in to optimization tips and tricks and show you the effects of each on a sample application. Hopefully it will help you become a better developer and enable you to maximize the performance of your apps, especially those with Telerik's RadControls.

Today's focus is on the new RadScriptManager and RadStyleSheetManager controls. These "manager" controls enable you to easily combine in to a single link all of the JavaScript and CSS links required by the RadControls. Why combine? One of the biggest bottlenecks for browsers these days is created by the concurrent requests limit. By default, both IE and Firefox limit concurrent requests per server to 4, as is recommend by the HTTP RFC guidelines. This limit can be changed, but expect few of your users to actually have done so as the process requires advanced computer skills.

With a limit of 4 concurrent requests (2 persistent connections), you can see how easy it is to clog the pipe with all of the request for images, JavaScript, and CSS on your page. Combining many links for CSS and JavaScript in to a single request can significantly improve your page load time by reducing the number of round-trip requests your page makes when it loads. And by doing the combining dynamically at runtime you don't have to send any unnecessary JavaScript to the client (for controls not in use) or manually maintain combined JavaScript files. It's one of the easiest and most effective optimization tips available.

Let's see the effect of these managers on a simple demo app that uses RadGrid, RadMenu, RadTreeview, RadAjax, and RadSplitter. We'll use FireBug (in Firefox 2) and Fiddler for our tests, and we'll run our site from IIS to ensure we get accurate performance numbers.

Requests and Bytes
The first thing you should notice when using the Managers is that the number of requests your page generates is reduced significantly. Let's take a look at the difference:

• Requests without Managers
• Unprimed cache: 32 @ 21.4 KB
• Primed cache: 3 @ 2.6 KB
• Requests with Managers
• Unprimed cache: 16 @ 11.2 KB
• Primed cache: 1 @ 1.8 KB

Clearly, the managers have a significant impact on your requests. In this demo app, they cut in half the number of requests and the number of bytes sent to the server on page load. That's a pretty significant gain and bandwidth savings for your user. Even on the download side, the Managers reduced the payload sent from the server about 11% on average, for both primed and unprimed page loads.

Page Load Times
While reducing the number of requests and bytes is good academically, it's ultimately page load time that matters to users. To see the effect the Managers have on page load time, I ran the demo through the online stopwatch in IE7, IE8 beta 1, FF2, and FF3 beta 5. I ran the stop watch 6 times for each browser, 3 unprimed cache tests, 3 primed cache tests. I then compiled the results in to the following chart.


This chart reveals a few interesting facts about the Mangers' effect on page load time:

• Usually, for both primed and unprimed caches, the Managers reduce page load time
• Unprimed improvement: 30%
• Primed Improvement: less than 1%
  
• Primed Improvement without FF2: 3%
• As has been observed in other performance tests, FF2 is a poor performing browser
• It renders pages slowly and renders cached pages slower than first request pages
• FF3 is a lot faster than FF2 (yay!)
• Almost all browsers tested render the test page in less than 1 sec with Managers
• True for primed and unprimed cache
  
• Key exception is FF2, but see note above. FF3 solves the problem.

Whether or not you'll see a 30% improvement on initial page load time in your app will require your own testing, but this analysis definitely makes it clear that the Managers can have a very real impact on improving your page's load time.

Optimization Tip Summary
To cut significantly reduce the requests and bandwidth required by your page on the initial visit, and to significantly trim your initial page load time, you should add the RadScriptManager and RadStyleSheetManager to your ASP.NET AJAX applications. For more details on how to add these controls to your page, see this page for the ScriptManager and this page for the StyleSheetManager in the Telerik documentation.

Next up, we'll look at the impact debug=true and the Visual Studio development server have on your page's performance.