Front End Optimization

Over the last year and a half or so I’ve spent a lot of time dealing with javascript widgets on web pages. One thing that I learned very early on is that people don’t have a lot of patience for slow widgets on their blog/website. As a result I’ve spent a fair amount of time trying to hunt down various tips/tricks to speed up load time. Some of these optimizations take place on the backend (actually serving up the javascript), but a surprising amount of optimization can be done on the frontend that many don’t even consider. In order to do my little part to spread the word, I’ve decided to do a series of posts with some helpful techniques to optimize your front end load time on web sites. This will be my first series on the blog, but it seems like a popular enough thing these days that I’ve decided to give it a try.

So first off, why do we care about front end optimization? Take a look at the breakdown for Amazon.com as an example (click the image for a larger view):
Amazon load time

The red bar represents the time it took to serve and download the core page from the server (920ms in this case). The rest of the 6.34s is spent downloading images, css, js, and rendering/executing it all. Clearly there is plenty of room for optimization on the front end. (Note: many of the requests have been stripped from the screen shot – limited only to HTML requests – for brevity.) This is just for Amazon – many other sites are even worse ratios for front end vs. back end load time.

Now that it’s clear that there is optimization to be done, how does one get started? I’d recommend getting started with a couple basic tools right off the bat. Here’s my short list:

  • Firebug – great addon for Firefox with tons of features helpful for front end optimizing (among other things)
  • YSlow – an addon to an addon, YSlow extends Firebug to give it a new tab with a bunch of handy features. It also has some tips built right in and will tell you which you’re doing and which you’re not
  • HttpWatch – an HTTP traffic sniffer for IE.

In my next post I’ll start covering some basic techniques to improve performance. Got a tip of your own? Let me know in the comments.

Posted in General | Comments Off on Front End Optimization

Ubiquity

For those of you that don’t already know, Mozilla Labs recently released an early version of Ubiquity. Ubiquity is a command line interface that opens up new options to interface with your browser and integrate your web apps. Check out the video for more info.

Overall I think this project is very interesting. For the techies/power users out there it provides a much more efficient way to do complex tasks. This type of UI lends itself well to the repetitive tasks that you face on a daily basis (in particular the email commands in Ubiquity are a great example of this). The real power of Ubiquity comes from its expandability though. New commands can be added by adding simple javascript functions to the addon. These additional commands can then be shared with a special link tag in a document and can even be automatically updated (if the user has given permissions for this).

I’ve taken a stab at my first Ubiquity command. You can get it here. It adds a command to add RSS feeds to Newsgator (my RSS reader of choice). Just hit CTRL+SPACE (to open Ubiquity) then execute the command “add-to-newsgator” and it’ll search the current page for an RSS feed and add it to your Newsgator account.

What do you think of Ubiquity?

Posted in Code, Javascript | Tagged , , , | Comments Off on Ubiquity

Cloud Computing

I’ve recently heard/been involved in a lot of discussion around the concept of cloud computing and whether or not there is an impending evolution/revolution around it. As such, I decided to put in my 2 cents.

Let’s get the punch line out of the way: cloud computing is coming…so deal with it.

Skeptics cite a handful of reasons why this is purely “hype” as opposed to the way of the future. Mainly the issues around reliability, accessibility, security, and performance. I’ll deal with each of these points individually.

Reliability is no doubt an issue currently. When one looks at sites like Twitter and the issues surrounding it, it is no wonder that this is a major concern of the skeptics. It’s important to remember, however, that we’re in the early stages of this transition. Looking back on the initial digital revolution the computers of the day weren’t very reliable either. Computers would crash and lose the active document, hardware would fail losing all the documents on the computer, and we still constantly face issues around viruses and data corruption. As time has gone on, however, we’ve found solutions to most of these problems. Word (and many other applications) have periodic auto-save and document recovery features, software has gotten more stable over time, hardware has built-in monitoring to warn of pending failures, and anti-virus has matured while data-redundancy options have begun to go mainstream. Similarly, the reliability issues around cloud computing will evolve over time. The network will become more reliable, the individual sites will be held to a higher standard of up-time, and data redundancy will become a trivial task built in to the libraries the applications are built on top of. There are possible early examples of this already available using solutions like Amazon S3 and Google AppEngine that aggregate the needs of many applications to take advantage of economies of scale. As the cloud computing applications mature and become more wide spread the issues around reliability will diminish until web apps are no more or less reliable than their desktop counter parts.

