Because .com Wasn't Available

This is cross posted on the Wayfair Engineering Blog A couple of weeks ago I ran a test with WebPagetest that was designed to quantify how much a CDN improves performance for users that are far from your origin.  Unfortunately, the test indicated that there was no material performance benefit to having a CDN in place.  This conclusion sparked a lively discussion in the comments and on Google+, with the overwhelming suggestion being that Real User Monitoring data was necessary to draw a firm conclusion about the impact of CDNs on performance.  To gather this data I turned to the Insight product and its "tagging" feature. Before I get into the nitty-gritty details I'll give you the punch line: the test with real users confirmed the results from the synthetic one, showing no major performance improvement due to the use of a CDN. Implementation Details:  Prior to this test we served our static content (CSS, JS, and images) from three domains: common.c...

When I was at Velocity  I heard about a quick and useful trick you can do with WebPagetest to measure the effectiveness of your CDN.  The steps are pretty simple: Test a URL on your site from a location that is far from your origin. Using the scripting tab in WebPagetest, point your CDN domains at your origin IP, and run another test. Compare the results, and see how much your CDN is helping you! Let's break this down for a Wayfair URL. Step 1:  Test a URL on Your Site Normally Since we only have our static content on our CDN, I chose a URL that has a lot of images on it, what we call a "superbrowse" page -  http://www.wayfair.com/Outdoor-Wall-Lights-C416512.html .  Since our origin is in the Boston area, I picked the LA node in WebPagetest to give our CDN the best chance of success.  To try and smooth out the results, I configured the test to run 10 times.  It also helps to login and label your test so you can easily find it later. ...

I've always enjoyed doing push-ups.  Okay, that's a lie - I used to hate  doing push-ups and I was pretty bad at them.  At some point in high school I had done enough that all of the little stabilizer muscles that are required for good form began to get built up, and they stopped making me miserable.  Once I got into martial arts they became a regular exercise for me, and I eventually came to like them. One summer in college I was off campus doing physics research, and I had planned on testing for my Black Belt once I got back from my program.  Black Belt tests are notorious for being extremely grueling, in fact I remember my instructor saying "first we physically exhaust you, then we try to mentally break you, and then we see if you actually know the techniques you are supposed to know".  I wanted to be prepared for my test, so I set a goal for myself to do 20,000 push-ups in the 9 weeks I had to train.  I didn't have much time to get to that goal, ...

This is a cross post from the  Wayfair Engineering Blog As we have mentioned before, the main source control system we use at Wayfair is SVN, with TortoiseSVN as our client. One of the things we love about SVN is the ability to add commit hooks, or checks that run when someone tries to commit a file to source control. By having a few key checks we can prevent bugs, ensure consistent coding practices, and generally have a cleaner codebase. The first commit hook we added was a PHP lint check. This means that when you try to commit a PHP file we run php -l on it from the command line, ensuring that the file has no syntax errors: Rejected commit due to a syntax error in a PHP file This might seem like a paranoid check, and you might assume that this kind of thing never happens, but with our ASP code (where we have no syntax check) we saw people committing files with invalid syntax on a semi-regular basis. Sometimes people are making the same change in a number of files and ...

Read it Later is an online tool and app that allows you to save the "one read wonders" that you find on the web for another time.  I use this service frequently, since I'm often checking up on Twitter or Google+ on my phone and seeing posts that I want to read, but that I don't have time to read at that time.  It's easy to add a URL to Read it Later and pull it up on my desktop at home.  Overall it's a great service, and free. When I started using Read it Later it had a really simple web interface, with no frills or fancy animations.  This made for a fast, but not particularly sophisticated product. Read it Later is currently trying out a new and improved web interface that gives larger previews of your articles (including thumbnails), easier navigation and action menus, better use of the available screen real estate, nice animations when you mark things as read, and generally a cleaner and more modern look (among other improvements). 

This is a cross post from the Wayfair Engineering Blog Progressive Enhancement is often described as an alternate approach to “Graceful Degradation” – it encourages focusing on the most basic functionality first and then building out from there.  It also forms the core of the Yahoo! Graded Browser Support model, which we use as a guide for our own rules around browser support.  This is an important topic, but it has been covered fairly extensively in other articles , so I’m not going to dive into it too much here.  Instead I am going to talk about specific progressive enhancement techniques we use at Wayfair to improve site performance. As you may know, there are some amazing new features in HTML5/CSS3 that make web development easier – rounded corners, drop shadows, gradients, placeholders in text fields, in browser form validation, etc., all of which reduce dependency on background images and JavaScript.  These are great features to have, but w...

This is a cross post from the Wayfair Engineering Blog One of the big changes at Wayfair recently was moving all of our storefront code (well, almost all…we’re still working on our sessioned code) from Classic ASP (VBScript) to PHP.  The company was started in 2002 and at that time ASP was a common technology on the web, and one that our founders were familiar with.  After 8 years of working with it, we had pushed it to the limits and decided we’d get more benefit out of moving to a new technology. Motivation for Switching While ASP is still in extended support, as a language it hasn’t been actively developed for a number of years (I tried to find out exactly how many years, but my Google searches were fruitless, which might tell you something).  It’s also a proprietary Microsoft language, so we were unable to make modifications ourselves, so any bugs we found were not getting fixed.  ASP’s age also means that there are very few companies using it...