jeff hooton

What I Learned from Remaking the Same Website 12-18 Months Later

posted on jan 8, 2020


sage 9

In the fall of 2018, I was about a year into my web development journey, all of which was focused around Wordpress. My background in programming up until getting into web development was 100% native Android development. I decided to embark on creating something that, to be fair, was probably out of my league as far as complexity goes, and it definitely showed with my end product. The website,, was riddled with simple, avoidable errors that I couldn’t imagine making now.

Development errors I made the first time

  • Using a UI framework and jQuery slowed the website down to a crawl. In a world where your 40% of potential users are going to leave your site if it takes longer than 3 seconds to load, speed is always essential.
  • My responsiveness was all out of wack. I can’t tell you how many times I would scratch my head not being able to figure out why it was that elements would overflow the viewport. After finally fixing this I had probably added about 750 lines of purely media-query-centric CSS.
  • The design, absolutely terrible. I learned a valuable lesson in this though, either follow a design system, spend time learning enough design to put something halfway decent looking up or HIRE A DESIGNER/BUY A DESIGN. If you are as inept at design as I am, paying someone else to do it, or putting in some serious work to build minimal skill with it will pay off in the end.
  • Accessibility had never crossed my mind at this point. I didn’t put a single aria label on the entire site. I didn’t have tab indexes. Structured markup was out of wack for how a document should be structured. Contrast ratios were all out of wack and I definitely wasn’t passing any WCAG specifications for accessibility.

SEO errors I made the first time

  • Like I mentioned above, my site was slow as can be. I know this isn’t a direct ranking factor. But the thing is, if your user experience is crap users WILL leave and Google does not like sites with crappy UX as much as they like sites with good UX.
  • Duplicate H1 tags, unacceptable. Don’t make the mistake of having duplicate H1 tags.
  • Missing meta descriptions, make sure that every page you post has a meta description.
  • 404ing pages. Anything that ever indexes on your site should be redirected if you delete it or change the slug.
  • Broken breadcrumbs, if you are going to put breadcrumbs on your site, make sure they work.
  • No structured data. Schema is an easy-win when it comes to extra SEO that you can do for your site. Its the number one way that you’re going to pull featured snippets, and I can’t recommend adding appropriate structured data enough.

What has changed over the past year or so?

Over the last 12-18 months I have grown quite a bit, as a person and as a developer. I set out to change the direction and focus of my career around 9-10 months ago. My only web experience was working at a digital marketing agency in a support role as a Wordpress theme developer. My skills in web development were not just limited, but hardly constituted being able to call myself a developer. I switched up my focus to learning both front and back end Javascript. Vanilla for the front end at first, I had to push my abilities past being able to write emergency jQuery at some point, and then focusing on the framework React after that. On the back-end I focused on Node. I figured learning one web language at a time would be most beneficial for me. Being able to focus on the paradigms and syntax of one language at a time helped me learn at a much quicker pace.

Six months ago I accepted a position at a different company. This company was hundreds of times larger in terms of scale from where I came from. They also had a largely different focus than digital marketing, they were focused on creating great user experiences in web applications. The start of this job felt somewhat rocky for me, I was constantly plagued with imposter syndrome, but if there’s one thing that I’m good at, its rolling with the punches, adapting and learning QUICK. This was also my first experience working on an agile team that had all the facets of a production team. I had to have my code pass peer-review for the first time ever, and I also had to have it pass rigorous QA testing.

The rate I was growing at this new company compared to my last is incomparable. It also opened my eyes to a few key facts:

  1. Don’t shortchange your work, saying good enough is never part of my vocabulary any more. If I’m going to do something or write some code, I’m going to do it to the best of my ability and try to learn something along the way.
  2. TEST TEST TEST. Test your code in order to avoid headaches down the road.
  3. Design is not something you always have to take on. I have learned that I would much rather have/hire a designer than do it myself as the difference will most definitely show in the end product.
  4. Always be learning. You can never be good enough or know enough when it comes to development. Get out of your comfort zone and learn something new. It will have a direct impact in all other areas of your work.