Accessibility is another commonly cited example. What will we do when we don’t have access to the internet? How will we use these applications? My answer to this: A long time ago, we didn’t have laptops. Instead desktops (and their corresponding data) was trapped in that single location on that single machine. As the technology matured we got cheaper desktops that we could buy for personal/home use and laptops that we could take with us anywhere. This freed users to use their applications wherever their hearts desired. It’s easy to see that internet connectivity is getting more and more wide spread. Wifi is everywhere and access to cellular networks is filling in the gaps. As this trend continues it’s easy to see that internet connectivity will one day be available wherever electricity is available (which we often take for granted now). In the transition, however, we’ll continue to see development around projects like Gears that allow users to take their web app experience offline and re-sync when the internet becomes available. Accessibility is an issue fading fast and will fade even faster as the trend continues.

The issues around security are real and worth noting. Having data accessible via the internet means it’s accessible to everyone on the internet if the proper security isn’t in place. Although the internet isn’t exactly built for security there have been huge leaps in this area over the last few years. As encryption becomes more prevalent and new systems of multi-authentication become widespread we’ll see many of the same types of security issues we’ve faced with laptops come and go in the web space. Ultimately many of the security issues will come from user-error and social engineering, not software failure. While this is significant, it’s important to note that these same issues would be faced on a traditional desktop application and/or even pre-digital revolution data storage (old school papers and files). The biggest holes in security will continue to be in the people accessing the data, not the systems in place to protect it.

And lastly, performance is a commonly mentioned issue. Web apps have a reputation as being a bit slow and clunky. This mostly stems from the fact that these applications are built in JavaScript which is a powerful, but dated system. JavaSscript is interpreted, which makes it run much slower than compiled counter parts. As the technology matures, however, we’ll see the same trends we saw in the desktop space: initially the improvements will come from clever programmers and minor improvements in the processing of the code itself, but over time the hardware improvements will out-pace the software changes allowing the same applications to run faster on the new hardware/platforms (in this case it’ll most likely be a combination of hardware improvements and browser enhancements). The performance woes will subside as we see the line between the client and the server blending (as made possible by the technical enhancements previously mentioned).

In summary, although there are some real issues around the current state of cloud computing many of these issues aren’t all that different than the issues we faced in the initial digital revolution. And, just like in the previous revolution, these concerns are far out-weighed by the advantages of the cloud computing model. The accessibility of having your data and your application available from any internet enabled device is very powerful. Add to that the advantages of direct, digital distribution (software updates are seamless and immediate…dramatically lower distribution costs as everything moves to digital downloads) and you’ve got a real force behind this movement. Watch for clients to become simpler, more prevalent, and the emphasis to move more to form factor and usability as opposed to power and performance.

The cloud computing revolution is coming…might as well embrace it.

Posted in General | Tagged | 1 Comment

Communication

I tend to put a very strong emphasis in my life on efficiency. I strive to squeeze as much productivity out of my time as possible to allow me to get more done and have more time to do other things I want to do besides being productive. In general I’m very happy with what this has allowed me to do in life. I get a lot done and am able to still keep my sanity (well…most of the time at least). This mindset, though, does have its drawbacks at times. One thing that I definitely give up is a degree of communication.

In my efforts to remain productive, I often keep my communication short. Emails are often a couple sentences at the extreme, project descriptions are brief, and overall my communication style is narrow and to the point. This can be a good thing in moderation, but at the extreme can lead to problems. Sometimes I end up writing more than I would’ve at the start because of a misunderstanding due to my brief correspondence. Other times my emotion or prioritization of items is lost in the brevity of my replies. In any case, the problem is that in some situations I end up under-communicating, and these issues end up decreasing efficiency because of the problems that arise from them (as well as annoying my friends and coworkers who are left confused).

It’s been said many times that one can’t find the limits of something without pushing one’s self to them. I think in this case I’ve gone past the limit a bit, and I believe it’s time to swing things back in the other direction. As such, I’m going to try a different approach for a while. I’m going to write a few extra sentences to get my point across, repeat myself if I think it even might be necessary, and sometimes go so far as to ask questions to ensure comprehension on both my part and the part of whomever I’m speaking with. In short, I’m going to try what I would describe to be over-communicating for a bit to help find the most appropriate level in order to balance my determination for efficiency and productivity with the ability to properly communicate ideas and emotions with my friends and coworkers. An interesting experiment if nothing else…

