TinyCDN blog

This is the first post of many to come on the new weblog of TinyCDN, a cool solution provided by innovative Quotient Solutions. You can expect to see many upcoming posts from the Quotient team regarding software strategy, usability, design, and business innovation in general behind the TinyCDN service. For years we have been delivering an array of software solutions for a variety of verticals. TinyCDN is one of our first services to offer directly to end-users.

General

We upgraded TinyOptimizer to run via webservices. The impact on the application performance is slightly noticeable but now we are able to register new features as they come on board. This also makes the use of it on production machines far safer since we dont need to load the added weight of the optimization tools locally.

The second piece we decided to do was expose our API’s to the webservice for both JSON and SOAP protocols. This allows you to build a script or an app that can use the same tools we have in the TinyOptimizer.

You can optimize your own files by interfacing with our API. We currently expose SOAP and JSON endpoints at the following URLs:

 SOAP: http://tinyoptimizer.tinycdn.com/Services/Optimizer/Optimizer.svc?wsdl

JSON: http://tinyoptimizer.tinycdn.com/Services/Optimizer/Optimizer.svc/json/<method name>

The method of interest is called “GetSchemes”. It returns an array of supported optimization schemes. You will need to pass “SchemeName” to the processor service to indicate which optimization scheme to use.

I am very excited to be able to offer this to the community of enthusiasts as well as the newbies. We are very open to hearing what would help you more and of course any ideas you have that would help new folks and end users get more value from this.

I’m happy to say that for testing this I took one of my largest projects and dragged the file onto the application, it parsed all of the file types and had about 3600 png,js, css files. The application took about an hour to run but at the end I save several megabytes of space.

For those worried about privacy, we are not storing any of the files, they are destroyed after they are streamed back. In full disclosure we might add a feature that stores the metrics on each file so that we can get some more broad metrics about the use of optimization techniques.

For those interested in the new release and the api details please visit

http://www.tinycdn.com/Utilities/TinyOptimizer 

Any constructive feedback would be awesome.

Lastly, we made some ui tweaks today, the app is now officially awesome

General, TinyOptimizer, utilities css minification, javascript minification, optimization, utilities, Webservices, yui compressor

I find myself optimizing a lot of files by hand, by hand I mean, using online tools. I’m sure the cycle is pretty familiar.

1. You go to your favorite online yui conversion site – mine is http://compressorrater.thruhere.net/ 
2. Then go to the site that has the js you want to minify and download it,
3. Next, open the file in notepad and then copy into the minification site.
4. The site works its magic you download the file and then upload it back into your project.

That is how I handle Js and css. For Images I use smush.it now found in firebug

• Go to a website
• Click on yslow
• Click on tools
• Click on smush.it
• Download all images and then figure out where they came from in your directory structure and then save them back to the web.

Like most of you I have been doing this for longer than I care to admit. I am also not one that goes too long without a cool solution. If you have no idea what I’m talking about above then great, I have come up with a tool just in time.

Most of my time is spent working with custom applications and consulting with Quotient Solutions. TinyCDN is a new venture that I lean on to help with some of these issues, but I can’t rely on all of my customers to be on board with it just yet. Needless, to say I have become pretty quick at the above flow.  Anyone’s optimization kit should contain just about the same stuff.

• Javascript – Minification 
• CSS – Minification
• PNG’s – Smashing
• Jpg - Exif data

Well this weekend I got a new tool by building a small desktop client that significantly improve the flow. the key is to abstract what you are really doing. Optimizing across file types.  Ideally your bag of tricks should really just be 1 merged tool. All of the non automated solutions (aka those sitting on the webserver at runtime) require you to take an additional step. Let me explain. As a user of sites like Smush, now found in ysow via firebug, do a great job at optimization but they are not good at real world use. The reason? Because they don’t persist the directory structure of the images and require you to take a micro focus on a per page level. Essentially we are using the wrong tools to really solve the problem. Something is needed that can traverse the file system/director and make these optimizations and leave everything where it found it. Traversing the file system means that I can point my application at the root directory and allow it to run its course from top folder to bottom most folder to find png’s, css, and js files. Ahh, now it takes less time to optimize. No more excuses!

Here is what we came up with

Simply drag the file or folder into the app, click start, and it will take it from there, it also takes the task out of saving the original by making a backup folder in each directory that had a change.

Here is what the app looks like when it is done