The benefits of the changes

The most significant benefit that I found after going back and working on old code again is to not take shortcuts. Always do things the right way from the beginning as it will make your life that much easier in the end. Testing my code and making sure that it meets my requirements before I launch it is super important. It’s much easier to change code locally, and get it perfect(well as perfect as possible) before you deploy. Going back and changing things as a patch is going to be necessary sometimes, but it doesn’t have to be a regular occurance.

Branching out into other technologies, Javascript(React) and Node, gave me some new techniques in how I think about building websites. Instead of building pages, I went back into this project thinking more about reuse and componentization. I hate repeating myself, as I’m sure most people do, and being able to avoid doing so by pulling resuable components and logic out of specific pages really helps with this.

Working with a QA team, and really just a team in general, really helped with my code quality. I no longer ship bugs that I would have shipped 18 months ago. More often than not I now look at the website that I’m going to ship through the lense of the end user that is going to be experiencing the product that I ship. I’ll go through the entire site before I ship and make sure that it is something that I personally would use. If I wouldn’t use it, who will?

Optimizing for perfomance and abandoning all usage of a UI/CSS framework helped me be more efficient in what I’m writing, and the end product is smaller and faster. Over the last year I’ve become much better with using vanilla CSS and SCSS. I honestly prefer it much more this way. I no longer have to lean on the crutch of a framework to achieve my end goal. I can typically write code that will make something look the way I want it to, and if I can’t there is a good chance that I can figure it out given enough time.

Would I willingly use Wordpress again?

Now this is a tricky question. After being exposed to so many leaner, faster and more enjoyable dev experiences (in my opinion) it would be tough for me to willingly use Wordpress in its entirety again. Would I use it as a headless CMS to power a frontend of my choosing, sure…

Having experience with vanilla javascript, React, Vue, Next, Nuxt, Gatsby and Hugo leaves me with enough wiggle room to accomplish what I need to without reaching back in for Wordpress. I mean you’re always going to have clients that ask for a Wordpress site, or are familiar with the admin panel of Wordpress and therefor I don’t see it going away any time soon, I just know that it wouldn’t be my first choice when reaching into my toolkit to develop a new project.

The website now

Even though I had to go back and use Wordpress again due to a business situation and hosting restrictions, it is significantly better in many objective, and even more subjective, ways. It is fast now. The site loads on average 70% faster than the last build that I did. I’m hardly loading in any external dependencies, leaving out a bunch of bloat that I didn’t need in the first place. I’m no longer using jQuery and instead optimizing for vanilla javascript (down from around 6mb of js to right around 1mb). I abandoned using a UI/CSS framework, leading to a much smaller file size for style assets (from around 400kb down to 52kb). I don’t have any render-blocking javascript at all anymore. I don’t have any render-blocking css at all anymore.

The style and UX of the site is much better in my opinion now than it was from my build 18 months ago. I expect the conversion rate will be significantly higher than the 1-2% I was capturing prior to the rebuild. The bounce rate should drop as well. It is easier to navigate the site. It is much better looking than it was prior. Pretty much everything about the website is better than it was 18 months ago.

The SEO of the site is leagues ahead of where it was. The breadcrumbs work. There is appropriate structured data in the form of json+ld. The redirects are done properly. There aren’t any duplicate H1 tags. Meta descriptions are present on every single page. I anticipate that my indexing coverage will skyrocket after Google gets over the massive overhaul that the site underwent.

None of these benefits/upsides would have been possible without the growth that I’ve undergone the last year or so. I went out of my way to push my limits, better myself and improve my craft and I believe it shows. If you want to take a look at the old version of the site, you can may be able find it on wayback machine, but I’m not sure they have a copy. The updated site can be found here.

more posts