The Next Scotch v8: How We're Getting to 1s Load Times

Celý článek

You might be wondering, "are they redesigning again?!" Whenever I'm asked that, my answer is always a resounding "OF COURSE!"

Sure the Scotch site is currently good enough, but there's always ways to improve. This next version is what v7 was supposed to become.

Some of the main features

• Fully cached pages (JAM stack-ish)
• Better discoverability (real-time search everywhere)
• Clearer site sections (Guides/Courses/Posts always confused people)
• More video content
• More community involvement

In this post, I'll dive into some of the main technical changes and reasons why.

Launch is impending (tm) (copyright).

The Problems with Scotch v7

Before we can design something new, we need to know where we come from. We have to identify problems and iterate on them (or blow them up). Otherwise, we'd end up with the same problems as the previous design. History repeats itself as they say.

Scotch is Slow Globally

In the states, Scotch responds quickly. We're hosted over at Digital Ocean in New York.

Our site audience is pretty global though. And those speeds are not as impressive.

Load time doubles when moving across the world to Mumbai. Unacceptable!

Also, first byte time for both of those are slower than Google's recommended 200ms.

New Site Numbers

Here's some early numbers on the new design (from Mumbai):

• Load time: 1.36s (down from 16.52s)
• First byte: 0.27s (down from 0.92s)
• First interactive: 1.06s (down from 8.19s)

Solid numbers! Really excited about that first interactive improvement.

Still early numbers and I still think we can improve. We'll talk about how we got to these numbers later in this post.

Finding Content is Hard (and confusing)

Our current site header:

We lost so many sections of the site. Bet you didn't know these existed:

• Guides
• Author's Section (Post Ideas)
• Newsletter
• Shop
• Forums
• Tag Pages (Angular, React, Vue, Laravel)

New idea for site header:

Ever since v7 launched, our pages/visit went down from ~3 to 1.3. Big loss there and we think this will fix it.

We'll have a lot more updates on finding new content when we get closer to launch.

Content Discovery Improvements

Here's a tease of what we're cooking up with real-time Algolia:

We'll be talking much more on design in the next site updates.

The State of Blogs: Era of JAM Stack

The JAM stack is a great way to build blogs these days.

• JavaScript: Get the data
• APIs: Provide the data
• Markup: Prebuilt sites from a site generator

Ultimately, what JAM stack meant to us was:

• Separate API w/ JWT authentication (easy enough)
• Separate frontend that hits API (not sure how to implement. keep current or move everything)
• Serve sites statically for crazy uber duper fast load times (not sure how to implement. keep current or move everything)

Blogs these days are becoming more and more static. Many blogs (including Smashing Magazine) have moved towards static-sites.

A few tools for static sites:

• Netlify
• Firebase
• Gatsby
• Jekyll
• Hugo
• Contentful
• prismic

I asked myself:

If we built a blog starting today, with the tools available, what would it look like?

I knew that we had go fully static. The question is how to do that?

• Do we move our entire infrastructure?
• Can we use what we currently have and create a static site?
• Two parts. Do we move the API? Do we move our frontend markup?

We decided that having a static site brought lots of benefits that we needed.

Going JAM and Caching Everything

This can't be underestimated at how much speed this brings, especially globally. If you never have to spin up a server, you can serve pure HTML for a request and speed things up greatly. No wonder so many are doing it.

We've seen this with traditional server-side setups by using Varnish and NGINX Caching. I tried that with the Scotch setup, but never found configuration easy enough. I don't consider myself a backend devops type person (hats off to those who can), so I wanted an easier setup.

The big problem with going to a fully static site is removing any server-side session usage. Our entire auth setup!

We had to remove any auth things in the view and handle that client-side with JWTs. Thinks less of this from Laravel:

@if (Auth::user())
  I am logged in!
@endif

And more of client-side JavaScript JWT auth.

if (localStorage.getItem('user')) {
  // render some stuff in that div over there
}

This leads us to the next point. Moving to a JWT setup means we got to separate backend API and frontend concerns.

Our Options Moving Forward

Here's our current setup:

• Backend: Laravel
• Hosting: Laravel Envoyer and Laravel Forge through Digital Ocean
• API: Laravel
• Frontend Views: Laravel Blade

As you can tell, we're big fans of Laravel. Going JAM meant we had to make API JWT authenticated and frontend views had to be API driven. Options were:

1. Total Loss of Control

Move our blog to a 3rd party. Medium, Ghost, WordPress, etc. Not for us.

2. Move the API + Frontend to JavaScript

This is the traditional JAM stack setup.

1. Move our content and API over to Contentful
2. Move the frontend to Angular, React, or Vue
3. Use a static site generator like Gatsby to generate our site
4. Host the statically generated site through Firebase or Netlify

Big architecture changes to go fully JavaScript. While tempting, there wasn't a compelling reason. The goal was to get to static sites. Totally achievable without changing everything.

We invested a lot of time into our setup and have some custom stuff. It would probably take a decent amount of time to move the API to Contentful or prismic. Also, that's another expense we'd have to take on monthly.

We're still a small team (Scotch is a side project for us) and want to stay as lean as possible. As few monthly expenses as possible so this option would've brought on two new costs (Contentful and Netlify).

3. Update Current API + Frontend goes JavaScript

We could keep our current API and have JWT auth. Really easy to switch thanks to Laravel. Then we build out the frontend in JavaScript, generate static sites, and then host statically.

This was something we really looked at. Ultimately, we wanted to see if there was something easier than moving the entire frontend.

Scotch Solution

With all these awesome new tools out there, what would be the best solution that got us a better site and got it fast?

The problem we faced is that we already have a solid backend built fully custom on Laravel with lots of custom features.

We decided to keep our current Laravel backend and API. We also decided that we'd use Laravel to serve our HTML but also add React on top for the auth things.

No need to go fully JavaScript frontend. Laravel for sites + JS auth vs JS static generated site + JS auth. Pretty similar in the end result.

Getting Static Sites

So how would we get a static site? Drumroll... we would let our good friends at Cloudflare handle that!

1. Update the current Laravel API
2. Update our views to have React dropped on top for only the authenticated parts (user nav, bookmark/like buttons)
3. Use Cloudflare to statically cache and serve the site

Easy Cheese!

Sometimes the best solution is the easiest. I know this solution came out of left field. It's essentially change as little as possible. I like to call what we've done "JAM Stack-ish".

It takes 5 seconds to switch Scotch to fully cached static pages delivered globally:

Cloudflare is amazing (not paid to say this). We even have a case study.

With Cloudflare handling the static site generation and us using our already existing API, we were able to switch to static pretty easily. The architecture change of switching from session auth to JWT auth was the biggest amount of work.

Since we had to redo all the auth, might as well redesign the site and fix our problems!

Recap and Up Next

So to recap, we went with minimal architecture changes. This only touched the surface on the new site. Here's what we'll be talking about next:

• How we improved content discovery?
• Making a better writing platform for coding authors (Dashboard updates)
• Improving tech blogs. Tech blogs have been the same. Let's make them better

This was a long journey learning about the current state of blogs and are happy with the choices we've made. This isn't to say that these choices will be right for your setup, but definitely weigh all the options. It may be tempting to move to the latest and greatest, but ask if that's really the best way forward.

Let me know what you think of our changes moving forward!