The application is named TinyOptimizer because over time we will continue to plug-in other optimizations. The exe was built and deployed using what is called click once technology. This allows it to be more easily installed and maintained. Similar to that of a web app because you can bookmark its url and that will run the application. Each time you run it, a quick check is done to see if there are any updates or if you app has been corrupted. If you have used GoToMeeting or similar applications then the process will look familiar.

I am hoping by now you are ready for the app. Here we go:

Go to

http://www.tinycdn.com/Utilities/TinyOptimizer

then you will see a window

After the application has verified the environment it will then ask for confirmation

And then finally it will download the necessary files

and then finally you will have it installed on your machine.

Ways to use the application.

• Drag all of the famfam pack onto the application and watch it work. The app was tested into the thousands.
• Find the root of your site and drag the folder onto the application and watch it minify your js and cs
• Grab any static folders onto the application and let them run. Keep in mind it will automatically generate a new folder in each directory location to store backups. So should you find some unexpected behavior, it will be easy to revert.

You might be wondering why we are giving this application away for free?

Because I genuinely care about speed, I care that people take the time to visit a site and expect to get a fast website.

Why is this different than TinyCDN services?

A big driver to TinyCDN being different is that we want you to optimize your files before you serve them on a CDN. Again going back to the saying “Serving bloated files faster”. Files should be optimized before you try and serve them quickly. Many of the CDN providers don’t offer this and to that point many people not on CDN’s dont have the tools or time to optimize their files. This application can be used for anyone, in any hosting environment.

Is this application Opensource?

No, you are free to use the application in any capacity that is not competitive to TinyCDN.

Can I use this application for my company website or commerical web application?

Yes, go for it. We are advocates of speed. If you end up with good results please drop us a line, we would love to hear about your success.

What do I need to run this app?

A Windows machine with .net 3.5 installed. The clickonce app should take care of checking for dependencies but if you run into any issues please drop us a line.

What are you using to optimize the files?

• PNGcrush
• Yui Compressor (no munge, preserve semi, disabled micro optimizations)

How did you get a windows app to animate like that?

WPF, welcome to graphics card application acceleration.

I hope you enjoy the application. Share it with others and let us know any feedback that you feel would really add value to the app and its users.

====

Download TinyOptimizer here

====

General, TinyOptimizer, utilities css minification, javascript minification, optimization, pngcrush, tinycdn, utilities, yui compressor

Hello general internet and fellow speed freaks. I want to talk a bit about optimizing pages. Often we like to think about cool things like smush.it, pngcrush and other tools but today I am going to keep it simple. There is a lot that can be done by general page authors and designs to keep things small.   At Quotient we strongly believe that it is everyones job to optimize user experience, not just the dev team. At the end of this short example designers and business users will be knowledgeable with what it takes to make pages faster and images smaller.

Names will not be mentioned to protect the innocent.

Lets take for example this ordinary image taken from an ordinary site 

it is 150 x150 and is   35,024 bytes or ~ 35Kb.

While this doesn’t immediately strike the non-enthusiast as anything out of the ordinary I have to mention that on this same page this image is located there are 8 of these exact same images. Supposing they are the same size we get 35kb x 8 = 280kb. Yikes!

Using a very ordinary web graphics program like Photoshop we can do a simple conversion of jpg to png and get a very reduced image with a file size of 16.33KB. Zooming into the image I can not tell that anything has changed. Yes, I am picky about persisting quality images.  In less than 2 minutes I have already saved 35-to-16 is 19K off the page in just this 1 image. Now if we do the math and assume all things equal we have saved the page approx. 152Kb.  

I am still not ready to call this done. I am sure we can get it smaller.  

Lets go back to jpg, since the image is small and there are a lot of colors in the space I think we can easily afford to go with a higher compression value in jpg and get a smaller image that you still use as a replacement for the original. Going with a higher compression value yields a image with the size of 7.44Kb. Now we have saved an additional 9kb from the png conversion. This gives the page about 72Kb more savings bring us to a grand total of 220Kb saved.   Don’t forget the original size was just 280Kb and now we are at 59.52Kb.. 79% saved

I welcome you to try and compare them to figure out which is which, don’t cheat.   Again, think what adds value to the end user a cleaner image by X% or a faster page.

Saving space on a page improves user experience, decreases the load on your hosting enviornment, and saves trees.

(the image on the left is the smaller of the 2, by nearly 80%)

General

