    
|
|
|
|
|
|
|
At Twitter, one of our key metrics for success was ‘time to first tweet’, the time taken between someone navigating to twitter.com, and seeing the first Tweet in the page. I’ve always thought it a useful metric, as initial interaction speed is vitally important; take too long, and users lose focus and leave.
There seems to be a lot of fear, uncertainty and doubt (FUD) in the programming community around the speed of JS web apps, especially with the initial page load. Server-side generated HTML is making a come-back, indeed Twitter eventually moved back to that away from a stateful client. It seems the single-page-app approach has many vocal opponents.
I’m here to put some of that FUD to rest, and show you that it’s perfectly possible to make JS web apps that load extremely fast. I’m going to show you some of the techniques I used to make monocle.io so fast.
First, a little disclaimer. As always, this approach may not be for everyone. If it turns out that server-side-rendering is best for you, then great - use it! Know your options, and use the best tool for the job.
In my experience there are four main bottlenecks to initial page loads. They are, in no specific order:
By default Rails apps are single threaded, you’re only going to get one request processed at a time. Even if you’re not using Rails, or you turn on threading, network and DB calls can block the interpreter for everyone since threads are restricted by the GIL. [1]
MRI is restricted by the GIL, which prevents Ruby threads running concurrently. While modern DB drivers prevent the interpreter blocking on IO calls, the fact of the matter is that only one Ruby thread is performing at any one time.
If you go down the evented route, with EventMachine & Thin, you’ll have to make sure that every single part of your application is EM aware, from the server to the database driver. Unfortunately this often requires re-writing large parts of your application. Many libraries and middleware either don’t support EM, or require patching. You can see the problem manifest itself in the amount of gems that inject EM code into popular libraries; it’s not pretty.
Processed based web servers, like Unicorn, are a fine choice. They’re reliable and, as long as you have enouch processes, you’ll mostly solve the IO/GIL blocking problem. The downside, of course, is that each process has a significant memory overhead.
There’s a new threaded server on the block, Puma, that has some really promising benchmarks. I’ve been experimenting with running Monocle on Puma, instead of Unicorn, and getting some satisfying performance improvements. As soon as Rubinius is a bit more stable, I’ll switch to that runtime and take advantage of real threads that aren’t throttled by the GIL.
If you take a look at monocle.io, you’ll notice that we need to fetch a list of the most popular posts every page load. This needs to happen really fast, since the posts are loaded concurrently to the page request.
However, this wasn’t happening as quick as I’d expected. I investigated further, and it turned out that every request to fetch the top 30 pages was running about 151 SQL queries. Specially this method was the culprit:
def as_json(options = nil)
user = (options || {})[:user]
{
id: id,
votes: votes,
voted: self.voted_users.include?(user),
created: self.user == user,
score: score,
title: title,
url: url,
comments_count: self.comments.count,
user_handle: self.user.handle,
created_at: created_at
}
end
Notice we’re doing five extra SQL queries whenever we’re serializing a Post to JSON. Clearly this is far from efficient, and we need to do a bit of data-denormalization.
I created columns on the posts table for voted_user_ids, comments_count and user_handle. I then made sure that data was kept up to date using Postgres triggers. You may want to do this at the ORM level (say with a ActiveRecord counter cache), but I’d rather leverage the DB to do this. Since this particular application (Monocle) is read-heavy, I’m not too worried if writes take a bit longer and data is duplicated.
By getting rid of all those extra queries in the JSON serialization, I was able to return a set of posts with only two SQL queries - one to find the currently logged in user, the second to fetch the top posts.
Your user’s network is the one part of the equation that is particularly hard to speed up. Google have been developing SPDY to try and improve some of TCP’s pitfalls, and if your server supports then I’d recommend enabling it.
Ultimately the answer to improving the download time of pages is to try and send less over the network, reducing both the size and number of assets.
Run your JavaScript through UglifyJS, and your CSS through YUI compressor.
The JavaScript compressor will actually rewrite as much of your JS as it can to save characters. Less data over the wire means faster web pages.
Concatenate all your JavaScript & CSS into two files, application.js, and application.css. Less TCP handshakes and server requests often means assets load faster.
It’s a good idea to append a checksum or mtime of the file onto the file’s name. That way, whenever the file changes you’ll get automatic cache invalidation.
If you have a lot of changing JavaScript, and a lot of stable libraries in your application, you may want to split out the two.
GZip JavaScript & CSS assets so they’re compressed over the wire. You don’t need to GZip most image types as they’re already compressed.
If you’re using Rack, you can get this by simply adding the following line. Be aware though that it can conflict with some of your other middleware, and breaks Sinatra’s streaming.
use Rack::Deflater
It turns out that GZipping assets had the biggest impact out of all the tricks mentioned in this article on Monocle’s load time.
Enable long lived caching for all your static assets. Set the expiry for about a year, as most clients don’t support longer ones.
By setting Cache-Control to public you’re instructing browsers to cache assets locally, and not to request them again until they expire.
Cache-Control: public, max-age=31557600
Date:Wed, 03 Jul 2013 15:09:55 GMT
Expires: Thu, 03 Jul 2014 21:09:55 GMT
Cache invalidation is simple since you’re appending the mtime of assets to their names. To expire a cache, simply touch the file updating its mtime. You’ll get this for free with Sprockets.
Host all your static assets on a CDN like Amazon’s CloudFront. That’ll ensure that assets are served as fast as possible, and as geographically close to the client as possible.
For Monocle I simply proxy assets through Cloudfront. If Cloudfront doesn’t have them cached, there’s a cache miss and Cloudfront requests the files from the server.
Cache invalidation is also incredibly simple: when the file changes, its name changes therefore causing a cache miss and invalidation.
On the client, there are couple of trick to speed up the browser’s rendering speed, mostly about hinting to the browser which resources it’ll need to fetch.
Make sure the initial page is incredibly quick to load - don’t do any SQL queries or complex server-side rendering. This will allow the browser to scan the page and figure out which remote resources like JavaScript and CSS it needs to download and parse as quickly as possible.
Add the defer attribute to all <script> tags. This will ensure the browser won’t use the legacy ‘document.write’ compliant behavior, and script downloading won’t block the rendering of the rest of the page.
<script defer src="/application.js"></script>
Be aware that a combination of defer and some libraries will break a few browser like IE <= 9.
Ensure that all scripts that don’t need to be present on page load, such as analytics, are appended to the page dynamically.
$(window).on('load', function(){
$.getScript('http://some/analytics.js');
});
You’ll notice in Monocle the loading of the ‘Top Posts’ is synchronous to the page load - you’ll never see a flash of white unloaded content, or a loading spinner. I’ve achieved this by having a separate script, /setup.js, which is referenced in the initial page load. setup.js contains the top posts, and bootstraps the app with initial data.
I want to finish with a few page speed tools, that have been invaluable into speeding up monocle.io’s loading time.
Use the audit tab in the Google Chrome Inspector to get an insight into some performance metrics, such as browser caching and gzip compression. It’s worth running it in incognito mode, as some extensions can mess up the results by injecting their own assets. Also note that the Inspector’s cache settings can also have an impact on results.
Chrome’s network inspector is also invaluable for seeing what’s affecting your page load times. You want to move those two blue and red lines (DOMContentLoaded & load) as close to the left as possible. Remove assets, and cache as much as you can before DOMContentLoaded is triggered.
Google have some really excellent articles on page speed, as well as an extremely useful tool called PageSpeed Insights that will analyze your web app and provide you with a bunch of tips on improving page rendering.
Hopefully I’ve demonstrated here that It’s perfectly possible to create extremely fast loading JavaScript web applications. Once the application’s assets are on the client, the speed increases only continue. Rendering templates on the client is extremely fast, and you can provide a responsive and asynchronous UI to make interactions seem even faster.
[1] - It turns out that in my haste to dispel FUD, I’ve actually gone ahead and spread more. Modern Ruby DB adapters do not block the GIL, the interpreter is ‘unlocked’ during IO calls. Furthermore Rails 4 is threaded by default.
]]>It's truly a unique and interesting experience to watch someone transcend from one community to another with little to no issues. In this case, we're talking about Elijah Manor who successfully worked to build his reputation in the open source community while still maintaining his strong presence in the Microsoft world. He has the best of both communities at his disposal, now able to leverage his cross-platform expertise into a new life-changing role with Pluralsight.
We managed to snag some of Elijah's time amidst the many projects he has going on to learn about his new direction and how Microsoft has impacted his development views.
I used to tell myself I'd never start my own business, but it came to a point where going out on my own just made sense.
The time I worked at appendTo was great. I learned a lot and was privileged to work with a great and talented group of developers. While I was there, I participated in several consulting projects, architectural reviews, worked closely with Microsoft on some interesting projects, and led several front-end web development training classes.
I left appendTo to try to focus my time primarily on the training, since that is what I've become passionate about over the years. I enjoy blogging, teaching, writing, and speaking and I wanted to try to find a way that I could do those full time. I used to tell myself I'd never start my own business, but it came to a point where going out on my own just made sense.
I've actually only been on my own for about 3 months at this point. I am currently working with Pluralsight to author several front-end web development courses until the end of the year. I've finished two courses so far entitled Front-End First: Testing and Prototyping JavaScript Apps and Fixing Common jQuery Bugs. I'm also in the final stages of releasing another course in the next week or so called "jQuery Tips & Tricks" that will be available from my Pluralsight profile.
Some of the main challenges I've faced thus far are trying to figure out how to start a business, how I go about paying business taxes, getting personal health insurance and dental coverage, and things like that. I've always relied on an existing company to provide or do many of those things for me. This is a brand new world that I'm slowly trying to figure out. Thankfully, I have a great financial counselor, lawyer, and CPA to help me navigate these uncharted waters.
I have a wonderful wife and three lovely children and it's a huge priority for me to make sure I can provide for them, so before leaving appendTo I wanted to make sure we could handle this transition. It is true that Pluralsight pays royalties to their authors for how much of their courses' have been viewed, however, they also pay the author a completion fee at the point when their course is published.
I've agreed to do at least 6 courses for Pluralsight which should get me close to the end of the year. After I finish the 6 courses my hope is that there will be a steady stream of royalties, but there is a risk on exactly how that will turn out. I will then reevaluate where I need to focus. I would like to continue making courses for Pluralsight, although I will most definitely need to slow down the pace some. I'd like to eventually start focusing on making my own content for on-site and remote trainings, but I'm not quite sure how that will play out. If I'm not making traction with any of these ventures, then I may start doing hourly work with a consulting company to help provide some consistency and stability.
I wasn't sure how the series would go over when I first thought of the idea. I liked the idea and this is my type of whimsical humor. Up until recently many of my blog posts and talks haven't shown my personality and I wanted to try and switch things up a bit.
The blog series was really an attempt for me to make a new talk at a steady pace. Usually when I make a new talk I invest a lot of time working many nights right up until I present the session for the first time. Instead, I wanted to have a blog series that I could continue steadily and then string them together to make a new talk. The nice thing about this approach when speaking is that I can also add, remove, or swap items from the blog series depending on my audience and the amount of time I have to present.
Generally, I have gotten positive feedback on this particular series in that it was clever, easy to search for on the Internet, and that there was a lot of helpful information. I've also received some negative feedback in that I was stretching the analogy a little too far, but that is totally understandable and I can see that viewpoint. My main goal was to create a semi-interesting storyline that might be memorable, fun, and informative at the same time.
If you look closely, you'll also see an interesting trend among front-end web developers to move away from jQuery altogether and to instead start using modern browser APIs.
Over time I've continued to narrow my focus to what interests me at the time. I mainly picked up jQuery because I started to learn ASP.NET MVC before its official 1.0 release. I would read Phil Haack's blog and notice that he used jQuery to help with his Views. It was then that I started to learn about the ins and outs of the library and is when I began to engage with the community.
Once I started working at appendTo, I was placed on several projects that challenged us on how to structure and architect large applications. jQuery was still a large part of our project, but in order for us to address the needs of the project, we needed other constructs and patterns to assist us as well. At first we came up with our own organizational techniques, but when we eventually moved towards making jQuery UI Widgets and then picking up Backbone.js and RequireJS to aid our development.
If you look closely, you'll also see an interesting trend among front-end web developers to move away from jQuery altogether and to instead start using modern browser APIs. Although this is doable with modern browsers, I don't see the vast amount of developers going this route, at least not anytime soon. However, what I am seeing is a lot of developers moving to adopt AngularJS, which natively doesn't depend on jQuery, or other MV* frameworks. If this trend continues, then I do see the overall usage of jQuery decreasing over time, but it is hard to gauge how quickly and over what duration.
With that said, I still think jQuery is important and that developers should know how to use the library and to understand what is really going on, which is why I've worked on two jQuery specific courses for Pluralsight entitled Fixing Common jQuery Bugs and soon to be published "jQuery Tips and Tricks" co-authored with Dan Wahlin, which will be listed on my Pluralsight profile once it's live.
I briefly touched on this, but I do encourage you to pick up other tools for your toolbelt. For example, pick any of the MV* frameworks and invest some time learning one of them, whether it be Backbone.js, AngularJS, Ember.js, etc…
Well, I'm just this guy who likes to learn and to share that with others. I started using ASP.NET WebForms many years ago when I worked at Acxiom in Arkansas and then I eventually moved to Nashville, TN to continue to work with .NET technologies. As I mentioned previously, jQuery only came to my attention when I started to use ASP.NET MVC. At that point, I was slowly introduced to the broader non-Microsoft community. In some ways it was a shock, but in other ways it was not. I was used to pretty good documentation by Microsoft and that their tools and libraries just worked well together. However, documentation can be lacking in many OSS projects and it can sometimes be hit or miss whether an OSS project will "play nicely" with another project. These are over generalizations and there are numerous exceptions to both of these statements. What I'm actually seeing is that both worlds are starting to meet in the middle, which is great for all!
The thing that I like about the MS stack is how much effort Microsoft puts into making them work well together. There are exceptions of course, but it's in their best interest that they work together and you can tell a lot of effort has been invested in that. What has most encouraged me about Microsoft in the last five years is the amount of focus they have put into OSS and how transparent they have been on many projects and tools. In addition, many of the new services and frameworks they are making provide extension and integration points, allowing developers to tie into well known non-Microsoft technologies such as Git and Node.js for example.
The IE userAgent program is a new program that was started several months ago. The agents are a group of developers who love web standards and are passionate about web technologies. You will probably see us around in various developer communities across the web trying to promote cross-browser coding best practices and encourage and assist developers as they run into issues or roadblocks.
Much of the negativity towards IE is usually targeted towards oldIE (IE6/7/8). IE9, IE10, and especially IE11 have really done a much better job on focusing on web standards and in many cases, as long as you follow many of the best practices, IE9/10/11 will just work. There are gaps in functionality as you can see from Can I Use, but for many of those you can utilize Modernizr and use a Polyfill or Shim to bridge that gap.
I would say that IE userAgents aren't sold out for IE. Many of us actively use other browsers as well. We, as a group, want to see IE continue to move forward, we want to see websites work everywhere, and we want to make it easier for developers to do their job. Modern.ie is a great initiative, that the IE userAgents stands behind, and provides tools for developers to make it easier to test and debug their applications in oldIE as well as provide a nice tool to analyze your site for common coding problems.
As a developer, I enjoy the Chrome DevTools a lot.
Being an IE userAgent has encouraged me to use IE10 more than I did otherwise, which is great, because I've been able to provide feedback to Microsoft about the things I like and also areas where I would like to see improvement.
You might find this strange, but I personally use Google Chrome as my primary browser. At the same time, I want Internet Explorer to succeed and I think it's important that developers don't code themselves to only one browser or rendering engine.
As a developer, I enjoy the Chrome DevTools a lot. They move very quickly and I use the Canary build because I want the latest stuff now. With that said, I've been very impressed to see all the great work that Microsoft has put into the recently announced IE11 Developer Tools) and I look forward to watching those tools get even better. It's in my best interest to have multiple browsers on my machine and to be able to use them to their fullest as I develop applications and teach others how to do so as well.
I have really enjoyed the transparency of the Visual Studio and ASP.NET teams in how they progress and communicate, not only in the public, but also among the Microsoft MVP and ASPInsider programs. Over the last several years I have participated in those programs, they have been very open about our feedback, have included us in their direction, and have enabled us to feel as we are guiding the future of those tools and libraries.
However, with regards to Internet Explorer, I would say that transparency is also an area where Microsoft could improve. IE has thankfully changed a lot in terms of adopting web standards, having a renewed focus on performance, and pushing the web forward. The area that seems opaque is what features might come out in the next release of Internet Explorer and when those features might be released. This is easier to track with other browsers since they have weekly, daily, and nightly builds accessible to developers. Developers expect a new release of Internet Explorer at best only once a year. Those are some of the frustrations that I see in the developer community. I understand that Microsoft's model is different from their competitors and I imagine that comes into play with many of these decisions. I don't know the answer to this riddle, but the great and encouraging news is that with the introduction of the IE userAgent program, I have seen topics like these being seriously discussed and I have seen progress being made.
There have been several times where I've said that I would stop tech tweeting for one reason or another, but in the end I keep coming back.
Yeah, I am not physically tweeting all the time. If that were the case, then I wouldn't be able to get anything done. I first started tweeting tech related articles because I was already scouring the web for new tech news and thought I'd start sharing those on twitter. I did most of my research in the early morning and then I'd tweet them all out, but soon found that was annoying some of my followers. So then I wrote a desktop program to schedule my tweets so that I could make the information more digestible. Since then, I've used other online systems to schedule my tweets and I currently use Buffer which works really well for my needs.
When I first started sharing tech tweets the quality wasn't as high as they are now, but unfortunately, I didn't realize that at the time. I was pushing out numerous "Top 10 jQuery Plugins" types of posts, that tended to be popular, but really didn't have much substance to them. In addition, the more I've learned about front-end web technology, I've been able to better identify what is valuable and high quality.
There have been several times where I've said that I would stop tech tweeting for one reason or another, but in the end I keep coming back. It really has become a part of who I am and what I do. I enjoy knowing the latest and greatest tools, tips, and technologies in our field and I also enjoy sharing those with developers that are interested. So, tech tweets are a natural extension of what I am already doing and is a way I can be involved with our community. There are many other avenues to get this information. A great list of resources of how you can keep up to date with various front-end technologies can be found at the Front-End Rescue.
So now that we know that you're actually human and not a non-stop tweeting robot, we want to thank you for sharing this great info and wish you great success with your new endeavor!
]]>The artist statement for Lynn Cazabon, visual arts, and Neal McDonald’s, visual arts, multimedia project, Junkspace, 2012, will appear in the Vol 46. No 5 issue of Leonardo — Transactions.
Leonardo is a peer-reviewed academic journal published by the MIT Press covering the application of contemporary science and technology to the arts and music.
http://www.leonardo.info/transactions.html
Junkspace “is a time and location sensitive video installation and corresponding iOS App that superimposes two forms of waste, one earth—bound (electronic waste) and the other celestial (orbital debris).” Learn more, or download the app at the installation’s website.
]]>It is with mixed emotions I am writing to announce that Patrick Simon, Business Analyst/Developer in DoIT’s Business Systems Group, will be leaving UMBC to become a consultant with Accenture. His last day on campus will be Thursday, August 15th.
Patrick has been with UMBC since 1998,
starting as a student employee and then hired full-time as a programmer to assist with the Student Information Legacy system and Y2k efforts. In 2003 Patrick joined the BSG technical
team supporting the PeopleSoft Finance system. After a very successful three-year
tour he took his new skills and moved over to the technical team focused on the
implementation for the PeopleSoft Student Administration system.
Patrick has been instrumental in the success of many projects at UMBC. Some recent projects include an automated process for Admissions Posting Decision, which he co-presented at the most recent Regional PeopleSoft Users Group in June 2013, Online Transcript Request system from AVOW, and web-based front-end solutions for UMBC’s Request Tracker (RT) system.
Patrick is another DoIT staff member with a UMBC success story. While working full-time he completed his Bachelors in Information Systems, got married and now has four beautiful daughters, and somehow managed to achieve an MBA from University of Maryland University College in 2011.
I have truly enjoyed watching him grow into the professional he has become. Please join me in congratulating Patrick on his past and future successes.
Sincerely,
Joe Kirby
Asst. VP, Business Systems Group
Division of Information Technology
]]>Starting with Google Glass, wearable technology could usher in a new era of security weaknesses, researchers say.
Internet-connected devices are ripe for hacking—and it seems that wearable gadgets like Google’s forthcoming head-mounted computer, Glass, are no exception.
]]>|
|
|
|