“I want to go fast – Ricky Bobby”

We live in a world of “instant”. And while this isn’t a new concept, we’ve gone from things like instant coffee and microwavable meals to instant messenger, video on-demand, same-day delivery, order ahead, and a list of instant services that continues to grow. The fact is that most people prefer not to wait, and if they have to wait for you, they’ll just go somewhere else.

It’s no different for people browsing the internet. Whether someone is passively browsing through articles, scouring reviews on a restaurant for dinner tonight, or shopping for the best deal on that toaster they want, they are not going to put up with a slow loading website. Why? Because a quick loading website provides a more pleasant, less frustrating user experience. According to a great infographic published by KISSmetrics in 2011, 47% of all users expect a website to load in 2 seconds or less. To complicate matters, this same expectation is becoming true of mobile users.

Does your website load that fast? If you’re not sure try running some quick tests on a free website speed test tool like Pingdom. If your site is not up to par, it’s not just a bad user experience; it’s costing you money.

How Poor Site Speed is Costing You Money

There are a number of factors and ways that a slow loading website could be costing your organization money. Let’s consider just a few:

Poor Site Speed Hurts SEO

Since 2010, Google has plainly stated that website speed is an important ranking factor in organic search results and overall SEO. Why? If you perform a search in Google and they return results that include slow loading websites, you are going to click on that result, and then bounce right back to the search results to try another one (this action is often referred to as “pogo sticking”).

Google Search is in the business of providing their users with results that are BOTH relevant AND provide a good user experience. If your website is slow to load, it won’t matter if you have great, relevant content. You simply won’t rank as a high in search results and thus you will get less traffic and need to supplement this through other paid strategies.

Decreased Conversion Rates

According to the above referenced KISSmetrics infographic, A 1-second delay in page response can result in a 7% reduction in conversions.

So let’s do a little math. Say your ecommerce site currently has a 2% conversion rate and that equates to around $50,000 in sales each day. If you were to improve the page speed of your checkout process by 1 second, you would earn an extra $1,277,500 in sales each year.

Reduced Customer Satisfaction

Think of the last time you went to a restaurant that had really slow service. There was an extremely long wait to be seated. When you finally arrived at your table, it took a long time for the waiter to come to your table. After putting in your drink order, they finally arrived some 30 minutes later. And the rest of the night continued in this fashion. Now reflecting on that experience, will you ever go back? Would you recommend that restaurant to someone else?

According to that KISSmetrics infographic, 79% of shoppers who are dissatisfied with website performance are less likely to buy from the same site again. And they are certainly not going to recommend your site to their friends via social media or word of mouth. Not only that, they’re likely to leave negative feedback or comments which will deter future prospective customers. There is no telling how much lost revenue this might result in.

Increased Operating Expenses

“Can’t you just throw more resources at the problem?” Sure! But it will cost you…

In some cases, it may be the right move to increase the number of web or database servers to your hosting environment. In others, you may need to add additional RAM or vCPU’s. But you might just be treating the symptoms and not curing the actual problem.

Your website might contain slow executing queries, functions or methods, and loops throughout the application that require optimization. It’s also possible that there are numerous notices, warnings, or errors being generated in log files that need to be addressed.

Before simply throwing more money at the problem, we’d recommend you having an experienced development team audit your site’s code first.

Simple Steps to improve your Site Speed

There are actually some simple things that can be done to improve your overall site speed that are often overlooked.

Advanced Ways to Increase Site Speed and Revenue

Beyond some of these simple steps, there are more complex solutions to your site speed problems. For example, websites that have a lot of dynamic or personalized content such as e-commerce and membership sites can pose challenges to efficient caching. Or, depending upon the amount of traffic your website receives, your codebase may pose challenges to scaling to support large amounts of concurrent traffic.

In either case, we’d suggest having an engineer review your website’s code to identify any inefficiencies or legacy functions that could be optimized. In addition, we’d recommend speaking with a strategist or UX engineer to look for opportunities to simplify and improve the user experience.

One thing’s for sure; site speed matters! If you’d like to chat more about ways to improve the speed and performance of your website, drop us a line. We’ll try to get back to you as quickly as possible 😉

Build tools and task runners were invented to prevent human error and make your life easier. They can bring you workflow nirvana, or cost you countless hours of aggravation and misery. There are quite a few options getting love from developers these days, so choosing your side can certainly be overwhelming — especially when new options seem to be popping up every day!

Everyone’s Got Choices

Which tool is the best fit for you and your project? The short answer is any of them. If you’re at the point where you’re trying to automate your process then you’re already doing something right, so good on you! The long answer, however, brings us to the battle between Brunch and Gulp.

Meet Brunch

Brunch entered the game in 2011 with two core principles in mind: keep it simple and make it speedy. It makes a few assumptions (see also: limitations) about your project, but in return it gives you an extremely simple project setup that runs incredibly quick.

Meet Gulp