Speed of delivery is a critical component for the success of a website, but the internet is a fickle creature and can’t be relied on to offer fast or consistent service. Sometimes all a developer can do is make their content as easy to deliver as possible and hope it gets handled well. In this era of Web 2.0 no website is complete without at least one small interactive gadget, but the resources that make up that gadget are far more massive than those needed for a static HTML page, and thus take much longer to load. Graphics, libraries, scripts, stylesheets; even modestly sized websites can quickly get out of hand. The biggest culprit for dragging down loading times is Javascript. Javascript is used for almost everything these days, from simple form validation to mammoth social networking sites. Javascript is easy to work with and a great tool, which makes it very easy to get carried away. Luckily, Javascript bloating is such a widespread problem that many excellent tools for compression have appeared and are in heavy use today. One of the most popular is an open-source command line tool called Gzip.

Gzip is simple to use and yields very high reduction rates. Here’s an example from an article by Mojo on seifi.org1.

 Load time..

 Gzip reduced the size of the delivered content by 70%, which reduced the total amount of data delivered by 44GB, estimated for 1 million unique hits over a day.

The corresponding time reduction was 51%, saving a total of 145 hours loading time (that’s 521,000,000 milliseconds!) again estimated for 1 million unique hits over a day. One downside of using Gzip is that a few older browsers don’t support it, which means when they receive a page which has been Gzipped the browser doesn’t know how to display it. All it takes is a few carefully chosen headers to avoid this issue2, but the problem is slowly dwindling by itself as older browsers drop out of use3. Note: All current browsers support gzip.

Gzipping can sometimes be difficult to implement on the server and thus is not done all the time, TinyCDN is a good tool to use for solving this because you have granular access to what files are gzipped and which are not.

General

The Quotient team (developers behind TinyCDN) have been invited to attend SXSW and showcase some of the technology that is working behind the scenes of TinyCDN. 

We will be at the booth from 12pm to 2pm and would love to meet any of you interested in either TinyCDN or the awesome tech stack.

Wondering what the tech stack is?

.net 3.5
asp.net MVC framework
Mootools
WCF
Silverlight
Custom “smarty template” framework (but for .net)
SQL 2008
GoGrid for grid computing needs
Amazon EC2 for worker processes
Amazon s3 and Cloudfront

General events, SXSW

TinyCDN is can help you make your site faster. By offloading static files to a CDN your end users can experience a drastically faster site.Other CDN providers are hard tow work with, expensive, and make the setup complex. with TinyCDN you can be up and running in a matter of minutes.

FAQ

General

I read and interesting article the other day starting at Ajaxian called Steve’s State of Performance 2008 and followed the article to a final exam that Steve had given his students. One of the questions posed in the test is:

“Why is it wasteful to send cookies on requests for static resources, and what are two ways to avoid this problem?”

For a lot of us speed freaks the obvious answer is because static files don’t need cookies and neither does the server to server them. After all, the file is static. Since I read this question, I have been wondering why so many of the websites on the net don’t think about this, with some assumptions I came up with the following reasons/excuses:

1. Who cares, cookies don’t cost that much
2. Business users and stakeholders will never know (I have never seen a CAT

   script with validating static files are on a different domain)

3. Requires more setup during the development process
4. Relative links, I mean, absolute links, (aren’t they the same?) really

   matter

5. Not in the specifications (I checked the SRS and it is just not there)
6. I have a fast server and good internet connection
7. Don’t have budget for such fancy things

A current project we are working on is a perfect example. In the image below

you will see a breakdown of a very ordinary site:

(Ordinary is a relative term but it actually has far fewer http requests than most sites I encounter. Total http requests on clear cache is 50)

From this diagram we see that the page loads in just over 6 seconds with an empty cache.

Now lets look at the cookies and what the page is actually requesting. The diagram below is a generated report that shows how many of the requests have cookies in the request header. We can see that there are a lot

Improper use of a Static file domain costs this page roughly 11.9K. per page load. Wow that is a lot…well not really when I say it like that but allow me to iterate the scale

• 11.9Kb x 10 = 119Kb
• 11.9Kb x 100 = 1.19mb
• 11.9Kb x 1000 = 11.9mb
• 11.9Kb x 10,000 = 119mb
• 11.9Kb x 100,000 = 1.19gb
• 11.9Kb x 1,000,000 = 11.9gb

