Encosia - ASP.NET, AJAX, jQuery, and more

Fix “addthis_config not defined” when using async AddThis

JavaScript, Performance By . Updated March 5, 2015

I recently decided to pony up for AddThis Pro. Spread across up to five sites, that’s not very much to pay for a wide variety of well-designed social widgets. Certainly much less than what my time would be worth to reinvent them from scratch.

However, I’m always wary of bogging the site’s performance down with poorly implemented sharing buttons, counters, toolbars, etc. I tried Buffer’s Digg Digg plugin for a little while last year, but it had a noticeable impact on page jankiness and load times even with the deferred initialization option enabled.

With performance in mind, I was happy to discover that AddThis supports loading the bulk of its client-side code asynchronously. However, I was less happy to find that it didn’t seem to work when I followed the instructions on their site, resulting in a JavaScript error and no AddThis widgets at all.

In this post, I’ll cover why you should consider using asynchronous scripts, how to fix the addthis_config not defined error, and an alternate way of asynchronously including the AddThis scripts that I think may be a better approach than the one AddThis recommends.
Click here to read the rest of this post »

IIS performance tip: Cache in on consistent casing

ASP.NET, Performance By . Updated June 11, 2014

In Spring 2011, at what would sadly become the final installment of Microsoft’s MIX conference, I attended a great talk called 50 Performance Tricks to Make Your HTML5 Web Sites Faster. I was skeptical about the session due to the linkbait title, but Jason Weber from the IE team proceeded to present one of the most comprehensive talks about web performance I’ve seen crammed into a single hour.

Standardize on File Capitalization Convention

A video of the presentation is still available online as I’m writing this. Streaming seems to be broken, but the full video downloads still work fine. Even three years later, it’s still well worth spending a few minutes to watch his presentation if you’re developing for the web and care about performance.

Out of all the points that Jason covered in his talk, the tip at about 21 minutes into the presentation stood out to me the most: Standardize on File Capitalization Convention.
Click here to read the rest of this post »

The big change in Bootstrap 3 that no one’s talking about

CSS, Performance By . Updated August 21, 2013

As you probably already know if you’ve seen any tech news this week, Twitter Bootstrap 3 came out of RC and was officially released this past Monday. There are a plethora of changes in the new version, but the two most visible changes are a “mobile first” responsive grid and a new flat graphical style, ala Windows 8.

The flat styling has been especially controversial. If you didn’t need to differentiate a site with distinctive design (e.g. internal admin sites), you could usually get away with using previous versions of Bootstrap without any stylistic modification, but not so much with Bootstrap 3.

Unfortunately for those uses, the default styling in Bootstrap 3 is fairly bland until you customize it a bit or augment it with a full theme. Bootswatch and WrapBootstrap are two great resources to accomplish the latter. To simply bring Bootstrap 3 most of the way back to Bootstrap 2.3.2’s look and feel, there’s also an official theme you can apply.

So, I think the brouhaha over flat vs. gradient defaults is overblown. More importantly, that change has had an interesting side-effect that seems to have been mostly overlooked this week: Performance.

Click here to read the rest of this post »

A harsh reminder about the importance of debug=”false”

Performance By . Posted September 19, 2012

This post was originally going to be about improving performance in ASP.NET MVC websites that use the Razor view engine. Instead, it became a cautionary tale about just how important it is to run your ASP.NET sites in release mode if you care anything at all about performance.

The whole thing began when I tweeted about some rough benchmarks on ASP.NET MVC controller actions vs. ASP.NET Web API endpoints last week, and Ashic Mahtab asked me to also run some benchmarks comparing MVC’s Razor and WebForms view engines. When I ran those benchmarks and replied to him with the result that Razor was running much slower than WebForms, he had this suggestion:

@encosia did you remove the web forms view engine for the razor test?

— Ashic Mahtab (@ashic) September 2, 2012

Good idea. I did that, re-ran the Razor benchmark, and the magnitude of the change really surprised me. Razor was over twice as fast with the WebForms engine removed!

I knew that removing the WebForms view engine improves the performance of Razor view resolution, but I didn’t expect the difference to be nearly that significant. So, why was the difference so large?

Click here to read the rest of this post »

The crucial .0 in Google CDN references to jQuery 1.x.0

jQuery, Performance By . Updated August 21, 2012

jQuery 1.8 is out, and that new version is available on the Google CDN now.

That’s good news on both counts, but reminds me of an issue that I’ve been meaning to write about for quite a while now. Unfortunately, each new 1.n jQuery release results in a new wave of sites linking to the Google CDN’s copy of jQuery in a way that seems intuitively correct, but results in needlessly poor performance.

If you don’t care about the hows and whys, the short story is that it’s crucial that you always specify the full major.minor.patch version number when you use the Google CDN. Even though jQuery itself only refers to its new releases with a major.minor version number (e.g. 1.8), it’s important that you append a trailing .0 when you use the CDN to include a new minor revision on your page.

