(760) 483-3759

1 week before Unshrinkit was about to go on Shark Tank, Unshrinkit’s CEO Des Stolar reached out to me to ensure their website was prepared for the impending Shark Tank traffic spike. Websites have been known to crash at the peak of server traffic, right when businesses should be cashing in on sales, so this was critical to their business, and mine.

Assuming your website is ready and fearing changes by proverbially “sticking your head in the sand” aka “ignorance is bliss” and not taking action is the worst thing you can do for your business. Being proactive and engaging with your trusted advisors such as your web developer to seek their input as early as possible is the best thing you can do.

  • If the website crashed, I’d feel guilty and ruminate that I should have done more. Especially if they were offered a deal by the Sharks, and their failure to capitalize on the show’s publicity caused them to pull out of the deal, so a lot was riding on this.
  • If it held up and propelled their business onward and upward, it’d be a great boon to my business to say we helped a Shark Tank success story and attract like-minded business owners.

I literally dropped everything – just ask the 10 or so clients who tried to reach me that week, I had blinders on focused until I felt Unshrinkit was 100% settled and ready to rock it. But I knew in the back of my mind that those clients would understand, and I would be able to use the experience gained in turn to help their businesses in their time of urgent need too, so win-win in the long-run.

Des asked me to check:

  1. Her choice in hosting upgrade, from HostGator shared server to Optimized Managed WordPress (which is a different offering within HostGator)
  2. The migration, content, plugins, code etc
  3. UX and SEO
  4. DNS
  5. Security and stability of the site
  6. Backup plans in case the server did crash

While on the surface the site looks just fine, since we had worked on it a few months ago, I also gave her a complimentary conversion optimization review to ensure every little tweak that could be made in Unshrinkit’s favor on the website was brought to her attention to help convert potential visitors into sales, before they leave the site.

I mentioned that even a small increase in conversion rate multiplied by a large number of traffic, would translate into a meaningful increase in sales. This included tweaks like:

  • Buy button color: from dark to orange (more attention-getting)
  • Picture quality
  • Color-contrast for readability
  • Font and alignment
  • Copyright auto-update
  • An abundance of contact options including a third contact us under the Learn More menu and a instant chat option
  • Contact form that “pipes” to their corresponding team member based on the visitor’s drop-down selection to load balance messages across her team of 3 people
  • The way the site looks in Google by updating the on-site SEO, setting up Google Webmaster tools and pinging updates
  • The way the site looks when posted to social media like on Facebook with the picture, title and description, as it was loading an out of date image and no description (I later fixed that and tested it with the Facebook debugger)
  • Adding an “As seen on Shark Tank” logo to their site to confirm visitors are in the right place and add credibility
  • Checked mobile responsiveness and the Google mobile friendly test

However, once I started working on the site, there was an even bigger that was apparent… the site was still too slow to update and reload.

With varied home page load times between 2 seconds to 7 seconds with mostly just me on the site at the time, I thought, how could the site possibly handle tons more people at once? It couldn’t, it would crash for sure, so I was in fear and panicking. I optimized the heck out of the home page, reducing it from 15MB (there were lots of large pictures I had to Photoshop) down to under 10% of that, around 1.4MB. Yet still the site load time was slow and varied. Then my lead developer and I combed the theme and plugins looking for a possibly cause. We fixed one 404 error and deactivated or removed several plugins, yet still the slow and varied load time persisted. At times, I also saw in the Chrome browser status bar Waiting for socket, which is NOT a website problem, that’s a server problem. Damn you HostGator (many other web developers concurred HostGator is the worst). I worried and concluded, we’d have to move the site again. Fortunately, there was just enough time being a few days before the show aired.

When I went into HostGator to check out the server and contact support, I noticed a red warning message in CPanel saying a script was disabled due to a CPU spike recently:

After talking with support, I came to find out this was on their prior shared server, not their new one. Des had later informed me her friend did voluntary security testing, without coordinating with us or HostGator, which caused HostGator to shut down the script. I also submitted a support ticket asking HostGator to investigate the load time issue, and they didn’t get back to us even days later, but I didn’t wait, I had enough and was ready to move the site again.

I reached out to people smarter than me in various groups and asked them for advice. I spoke to one guy, David, who also had a client on Shark Tank before. He said he recommended LiquidWeb for their speed and support. I like that they have 24/7 support, something I also like about GoDaddy’s support, because I also work 24/7 and don’t want to wait when I have an urgent issue to resolve. After consulting David and LiquidWeb, I choose their Managed WordPress VPS Agency package, which has 8GB of RAM, which I learned is important for processing pages in short term memory. This was around $200/m.