No matter what shakes out of this, though, it has certainly brought to light for me the value and importance of communication. Whether it’s between coworkers, friends, or a significant other, without good communication you’ll end up confused, unhappy, and feeling repressed. As important as I deem productivity to be, it can’t come at the cost of your relationships. Communication also helps to lead to better team (as opposed to personal) productivity. Although it might slow me down a little to spend extra time explaining something more thoroughly, it might save the team as a whole a significant amount of time as everyone else is much more clear on the problem and/or potential solutions.

Do not undervalue good communication skills, and take the time to properly communicate your thoughts/emotions with those around you. Communication is too important to be ignored.

Posted in General | 9 Comments

Privacy: where’s the limit?

I don’t think anyone can disagree that privacy is starting to become more and more rare. It’s an interesting evolution as we make more and more of ourselves public and freely available. There are already strong differences between generations about where the limits on privacy should be. For example, many people in my generation have no problem having their cell phone # on Facebook or their street address available on the internet. Many new services continue to break down these walls. Location based services like BrightKite post our current location to the internet and even keep a running log of where we tend to be. Profiles on social networks continue to collect more and more information about where we live, what we like/dislike, who we associate with, and where/how we work.

The trend of diminishing privacy is clear and definite. The question in my mind is how far can this be pushed before people start to push back? What are the long term ramifications of this new open lifestyle?

Some of the edge services coming out in this area include digitizing our health records. With sites like Mint.com are we really that far away from making even more of our financial and bank records public? This could have many long term ramifications if the trend continues. For example, imagine the change for potential employers. Already they can Google you and look you up on social networking sites like Facebook to get a feel for how you spend your personal life. What if they could find out your financial status and health records as well? They could determine your salary based on how desperate you are financially instead of purely on your merits and the job market. Employers could pick the healthiest employees to try to avoid the impact of major health issues on the business. This also starts to play into discrimination a bit. How do you defend against financial and/or health discrimination? Can you? Should you?

The level of privacy continues to degrade over time, but is there a point where society pushes back? Or instead, is the slow evolution completely imminent and uncontrollable? Continually dropping with each new generation…

Posted in General | 2 Comments

Life without Google

I had an interesting discussion with Josh Fraser tonight during which a frightening proposition came up: how would your life be impacted if Google went away tomorrow? Now before you blow me off and say “I’d just use Yahoo!”, I’d like to encourage you to think about it in the broader sense of: what if we didn’t have a nice search interface to the internet?

It’s hard for me to imagine such a world, but it would definitely impact my life. I use Google dozens of times a day to look up functions, answer questions, and even spellcheck words I’m not sure about. It allows me to not have to keep reference books at my desk or keep a long list of bookmarks of sites with helpful tables of code. I even use Google as my calculator occasionally.

Often many people of the generation before me look at my generation’s dependence on the internet at large (and Google in particular) as a sign of the diminishing intellect among our youth. I couldn’t disagree with this notion more, however. The internet is a tool that frees our brains from having to memorize mindless trivia, remember hundreds of rarely used functions, and provides a seamless interface to a huge pool of knowledge. This allows us to become even more specialized in our thinking and spend more of our brain cycles solving problems as opposed to memorizing data or doing research. Not to say that we don’t still do research, but the process has just been immensely simplified.

I think of the internet as a tool…a base of knowledge “in the cloud” that is at my fingertips and frees my mind from having to remember some of the more rarely used bits that people of previous generations might’ve kept in their heads. Does this make us stupider? I think not, but I’m sure there are those out there that will disagree. The question still remains, though, how has the internet’s depth of knowledge and simplistic search interface impacted your life? And how would it impact it if it were suddenly gone?

Posted in General | 5 Comments

Todo lists

Todo lists are a surprisingly effective tool that are often undervalued (especially by young folk like myself). Those of you that know me well (especially those of you that knew me in college) know that I’m somewhat overly concerned with efficiency. I often strive to find ways to squeeze out just a little more throughput in my work day. One of the simplest tools for this is a simple todo list. I know that right now half of you are saying, “Yeah, of course…”, and the other half of you are rolling your eyes thinking about how useless this blog post is. I’m writing this post for the latter group (so please roll yours eyes back into position and continue reading)…