That is not the entire picture of course, we have to take a few other items into consideration. The site pictured above is also not using etags or expires headers. This means that for each page the browser is likely asking the server if the content has changed. This is where the 304 comes into play. The 304 is the silent killer of speed. It tells the browser that nothing has changed on its side and to use the local copy. Does this really mean that we are optimized? no, it doesn’t. The cookies are sent to the browser in the handshake between browser and server (http request) so the damage is still already done and the impact of this issue is felt on every page load, not just on the first page.

The second page request is the first item that should be optimized by the use of a new domain name. Here is the request

Request 2:

• Action: GET
• Url: http://domain.com/styles.css
• Host: meetingtechonline.com
• Result code: 200
• Transaction time: 0.260 seconds
• Time to first byte: 0.066 seconds
• Document: 1
• Socket: 5
• Request size (out): 619 Bytes
• Response size (in): 8242 Bytes
• Request Object Size (out): 0 Bytes
• Response Object Size (in): 7831 Bytes

Request Headers:

• GET /styles.css HTTP/1.1
• Accept: */*
• Referer: http://domain.com/
• Accept-Language: en-us
• UA-CPU: x86
• Accept-Encoding: gzip, deflate
• User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1;

  .NET CLR 2.0.50727; .NET CLR 3.0.04506; Media Center PC 5.0; InfoPath.2; .NET

  CLR 3.5.21022; MS-RTC LM

• Host: meetingtechonline.com
• Connection: Keep-Alive
• Cookie: __utma=219136645.1398114812.1221606831.1228601858.1228610625.26; __utmz=219136645.1228601858.25.4.utmccn=(organic)|utmcsr=google|utmctr=quotient+1234567+2345675|utmcmd=organic;

  ASP.NET_SessionId=mhwcdbnkixnb5oalwu2dbzyw

Response Headers:

• HTTP/1.1 200 OK
• Content-Length: 7831
• Content-Type: text/css
• Content-Encoding: gzip
• Last-Modified: Sat, 09 Aug 2008 05:34:24 GMT
• Accept-Ranges: bytes
• ETag: “0f0d494e1f9c81:1980″
• Vary: Accept-Encoding
• Server: Microsoft-IIS/6.0
• X-Powered-By: ASP.NET
• Cache-control: private,max-age=172800000,must-revalidate,proxy-revalidate
• Expires: Sun, 15 Jun 2014 21:43:02 GMT
• Date: Tue, 23 Dec 2008 21:43:02 GMT

We can see a lot of things from this request. But because the topic today is cookies we will just focus on that.

For many of the non-technical readers they have no idea what a cookie is or what is looks like, here it is:

Cookie: __utma=219136645.1398114812.1221606831.1228601858.1228610625.26; __utmz=219136645.1228601858.25.4.utmccn=(organic)|utmcsr=google|utmctr=quotient+1234567+2345675|utmcmd=organic;

ASP.NET_SessionId=mhwcdbnkixnb5oalwu2dbzyw

To complete the thought of dispelling reasons/excuses for not being fast, allow me to go down the list:

1. Who cares, cookies don’t cost that much

Maybe, depending on traffic, this might be a reason you are planning to get a

larger server next year

2. Business users and stakeholders will never know (I have never seen a CAT script with validating static files are on a different domain)End-users only know when things are slow, they aren’t concerned with why most of the time. Amazon has estimated that it looses 1% of its sales for every 100ms of latency
3. Requires more setup during the development processNot true, it should be taken into account in the architecture of the system but there is not a good reason considerable effort is needed to adhere to

   this guideline

4. Relative links, I mean, absolute links, (aren’t they the same?) really matterYes, it will mean that you need to spend more time testing your links to make sure you are following good practices. We all want to, this gives us a better reason to.
5. Not in the specifications (I checked the SRS and it is just not there)Okay, maybe with large scale systems but most small to medium sized systems dont have a performance requirement. This is a way to be faster than some and better than most
6. I have a fast server and good internet connectionGood, lets keep it that way. Focus your server on real work (aspx, php, sql etc.) let the fancy file system do the brainless work
7. Don’t have budget for such fancy thingsYou mostly likely do, use of a CDN and doing practices like this often lower your overhead and extend the life of your existing architecture. Based on the figure from Amazon, this might just make you more money

TinyCDN fits in here somewhere right?

Yes, it does! Not by some magical proprietary method,  but by simply offloading your static files to the CDN, not only are you reducing the load on your server you are also lowering the overhead on the site which in turn reduces latency and other weighted factors for your users.

General cookies, page speed, request, static files