Another recommendation was CloudFlare. I simply said to Des the higher the level, the more speed and security you can get, with options at free, $20/m and $200/m. Des got their Business package, which was also around $200/m.

We had moved the site to the LiquidWeb server through CPanel and the site was performing much faster consistently. Then I re-started making site updates, and we noticed, that some of the CSS changes weren’t updating. I asked LiquidWeb (LW) support to investigate. They said they didn’t know why and the website should have been set up in another way through their Managed WordPress system to get better support… UGH. So like 12 hours later, they finally moved the website within the LW server. Still, the CSS changes weren’t happening. I looked at the stylesheet for the CSS change I was trying to make and noticed “pagespeed.cf”. I assumed cf meant CloudFlare. So I turned off CloudFlare, yet still, it was showing up. So I Googled it and discovered that it was coming from mod_pagespeed. “mod_pagespeed is an open-source Apache module created by Google to help make the web faster by rewriting web pages to reduce latency and bandwidth.” Yet as the title of this Stackoverflow page I found states Pagespeed caching css, annoying to develop, it is indeed annoying to develop with, because flushing caches I had control over didn’t flush that to show updates. So I asked LW support to turn it off. Then CSS changes did in fact update, finally. With CSS updates working now, I could get back to updating the site.

One important change I made was beefing up the contact page, to incorporate piping, meaning based on the visitor’s selection, the email would route to a different team member, adding in a Press Inquiry selection, and also adding and configuring the Flamingo plugin to store emails on the server as well as a backup in case of email failure, since their Zoho email was under DDoS attack earlier in the week and the server/DNS changes caused the mail to go down sometimes. These changes meant I had to redesigning and recode the contact page.

In the web developer uGurus bootcamp I’m in, I was excited to announce that I got the site loading in under 1 second! Then our small group leader Sheldon had commented that the site should be loading in a tenth of that! I was shocked thinking how is that possible considering that a server ping alone takes just under a tenth of a second alone without any website data. I later found out he meant the first byte. But he also commented saying that loading ~100 requests were too many and to also get that down by disabling unnecessary files from loading. I asked him how that could be done in WordPress, and he didn’t know. So I asked the Advanced WordPress Facebook group if there was an easy way to selectively disable plugins per page, insisting that there must be a plugin for that (kinda like Apple would say There’s an app for that.) And eventually someone chimed in saying there is, Plugin Organizer. After I figured it out, I created a quick walkthrough video tutorial video showing how this works:

That reduced scripts loading from plugins like Contact Form 7, on all pages other than the contact page. Switch it off site wide, switch it back on on the contact page. Easy enough. Then I did the same thing for other plugins too.

Another plugin I tried adding was Unveil Lazy Load, which only loads images when they’re in the viewport, meaning when they come into view on the screen. Just like how Google Images and Bing image search works. So if a visitor only views the top half of the home page then clicks a menu item or button, the images below that aren’t loaded, saving bandwidth and load time. Although I switched this off after Des commented some images weren’t loading on her side, possibly due to a slower connection, so I thought maybe I should let the images load for people with slower connections or mobile, whereas I have Verizon Fios (fiber optic) so everything is snappy.

Brad from the WP FB group also gave me some code to add to prevent loading items like emoticons/emoji scripts and to remove version numbers at the end of scripts preventing caching, which I dropped into the child theme’s functions.php file. That further reduced requests and page size.

With everything anyone could think of set, then I configured CloudFlare for speed:

  • Auto Minify CSS (left off JS to prevent problems)
  • Polish strips metadata and compresses your images for faster page load times.
  • Mirage image optimization will help speed up loading of images through three key attributes:
    1. Mirage will analyze the type of connection and device the visitor is coming from, which helps optimize the image loading experience based on network and device connection.
    2. Mirage will virtualize the images, so a visitor on a poor connection will get a smaller version (lower resolution) of the image until the customer is back on a higher bandwith connection (high resolution).
    3. Streamlining requests into one. Instead of sending multiple requests for all of the  images on the site, Mirage will pull this into one request so visitors can start experiencing the images immediately.
  • Rocket Loader: Improve load time for pages that include JavaScript.
  • Always Online: If your server goes down, CloudFlare will serve your website’s static pages from our cache.
  • Page Rule: to cache everything *unshrinkit.com*

…and security:

  • Geolocation Challenges: for 56 foreign countries known for hacking attempts per past log records on client sites
  • Web Application Firewall: Set rules to protect your website from web vulnerabilities.
  • OWASP ModSecurity Core Rule Set: Covers OWASP Top 10 vulnerabilities, and more.
  • SSL: Full

SSL was also turned on at LW:

“The SSL certificate is to validate to end users that they are actually receiving data from the correct server. This will not impact loading of content, nor negatively impact the server’s interaction with CloudFlare.”

Even with everything turned on at CloudFlare to keep the site up, Murphy’s Law kept popping up throughout the whole week of preparation, and the website AND CloudFlare.com went down globally at 1am the night before the show. The incident report said said “Due to a route leak from a transit provider a large portion global traffic was routed to our South America PoPs”. Fortunately, CloudFlare.com came back up, and I could go in and switch it off to use LW’s servers until CloudFlare was restored.

With umpteen panic attacks averted, the website was finally all set and functioning correctly, a day before (Thursday) the showed aired (Friday 9pm 11/13/15).

With everything anyone could think of set, here’s how fast the site loads now:


  • Disregard the performance grade, as the worst offender was “Parallelize downloads across hostnames” but it was distributed on CloudFlare’s CDN, so not worried about that
  • Requests were down from 101 to 78, a 23% drop
  • Load time was down from 6.46 seconds to 408 milliseconds (0.408 seconds), a 94% drop in load time 😀
  • Page size was down from 15.2MB to 1.4MB, a 91% decline
  • And the easiest tell tale sign of all “Your website is faster than 98% of all tested websites” which Des loved to hear 🙂

After all of this preparation, Des called me about 2 hours before the show was about to air, saying it may not, due to the Paris attacks (again, Murphy’s law at play here). But the show did go on…

Show Time

During the show, everything was a success: Unshrinkit agreed to an offer from Mark Cuban for $150,000 for 15%, and the website performed flawlessly. Here are some stats:

  • Active users concurrently I saw in Google Analytics was over 1,900
  • Most in an hour per CloudFlare was over 5,800
  • Total unique visitors for the day was over 10,000

Check out this traffic spike:

The first spike is when Shark Tank aired concurrently on the East Coast and Central. The second spike 3 hours later is when the West Coast aired.

The CloudFlare cache was doing most of the work:

Pretty surprising to see GBs of bandwidth being used considering the home page size is only 1.4MB. But the visitor volume really adds up.

Again, pretty surprising to see hundreds of thousands of requests when the home page size is only 78 requests.

Furthermore, their top page in Google wasn’t even the home page, it was a lighter inner page, their product page:

Here’s the stats on that:

Fewer requests and much smaller page size than the home page. The load time varies in a small range sometimes for a variety of reasons such as the AdRoll and Zopim chat code responsiveness out of my control, but still fast under a second.

Even the day after the show aired, possibly due to replays, news, DVR, social media shares etc, the site traffic continued to be strong:

  • Thursday to Friday: 328 to 7,251 = a massive 2,211% traffic spike
  • Thursday to Saturday: 328 to 5,997 = a 1,828% spike over the day prior airing to the day after airing
  • Friday to Saturday: 7,215 to 5,997 = only a 17% decline the day after airing compared to the day of airing

Also the night during the airing, I thought to turn on outbound click tracking (via an option in the Google Analytics Dashboard plugin) since the sales are completed at Amazon. Based on the data the day after for a fair estimate, it appears that 35% of visitors clicked through from the website to Amazon.

From there Des said on Amazon “we maintained our usual sales conversion rate of about 20-25%”.

Sales estimates equate to:

  • Traffic over 2 days = ~13,000
  • x 35% outbound click rate to Amazon = 4,550
  • x 22.5% (avg. of 20-25%) = 1,023 bottles of Unshrinkit sold just through the website
  • x $12/bottle = $12,285 in sales
  • @ $7 profit margin/bottle = $7,161 profit in 2 days; $3,508/day

Pretty nice for some quick sales. Plus they got a heap of messages for additional online and offline retail channels for long-term, on-going sales. Fortunately I had installed Flamingo, because they weren’t getting the emails through the website, even though every test I did before and after worked to my email, so must have been a Zoho problem.

The biggest lesson from this experience: Murphy’s Law WILL happen (it’s a law, meaning it always happens) “What can go wrong, will go wrong”, so have multiple redundancies for EVERYTHING:

  • Contact methods: contact form to email, WordPress saved messages too, chat messaging, social media messaging, multiple email accounts with different providers (i.e. Zoho and Gmail), etc.
  • SEO: update the site, and instead of waiting for the Googlebot to come back, ping changes through Pingler.com too
  • Servers: LiquidWeb and CloudFlare backing each other up, plus back-ups on my (soon to be discarded) HostGator server

Now I’m on a hunt for more businesses with websites about to go through a traffic spike or product launch, as well as businesses seeking on-going online marketing and website updates, as my team and I can bring all of our experience, resources and tools to the table to be a small but significant part to their success.

For questions, comments or inquiries, contact me.