Those of you that haven’t actually tried todo lists are probably thinking the same things I used to think about them:

  • I don’t need to write it out…I know what I need to do
  • How does writing it down make me more efficient…doesn’t it take longer because you have to make the list as well?
  • What extra value does this list really create?

However writing out your daily list has many benefits that are often under appreciated. Here is just a sample:

  • Writing out your list forces you to think through (at least at a high level) all of your tasks
  • Often it forces you to come up with at least some type of rough prioritization of your tasks
  • Allows you to free your memory for other, more important, stuff
  • Keeps you moving rapidly as you never have to stop and think of what’s next to do…this allows you to stay in the zone when you get there
  • Allows for a strange sense of satisfaction when you cross items off the list…it’s weird just how satisfying this can be

If you don’t already keep a todo list for yourself I would strongly encourage you to give it a try. It might just surprise you how much more productive you can be with such a simple tool.

Posted in General | 1 Comment

Tips for TechStars Teams

Admittedly many of these are applicable to all startups, but I target the TechStars specifically because of my own experience with the program. This is also partially in response to Rob Johnson’s post where he calls out to me (among other previous TechStars) to share our advice to the new class. So, onto the tips…

1. Delegation – I can’t stress this one enough. Make sure that there is as little overlap in responsibilities within the team as possible. Also, just as importantly, make sure everyone knows their role. In our experience I ended up with a hand in just about everything we did as a young company. I attended every session, every meeting, and worked on every aspect of our project. Part of the reason in my case was situational, but in general I would highly stress that people should break up into at least two camps: the product/project and networking/business. Try to be as firm in this regard as possible, if there’s a session/meeting about Amazon and infrastructure then send the product/project people, but if it’s just about the best corporate structure for startups you probably don’t need to send them. The business/networking people should spend their time finding key mentors and building these relationships, while the product/project people need to be cranking out code as fast as possible. There is a lot of opportunity in a very short time, and the best way to capitalize on the experience is to divide and conquer.

2. Get your product out there – Even if this means releasing a product with an extremely stripped down feature set I think it’s extremely important to get something out as soon as possible. You’ll have tons of people around to give you feedback and help to build out the product and you want to use them as much as you can. It’s a lot harder to get feedback on an idea or a screenshot than it is to get feedback on a working (even if it’s only “working-ish”) product. You’ve got mentors, other teams/startups, and (hopefully) some early users all with plenty of helpful feedback that can save you a lot of time in the long run and overall make your product better. I would encourage stripping down the feature set instead of cutting back on quality and working around a prototype that finds its way into production. This is one area that I think we missed the mark on, trying to do too much too fast instead of perfecting a smaller feature set from the get go. People in general seem to have more tolerance for “we’re still young and that’s not done yet” than for “we’re working on fixing it”.

3. Don’t try to connect with everyone – When you’re working in a startup, if you’re lucky you’ll have tons of opportunity to connect with some really great people. In particular, in the TechStars program there are plenty of really amazing mentors that are all available at your fingertips. It is important, however, to remain focused and not try to connect with every single person. Instead, find a handful of mentors/people that you respect the most and that can help your startup succeed and focus on them. With relationships in general, quality over quantity is often underestimated. This is exceedingly true with mentors to early stage startups, as the level of attention and help is key.

4. Force feedback, and don’t take it personally – This one can be tough for people, but I think it’s very important. As you work your way through the startup, be sure to ask the people around you for feedback periodically. In particular, look for negative feedback. Positive feedback might make you feel good, but the truth is the negative feedback is much more valuable as it provides a plan for improvement. Be sure to ask the people you respect around that you respect the tough question: “What do I/we suck at?” Sometimes it’s tough to get a truly honest response to this question, but you can’t take it personally. Just focus on assuring that you understand their criticism, deciding if you agree with it (most likely you should), and finding the best method to address the issue. Improvement over time is an important characteristic. Most people won’t hold failure against you as long as you learn from it.