Gulp is the “code over configuration” tool that won our hearts in the last showdown. It’s a super customizable tool with a pretty impressive plugin library that’s gained a lot of popularity in recent years.

Ready? Fight!

Both of these tools are great, but there’s definitely pros and cons for each. We’re going judge these on five areas of importance — documentation, configuration, community, customization, and speed. Best three out of five takes the cake! (The cake is a lie.)

Tell me something good (documentation)

Brunch has a detailed set of documentation on its site that will get you up and running quickly. The detailed explanations behind core concepts cover getting started, installing plugins, installing JS modules, testing, and deploying. It’s organized, the information is well explained, and there are little brunch puns littered throughout (bonus!).

Gulp’s documentation is it a little bit harder to navigate. Visiting the “Docs” section of their website brings you to some documentation that resides in their GitHub repo, but there’s also an entire readme.io version of the information that’s somewhat overlapping but different. Overall, it’s pretty extensive, albeit a little less organized than Brunch’s. Much like the other, you’ll find a section on getting started with Gulp, and some information on using the API and CLI. There’s also a great jumpstart guide for writing your own Gulp plugin.

Winner: Brunch (barely)

Start me up (configuration)

This is where Brunch really shines. It makes a few assumptions about your project (outlined here), but also makes setting up your project a breeze. A typical config for Brunch might look something like this:

module.exports = {
  files: {
    javascripts: {
      joinTo: {
        'vendor.js': /^(?!app)/,
        'app.js': /^app/
      }
    },
    stylesheets: {joinTo: 'app.css'}
  },

  plugins: {
    babel: {presets: ['es2015', 'react']}
  }
};

Conversely, Gulp makes no assumptions. You’ll need to tell Gulp everything about how it should run, but it’ll also be a lot more customizable this way. A typical Gulp set up might look something like this:

var gulp = require('gulp');
var coffee = require('gulp-coffee');
var concat = require('gulp-concat');
var uglify = require('gulp-uglify');
var imagemin = require('gulp-imagemin');
var del = require('del');

var paths = {
  scripts: ['client/js/**/*.coffee', '!client/external/**/*.coffee'],
  images: 'client/img/**/*'
};

/* Register some tasks to expose to the cli */
gulp.task('build', gulp.series(
  clean,
  gulp.parallel(scripts, images)
));
gulp.task(clean);
gulp.task(watch);

// The default task (called when you run `gulp` from cli)
gulp.task('default', gulp.series('build'));


/* Define our tasks using plain functions */

// Not all tasks need to use streams
// A gulpfile is just another node program and you can use all packages available on npm
function clean(done) {
  // You can use multiple globbing patterns as you would with `gulp.src`
  del(['build'], done);
}

// Copy all static images
function images() {
  return gulp.src(paths.images)
    // Pass in options to the task
    .pipe(imagemin({optimizationLevel: 5}))
    .pipe(gulp.dest('build/img'));
}

// Minify and copy all JavaScript (except vendor scripts)
// with sourcemaps all the way down
function scripts() {
  return gulp.src(paths.scripts, {sourcemaps: true})
    .pipe(coffee())
    .pipe(uglify())
    .pipe(concat('all.min.js'))
    .pipe(gulp.dest('build/js'));
}

// Rerun the task when a file changes
function watch() {
  gulp.watch(paths.scripts, scripts);
  gulp.watch(paths.images, images);
}

Winner: Brunch, if brevity is your thing

I get by with a little help from my friends (community)

Brunch currently has just under 100 plugins to its name, while Gulp has upwards of 2,800. The wide difference here may be due, in part, to the fact that Brunch gained NPM support somewhat recently. Gulp also went out of their way to make plugin documentation easily accessible for developers, which may have also been a factor.

For any questions or issues you might have, Brunch has an active online forum you can post to and Gulp has a similarly active IRC channel. Both tools have active participants in Stack Overflow as well.

Winner: Gulp

You can have any color you want, as long as it’s black (customization)

Brunch is relatively limited in this category. As we mentioned earlier, it simplifies the setup process tremendously by making some basic assumptions about the setup of your project. Unfortunately, if you’re project is exceptionally unique it might be quite a headache trying to customize Brunch to work with what you’ve got.

Conversely, Gulp really shines here. The configuration file is definitely more demanding than Brunch’s, but it offers pretty much unlimited flexibility. You can control just about every aspect of the task runner through the many options made available to you in the Gulp API and CLI documentation. And, of course, those 2,800+ plugins don’t hurt either.

Winner: Gulp

If you’re not first, you’re last (speed)

Both of these tools are impressively speedy. Brunch makes speed one of its top priorities, and it uses incremental builds by default to filter out unchanged files in concurrent build processes, which makes it hands down one of the quickest processes we’ve worked with. Gulp also has the option of running incremental builds, but it requires you to set it up that way. (You can see how to do that here.) Even without that setup, Gulp runs a pretty efficient process overall by using node streams to prevent the potential bog down from writing intermediary files.