In other words, please use this URL to reference jQuery 1.8 on the Google CDN:

Under no circumstance should you omit that seemingly superfluous .0 in the version number on a production site. Failure to include the trailing zero will result in significantly degraded caching.

If you don’t care about why, you can stop here. Just be sure to add the .0 when you’re referencing jQuery 1.7, 1.8, 1.9, 2.0, 2.1, and so on. If you’re interested in why it’s so important, keep reading.
Click here to read the rest of this post »

Cripple the Google CDN’s caching with a single character

jQuery, Performance By . Updated October 11, 2011

It’s no secret that I’m a proponent of using a shared CDN to host jQuery. As more and more sites take advantage of public CDNs for their jQuery reference, the cross-site caching benefit is becoming almost a given. However, there are a couple ways that even I recommend against using these public CDNs.

With the impending policy change on hotlinking copies of jQuery hosted on jQuery.com, I expect that at least several sites will be migrating their hotlinked script references to one of the public CDNs soon. So, I think this is a good time to address one CDN-related usage mistake that I’ve seen an uptick in lately.

Click here to read the rest of this post »

6,953 reasons why I still let Google host jQuery for me

JavaScript, jQuery, Performance By . Updated December 16, 2010

It’s been nearly two years since I wrote about using Google’s CDN to host jQuery on your public-facing sites. In that post, I recommended it due to three primary benefits that public CDNs offer: decreased latency, increased parallelism, and improved caching.

Though the post has been overwhelmingly well-received, concerns have been raised as to whether or not the likelihood of better caching is truly very significant. Since the efficacy of that benefit depends entirely on how many other sites are using the same CDN, it takes quite a bit of research to make an objective case either way.

I’ve never been happy about responding with vague answers. Caching probability is a valid concern and deserves to be taken seriously. So, I decided to cobble together an HTTP crawler, analyze 200,000 of the most popular sites on the Internet, and determine how many of those are referencing jQuery on Google’s public CDN.

Click here to read the rest of this post »

Don’t let jQuery’s $(document).ready() slow you down

jQuery, Performance, UI By . Posted August 18, 2010

jQuery’s $(document).ready() event is something that you probably learned about in your earliest exposure to jQuery and then rarely thought about again. The way it abstracts away DOM timing issues is like a warm security blanket for code running in a variety of cold, harsh browser windows.

Between that comforting insurance and the fact that deferring everything until $(document).ready() will never break your code, it’s understandable not to give much thought to its necessity. Wrapping $(document).ready() around initialization code becomes more habit than conscious decision.

However, what if $(document).ready() is slowing you down? In this post, I’m going show you specific instances where postponing startup code until the document’s ready event slows perceived page load time, could leave your UI needlessly unresponsive, and even causes initialization code to run slower than necessary.

Click here to read the rest of this post »

11 keystrokes that made my jQuery selector run 10x faster

ASP.NET, CSS, JavaScript, jQuery, Performance By . Updated June 30, 2010

As an ASP.NET developer working on the client-side, one problem you’ll encounter is how to reference the HTML elements that ASP.NET web controls generate. All too often, you find yourself wasting time trying to reference TextBox1, when the element is actually rendered as ctl00_panel1_wizard1_TextBox1.

Much has been written about this, including a post of my own, so I won’t go into detail about many of the workarounds. Instead, I want to take a closer look at the performance drawbacks of one popular solution: the [attribute$=value] selector.

By specifying id as the attribute in this selector, you can avoid ASP.NET’s ClientID issues completely. No matter what the framework prefixes your rendered elements with, they still “end with” the ID you specify at design time. This makes the “ends with” selector a convenient alternative to injecting a control’s ClientID property via angle-brackets.

However, are we trading performance for this convenience? If so, how much?

When Craig Shoemaker asked that question while interviewing me for an upcoming episode of Polymorphic Podcast, I realized I didn’t know the answer as clearly as I’d like. So, I decided to do a bit of benchmarking.

In this post, I’ll share the results of that benchmarking, and show you one way to significantly improve the performance of this convenient selector.

Click here to read the rest of this post »

Automatically minify and combine JavaScript in Visual Studio

AJAX, JavaScript, Performance By . Updated May 28, 2009

As you begin developing more complex client-side functionality, managing the size and shape of your JavaScript includes becomes a key concern. It’s all too easy to accidentally end up with hundreds of kilobytes of JavaScript spread across many separate HTTP requests, significantly slowing down your initial page loads.

To combat this, it’s important to combine and compress your JavaScript. While there are useful standalone tools and HttpHandler based solutions to the problem already, none of them work quite how I prefer. Instead, I’m going to show you my dead-simple method for automatically compressing and combining script includes.

To accomplish that in this post, we will select a compression utility, learn how to use it at the command line, explore a useful automation feature in Visual Studio, and apply that to keep scripts combined and compressed with no ongoing effort.

Click here to read the rest of this post »