5. Know what is a competition and what isn’t (and act accordingly) – When we first got into TechStars we saw ourselves as competing with all the other teams. I think part of this was seeded by David and part of this was just that we didn’t know what to expect, but we definitely all learned over time that in general, we’re not competing with the other teams. In most cases the startups are different enough that competition is unnecessary. Instead, leverage the other teams for feedback, advice, and networking…you never know who will end up making it big. There are times, however, where there is a bit of a competition. The biggest examples of this in my mind are demo days and investor day. In these situations you’re fighting for the attention of the crowd which puts you in direct conflict with the other teams. You want to make sure you’re the one that is remembered. This can be hard, but be sure not to be caught blindsided by this. Have a plan and execute it, but don’t go too far; after the event you’re no longer competing, so be sure not to burn any bridges.

So that’s my list of tips (for now). Hopefully someone will find these helpful and can learn them from my short comings instead of going through them on their own.

Posted in General | 7 Comments

Those dreadful early decisions

One thing that is widely known already, but deserves to be restated for everyone that thinks they understand it is that the quick and dirty, seemingly meaningless decisions that you make when you first start designing/building a website are going to be greatly magnified throughout the life of the company. I run into little things constantly that I wish I’d just thought through a bit more carefully in our early stages that would’ve been a quick fix originally that are now an annoying problem to resolve because it’s grown overtime.

I think there is a delicate balance, especially in the earliest stages of an application, between speed and just getting something out the door (there definitely is such a thing as over-analyzing a problem) and thinking the problem through and looking at the long term perspective to prevent a series of “gotchas” in the future. I certainly still haven’t mastered this balance, but what I am learning is a couple of (now obvious) clues as to what should be more thoroughly thought out and what should just be cranked out and refined as time goes on. So what are the clues?

  • Anything involving the database should be thought out very carefully…and then thought out again. Changing the database schema after you’ve grown a bit is certainly possible, but is a nightmare of a thing to do. The application often ties so tightly to the database architecture that even relatively minor changes can be a major pain to implement down the line.
  • Core processes (anything done many, many times on your site) should get a bit of extra foresight as well. Anything that happens constantly will generate large amounts of data which is always hard to fix in the future. Also, if it’s not well thought out you’ll probably run into scaling issues and the like down the line – a little time spent early on can save you from a nasty bottleneck 6 months later.
  • Data collection and standardization definitely should get some extra cycles. Exactly how you store url’s (to normalize for inconsistencies) for example is something that is much easier to solve once, carefully, than to have to modify several times to ensure accuracy down the line. Any time you end up collecting large quantities of data, you want to be 110% sure you figure out the way you want to store it (including what it will be down the line). Having to modify large collections of data multiple times is murder on your server and extremely risky (playing with data always is). Save yourself the stress and figure this out from the get go.

  • In contrast, the UI of the site is something that should be cranked out relatively quickly. I’m sure some will disagree with me on this point, but what I’ve found over and over again is that what we think is the best way is never really the best way. The UI is something that should be constantly tweaked and iterated over to give the user the best experience possible. It’s very, very hard to plan out the best possible UI on day one, but your users will help you figure this out along the way. Let them, and don’t waste all your time on this up front since you’re just going to change it every 1-3 months anyways.
  • Formatting and copy (text) of the site/product should be done extremely quickly early on. Obviously you want to make your product usable from the beginning, and appropriate, understandable text is important to that, but this is so frighteningly easy to change that it’s just not worth all your focus up front. Instead, make sure it’s clear enough that it’s usable and then build off of the feedback of your user base a couple months in to clean it up and refine it.

So a quick summary would be that anything involving data, the database, or a core process should be handled with great care, but things like copy text and UI should be handled more iteratively instead. When phrased like this it seems completely obvious, right? Yet somehow in the moment it just doesn’t seem this cut and dry. Hopefully this will help someone else out there to make sure they spend their time on the right early decisions and prevent some headaches down the line.

Posted in General | 9 Comments

Mod Rewrite Tip

Just a quick mod_rewrite tip for everyone out there. I spent a little time today working on some rewrite rules for an upcoming feature on IntenseDebate. I didn’t realize before today, however, that query parameters are not part of the expression matching in mod_rewrite. That is, http://www.domain.com/url/param1/param2?abc=123, will stop matching after param2 in this case. When you think about it, this makes a lot of sense really…unfortunately I didn’t realize this until I spent a good 30-45 minutes in frustration wondering what was wrong with my regular expression. If you do want to do something with the query parameters you can access them by using the variable %{QUERY_STRING} in your script.

Hopefully this helps someone else out there.

Posted in Code | Comments Off on Mod Rewrite Tip