Winner: Brunch

And the winner is…

Our favorite meal, Brunch! But not by much. Your choice here will really depend on what you’re looking for in your build tool. Brunch is definitely the simpler option to get set up quickly, and it works well for us here at Oomph. If you’re the type of person who likes to control every aspect of your build or you have a really complicated and customized project setup, Gulp is probably the better choice for you. At the end of the day, what really matters is that you’re automating your process. The tool you use can certainly have an effect, but doesn’t make too much of a difference — go do it!

If you’re working in an industry that handles information relating to health care, there’s a good chance your organization has strict security practices and your next website refresh won’t be as simple as discovery-design-build-ship. There are going to be a lot of checkpoints along the way relating to security and governance—all designed to protect patients and customers and ensure control and privacy of sensitive data.

Factor in security while planning the project timeline

As you work to map out the project timeline, you must be aware of critical, albeit time-consuming, tasks that are not tied directly to the development of a website project.

When budgeting for the new project, be sure to factor in the time it will take to collaborate with vendors providing services to secure your site. It’s likely that your technical team, responsible for the build, will have their hands tied when it comes to configuring things like firewall settings, access whitelisting, and DDoS protection, and it isn’t always easy to predict how much time vendors will need to process your team’s requests.

Prioritize Security Testing

There are typically multiple rounds of security and penetration testing that need to happen before your organization will sign off on launching a new project. The testing window needs to be planned in advance, and it’s always a good idea to notify your hosting vendor to make sure they’re aware the testing is taking place. That way, they can disable monitoring and avoid false alarms. Once your site passes security testing, it’s recommended that there be a code freeze—meaning no new changes should be introduced, unless another round of security testing is planned.

Build on a Safe Platform

The easiest way to launch a successful and secure site is to start with a framework that offers considerable security benefits out of the box. Drupal is an open source CMS that can easily support a high traffic site with complex features, and it has one of the largest communities of open source contributors maintaining it. Not only that, but there’s a <a href=”//security.drupal.org/team-members”target=”_blank” rel=”noopener noreferrer” title=”Opens in a new window”>dedicated security team that provides security oversight, announcements, and patches to keep the platform secure.

Secure Your Application

With your new project on a widely supported and secure CMS, you might want to consider further restricting access to administrative functions like content creation and editing. There are a few ways to accomplish this, and they can be layered together to ensure the CMS is protected from being defaced or otherwise breached.

Multi-factor authentication

The first and arguably simpler form of protection is to enable multi-factor (MFA) or two-factor (2FA) authentication. Many popular services you already use offer this level of security, and it usually works like this:

Multi-factor authentication works because just having a username and password is not enough to gain access to an application.

Content editing over VPN

Another way to protect your application is to prevent visitors from being able to access your site’s login screen to begin with. Normally, anyone can access your login screen if they know the path to it, which opens up your site to brute force login attempts. While it means your editors will need to jump through a few extra hoops to do their work, blocking requests to these pages will make your site more secure.

This configuration is more complicated than a multi-factor approach, as it requires you to have separate servers accessible only to users who have already logged in to a VPN. On the publicly accessible servers, the paths to login screens are blocked and inaccessible by visitors. This provides a great level of security, especially when coupled with multi-factor authentication.

Put a limit on login attempts

Out of the box, many systems don’t limit the number of login attempts a user is allowed to make. Preventing users from trying to login after a certain number of attempts, or limiting the number of attempts within a span of time is a good way to thwart attackers. Drupal’s Login Security module provides some configurable settings for how to handle failed login attempts.

DDoS Protection

Any site can be the target of a Distributed Denial of Service (DDoS) attacks, but often the bigger the site, the more likely it will be targeted with an attack. DDoS attacks overwhelm a site’s resources with requests from many locations at once, making it difficult to just block a single IP to stop the attack. Successful DDoS attacks will cause a site to stop responding to legitimate visitor requests and can quickly impact your business.

The simplest solution to prevent and monitor for DDoS attacks is to route traffic through a service that provides DDoS protection as a service. Often, these service providers offer additional benefits like static page caching to speed up your site, or rate limiting rules for specific pages.

Avoid server strain with rate limiting

Rate limiting allows you to throttle the number of requests to certain pages of your site, which can be especially useful for features like web forms that require more overhead than serving static content, and are often abused by spam bots.

A lot of vendors offering broad DDoS protection services can configure complex rate limiting rules to limit how many requests can be received by specific paths on your site. If your application offers an API, or if you have forms on the site that could be abused by an attacker trying to overload your site with malicious traffic, it could be worthwhile to consider rate limiting.

Wow, that was a lot to digest

There’s a lot to consider and plan for with large digital projects, and a lot of decisions need to be made along the way. The best way to be prepared is to consider security and other critical aspects of a successful launch early on and to work with a team you can trust to help with vendor selection and communication.

To work with a team that understands how to manage all of these solutions, please feel free to speak with us anytime.