DEV Community: Blair McKee

Generate Types for Your GraphQL Schemas in 5 Minutes

Blair McKee — Wed, 06 Jul 2022 13:12:50 +0000

I couldn't find one single article that actually included all the steps to do this, so here's the step-by-step guide I wish I had hours ago on how to generate TypeScript types for your Graphql schemas 🫠

Separate your queries out from your components (optional, but nice)
Appease Webpack and TypeScript
Install some packages and plugins
Codegen time!

Context

I'm building an app using GraphCMS (super awesome, by the way) but the only gotcha is it doesn't offer a plugin to export your schema types. Since I can't function without TypeScript, that was a big problem the second I tried to write mutations or generate static pages using my schemas.

Step 1

Move your queries to a directory where only your queries will live.

Why? Separation of concerns, you don't want to couple your business logic with your presentational components. Also, it'll make it easier to to write your codegen config file.

query Question {
    questions {
    prompt
    tags
    id
    answer {
        html
    }
    }
}

Make sure each query is stored in its own individual .graphql file.

Step 2

If you're using Create React App or NextJS, you won't be able to compile at this point because webpack has no idea what a .graphql file is.

I'm using Next so this will end up in my next.config.js file, but if you're using CRA you'll want to follow these directions so webpack can parse your query files.

module.exports = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.(graphql|gql)$/,
      exclude: /node_modules/,
      loader: 'graphql-tag/loader',
    });
    return config;
  },
  webpackDevMiddleware: (config) => {
    return config;
  },
};

By the way, I found these config steps in this awesome NextJS + GraphQL + TypeScript setup article 👏🏼

You'll also want to add types for these files so Typescript doesn't yell at you. Add this to your graphql.d.ts file at the root of your app.

declare module '*.graphql' {
  import { DocumentNode } from 'graphql';
  const Schema: DocumentNode;

  export = Schema;
}

Step 3

Install a bunch of stuff.

I'm using yarn so swap out npm i for yarn add if you haven't joined the yarn bandwagon, yet.

yarn add graphql-tag
yarn add graphql
yarn add @graphql-codegen/cli
yarn add @graphql-codegen/typescript-operations
yarn add @graphql-codegen/typescript

👆🏼 There's a lot of stuff here, so let's break it down.

graphql-tag -> is our webpack loader
graphql -> you probably installed this already, but this is going to be an essential package later for when you want to make queries
@graphql-codegen/cli -> this is an awesome CLI that helps you setup your codegen config
the rest are plugins for the aforementioned CLI To get it to work with TypeScript

Step 4

Once you've run all those scripts, we can finally codegen our types!

You can use the CLI to setup your config, but I prefer to do it manually (it's also quicker, tbh. I tried 3 different codegen CLI's and this manual way the fastest and least error prone).

Create a codegen.yaml file at the root of your app and start plugging in the link to your API schema and directories for your queries.

schema: 'http://my-graphql-api.com/graphql'
documents: './src/queries/*.graphql'
generates:
  graphql/generated.ts:
    plugins:
      - typescript
      - typescript-operations

The documents value must be a folder where all your queries live and they must be stored inside files that end with .graphql, .ts, or .tsx.

Last but not least, we'll add a script to our package.json to run all this.

"scripts": {
    "codegen": "graphql-codegen"
}

Now you can run yarn codegen and see your generated types! Happy coding, y'all ⚛

CSS Grid in IE11: It's Possible! And Not as Hard as You Think

Blair McKee — Tue, 04 Feb 2020 13:56:38 +0000

Yes, it's possible! But it's up to you to know what is supported and what isn't. I'll save you the research and give you everything I found on CSS Grid in IE11.

If you look at caniuse, IE11 has partial support for CSS grid. But what does that mean? Basically everything from this version of grid is supported... aka: nothing you can rely on if you're used to modern grid.

You'll need a supported CSS preprocessor or prefixer to give you all the polyfills you need to enjoy the awesomeness of grid in legacy browsers.

TLDR;

There is no solution that polyfills everything for you. You still need to know the limitations of grid in IE11 and know what manual polyfills you'll need to write if you want to use methods like repeat() or props like grid-gap. You'll also need to explicitly tell each grid item where it should live in the grid, ie: you'll need to add a class to every item and tell it where to start, end/span. (Yes, it's a real pain, but do you want grid in IE11 or not?)

What's Supported in IE11

Good news! repeat is supported! It's just syntactically different. Instead of grid-template-columnds: repeat(6, 1fr 100px) you'll have to manually write out -ms-grid-columns: (1fr 100px)[6] for IE11.

What Isn't

span

span as in grid-column: span 1/-1 is not supported.

Child positioning

Grid item positioning. I mentioned this earlier, but it's important to reiterate so you're not pulling your hair out after following everything else I said. Grid items need to be explicitly "placed" in the grid. And, sadly, you can't select each child with :first-child or :last-child and so on. You have to create unique classes for each child and tell them where to start and end in your grid.

Know your IE11 wierdness

Another thing to be aware of… by default display: block behaves differently in IE11. Usually, if you have a parent container with content inside, the parent will by default be the size of the content. In IE11, the parent is by default the width of its respective parent. None of the articles I read mentioned this, which tells me they didn’t actually test in IE11. Or read the specs. But I did for you, so you don’t have to.

grid-gap

grid-gap, too, which is hands down my favorite CSS grid feature, does not get IE11 support. But you get by if you make extra columns/rows to act as your gaps.

everything auto

grid-auto-rows and grid-auto-columns are not supported, because IE11 can only create columns and rows automatically based on the size of the content it contains in the grid. So if you try to explicitly give a size with auto rows or columns, it will default to auto.

auto-fill and auto-fit won't work either, because IE11 has no concept of auto placement. Although, there are ways to hack it with autoprefixer.

But minmax() will work! Just not with auto-fill or auto-fit.

shorthand

Shorthand props like fit-content() and grid won't work, but they will if you write them out longhand.

inline elements

If any of your grid items are inline elements, they won't respect the grid. AKA your span and a tags. But what most people don't realize is any new HTML5 elements won't be recognized by IE11 and it will see them as spans and inline them. So you'll need to explicitly displaying them as clock, such as main, header, footer, etc.

Thankfully, normalize CSS does this for you... but check with your compiler or preprocessor to make sure they do.

This is just the tip of the iceberg, read CSS trick's article for even more of what's supported.

Put your preprocessor to work

Not a fan of manually polyfilling your code? Cool, me too. Try these libraries out...

Autoprefixer

Now there are a lot of great articles out there already that talk about this, and almost all of them end up with the same solution, use autoprefixer which seems to have polyfills for almost everything...

Almost everything... but there are still some things you have to polyfill manually.

If you are okay adding another dependency, there's a lot of content on autoprefixer, which does seem to be the tried and true solution (for almost everything).

But... I try to avoid adding dependencies whenever possible. So instead, I looked into what I was currently using to see if there was something native I could use.

Styled Components

I'm working out of a legacy codebase that uses a combo stylus and styled components. We're trying to move everything to styled components, so I first looked for polyfills there. Autoprefixer won't work, because it compiles at build time, where styled components are at runtime. Leaving me to rely solely on styled components for a native solution which unfortunately uses stylis to compile... and doesn't have prefixing for CSS grid... yet?...

I'd say "yet" but the issue has been open for 2 years with no updates. I'm a huge fan of styled components, so that was a big let down.

Stylus

So I looked for solution in stylus. Luckily, we happen to use kouto-swiss to do our compiling (and lots of other cool stylus functions) which includes polyfills for grid in IE11... almost all of them. I had to do some testing to see what it actually did, because the docs claimed that it had polyfills for everything, including things that were not supported in IE11, like grid-auto-flow.

grid
grid-area
grid-auto-columns
grid-auto-flow
grid-auto-position
grid-auto-rows
grid-column
grid-column-end
grid-column-start
grid-row
grid-row-end
grid-row-start
grid-template
grid-template-areas
grid-template-column
grid-template-rows

Unfortunately, it doesn't tell me what versions of IE11 these were polyfills for... So I did some more digging to see what polyfills were limited to.

Here's what I found...

Turns out... kouto was only adding the -ms prefix and not actually changing any syntax, or caring if something wasn't supported. Here's a great cheat sheet that is the most up to date version of what's supported on IE11, even with polyfills.

Takeaways

Don't trust your preprocessor to do all the heavy lifting for you. Know what it's doing under the hood and test, test, test!

Review my Portfolio?

Blair McKee — Mon, 26 Aug 2019 14:29:33 +0000

Hey guys! I just rebuilt my portfolio in React and would love to get some feedback.

Check it out here

I added a dark mode toggle using the Context API and had a little too much fun with the 80's vibe. Let me know your thoughts on the design and presentation of my work.

I've also recently redone my resume, any suggestions are appreciated. Here's the Google doc

How to Write a Great Technical Blog that Ranks

Blair McKee — Tue, 19 Mar 2019 20:16:40 +0000

You can be a great developer, and maybe an excellent writer, too... but that doesn't mean your blogs rank well on search engines. The latter requires a great deal of practice, user research, and most of all... trial and error.

Before I teach you how to write great technical blogs that also rank well on search engines... you need to know this:

This blog isn't going to make you a great technical writer, nor is it going to give you a template to rank better for your target search terms. I won't discuss link building or promotion either, that's up to you.

What I will do is teach you how to fine tune your blog topics so that they have the potential to rank well; how to research said topic; and guidelines for how to write about the topic in a way that answers searcher intent.

Searcher Intent

What is searcher intent? Only the most important thing in your universe, right now. Searcher intent is the driving force behind a search engine query. It could be a problem that needs to be solved, curiosity about a subject, a search for validation... I mean, think about it. Why do you use Google and other search engines?

If you really don't know, take a look at your activity.

Now take one of the last search queries you made, and type that into your browser again. Which one of the ten links did you end up clicking on? (hint: if you're on the same device, it will be purple). Why did you click that link? Did you find your answer there? Or did you click more than one?

Hopefully, you got lucky and didn't have to click anything and you were able to glean an answer from the featured snippet... lucky you.

That's because the page that ranks for that featured snippet solves the user intent concisely and accurately.

In the example above, I wanted to know how much wood a woodchuck could chuck. I didn't even have to scroll down to the search results, because the featured snippet has the answer bolded for me right there.

When you write your own technical blogs, you need to keep searcher intent at the forefront of your mind... and actually, at the forefront of your article. Most featured snippets grab their content from text that is above the fold --that's the content that's within the viewport when you load the page without having to scroll.

Run a couple of searches yourself and see where the featured snippet content comes from. It's most likely at the top of the page, in a short paragraph.

Now, why would you want to answer the user intent like this? If they can get their answer from the search result page, why would they ever click on the link to your site? Isn't this counterintuitive to the whole motivation behind better search engine ranks?

I mean, the whole reason you are interested in SEO is because you want site traffic...

Because if you're writing a technical blog, nine times out of ten your target searchers are going to need more than a single sentence answer.

Think of featured snippets as your opportunity to show searchers that you have the answers, you are the authority on this topic, and they should click your link (rather than the #1 ranked page) to learn more.

Now, featured snippets are the endgame, the ultimate prize in SEO... in order to get there you first need to try to rank for the #1, 2, 3, 4, 5 slots on the search result page. To do that, you need to also answer searcher intent above the fold, concisely, and then give a quick preview of all the other great things searchers will learn if they keep reading.

If you ever dipped your toe into the world of SEO before, you might be screaming at the computer right now saying "No that's not right! Google will only show the meta description, so on-page content doesn't matter!"

Things changed, thankfully...

In case you're new to this, meta tags are HTML elements that you stick in the header of each page that contain the page title, description, and keywords. Meta keywords have since been deprecated, but meta descriptions are now on their way out too.

Don't believe me? Run a search for something, a question maybe, then view the source of a top-ranked page. Does the meta description contain the same text that you saw on the search result page? More than likely, the two will differ.

Search result description:

Meta description:

In the last few years, Google stopped relying solely on meta descriptions for page descriptions. Instead, it crawls the page content and generates its own description for the page using snippets of text. You'll also notice that the search query is bolded in the description.

So the above the fold content on your blog is crucial for better rankings, as well as high click-through rates.

By this point, you have an understanding of searcher intent, you are caught up on modern SEO practices, and hopefully the gears are starting to turn and you're ready to get writing.

Choose a Topic

Let's start by choosing a topic. This is actually the hardest, longest step, so take your time and don't be hasty.

You shouldn't be pulling your topic out of thin air, there should be a "need" for this topic. Or as we mentioned earlier, searchers should be asking their search engines about your topic.

If you are writing for work, check your support system. Don't have one? Check wherever you get client feedback.

Already have a topic? Great, let's put it to the test.

All you need is a single word, or maybe a few words, like:

DNS
Failover not working
Secondary DNS
DNS not resolving

I work for a DNS hosting company, so I'll be using examples from my own work when I write technical blogs and articles for our website.

Make Sure Your Idea Hasn't Been Done Already

Run a quick Google search for your topic, it doesn't have to be a full sentence or even a question. If you are using more than one word, wrap it in quotes. Are there already blogs, articles, or forums that explain what you're looking for?

Since we're talking about technical content, forums are usually your gold mine. Here you can find people talking about your topic in their own words. Read both the question and the comments, because you'll usually find the question asked multiple ways or at least links to other similar questions.

Forums are you most valuable resource, because you'll find people talking about your topic in words you never would have thought of, or put together in that order.

Write them down, because that's your searcher intent right there.

If you answered yes, there's already content on your topic? Then maybe you shouldn't write about that... just kidding! First, ask yourself these three questions:

Are they good articles? Do you have to go to more than one article to fully answer your question? This could be an opportunity for you to combine a couple of articles together to make one awesome blog.
Are the first five sources Wikipedia, a news organization, ServerFault (within the last two to three years), or another authoritative source? This does not include other providers or personal/tech blogs. Reddit doesn't count either. If you said yes, then maybe you should choose another topic.
Are you seeing a wide variety of articles about your topic that are completely unrelated to each other? Maybe you need to fine-tune your topic a little more...

If you make it through all three questions and still feel like you have a strong topic, let's roll! Because at this point, you know that your topic is popular, there's a need for answers, and no one else has written about it as thoroughly as you can.

Did you answer no to the first question, no there isn't any content on my topic?

That may mean that there aren't enough people talking about it or there isn't a good enough article that answers the question.

Even scarier... this could also mean that no one cares about your topic.

Let's rule that out really quick by doing some keyword research. I recommend using Answer the Public, it's a free keyword visualization tool that shows you related keywords and questions about your topic. Also, the annoyed man on the homepage makes me giggle.

If you search for "DNS" you'll see something like this:

The more branches and sub-branches, the more popular your topic is. If you don't see a lot, maybe they haven't indexed it... or maybe your topic sucks (just kidding!).

You have to make a decision here, either stick with your potentially unpopular topic... or start over with something new. Up to you.

Give Your Topic Direction

Now that you have your topic, you'll need to whittle it down into something you can write about. Because right now, all you have is a concept with no direction.

Let's do some more keyword research! Take your Answer the Public results and zoom in on each branch.

I usually focus on the "how" and "what" branches. Here you'll find your most basic, general questions that users are searching for about the topic. These queries should also give you an idea of how users want to apply the concept and could give you valuable use cases you can use as examples.

Let's look at the "how" branch. Start at the darkest query (the darker the green dot, the more popular the query), in this case, "how DNS works" is the most popular search query.

Now work your way down through the list, and you'll notice that most of the questions revolve around the DNS lookup process. Makes sense, it's confusing.

But these are queries that have already been answered, by many sources, in detail. Even Wikipedia and ICANN have articles on the DNS lookup process, and those kinds of sources are extremely difficult to outrank.

In this case, since DNS is a very popular topic, I would stay away from the "how" and "what" questions and would move on to less popular topics.

It's also a good idea to steer clear of opinionated queries that you'll find in the "which" or "why" branches.

So let's look at something with a higher search ranking opportunity. Switch over to the less popular branches, like "will" and "can". Here you'll see less generic queries like:

Will DNS affect ping/speed/download speed (usually revolves around public DNS, not something a DNS hosting company is interested in)
Will changing DNS affect email
DNS will not resolve (still too general)
Can DNS names have hyphens (off topic... brings up domain registration stuff)
Can DNS redirect HTTP to HTTPS (oh look! We're already #1 for that)

There are some solid blog ideas here... but keep in mind that they need to also be relevant to our target industry (in this example, that would be Managed DNS).

That means, stay away from public DNS, private DNS, and general Sys Admin troubleshooting issues.

Now there are some exceptions. If there are industries you are trying to get into, or there are slight overlaps in topics... go ahead and work on those topics. Just use your best judgment, and if you feel like you're reaching, you probably are.

Research Time!

At this point, you have a topic and a direction. Now you need to do your due diligence and find out everything that's already been written about the topic.

You can use this information later when you write the article. You can either paraphrase something you found interested/relevant/necessary... or cite it and link to it. Up to you.

Usually, I cite and link out to content that I think is relevant, but not necessary in this article. I paraphrase stuff that is essential, like definitions or processes, and then link to my source.

Use inline links to keep it clean and readable, and don't say "read more", it detracts from the flow.

Confused? Don't worry, I'll walk you through an example topic/blog.

Let's go with the "will changing DNS affect email" topic. Google it and you'll see results from hosting companies, Quora, forums, and more hosting services.

Don't get discouraged if you see a lot of companies/providers or forums ranking high for a query. Usually, that means there's the opportunity for you to rank well, too as long as your content is more valuable to searchers.

As long as you don't see what are obviously authoritative, undeniably third-party sources (like Wikipedia or organizations that were created to be the authority on the topic) ranking in all of the top five slots... you have a chance to rank well.

Even if the top five positions are taken, you still have a chance if you can create a really thorough and well-researched article that discusses related topics and links to credible sources.

This is your golden opportunity to be the authoritative source on your topic.

Go to the first five results, read the articles, take notes. Write down the exact questions (if it's a forum) that users asked, jot down the answers, and anything you find interesting.

If you consistently see a similar phrase, Google it, this could be a related topic that you could touch on or even write about later.

At this point, you should have enough information to start writing. If you don't... maybe you need to go back to your keyword research and find another direction to go with your topic.

Tips for Research

Use your discretion when you read answers on ServerFault, Reddit, Spiceworks, or any other forum. If there are a lot of upvotes, comments from people who used the solution as well, I would trust the answer. But if it looks fishy, I would steer clear from using that answer as a source (whether you cite it or not).

Same applies to Wikipedia. If there is a citation, follow it and make sure it is credible.

Bottom line, if it looks like a duck, walks like a duck, quacks like a duck.... If you have one iota that it could possibly be a duck... Don't use it in your blog because it's probably a duck.

There are better sources out there, I promise! If not, then you could become that source, as long as you are confident that your information is true and helpful.

Let's Get Down to Business (I mean writing)

First, give yourself a pat on the back because you've done all the hard work already. Now all you have to do is turn your mess of research and citations into something cohesive.

Remember that you can do multiple drafts, the first time you write this is not going to be what you end up publishing... and that's okay!

Here's a sort of template that I follow when I write technical blogs:

Write the title last. When you do write the title... write at least three.

Start your blog with a single, two to three sentence paragraph that introduces what the article will cover. This is where you answer user intent and what you ideally want to show up in featured snippets. Keep it concise. Again, you can do this last as well.

If your blog answers a question, reiterate it. And iterate multiple times in different ways. Always make sure you phrase the question the same way a user would. Even better if you can copy and paste an actual user's question. You can format this in bullets, like this:

How do you move traffic from one server to another?
How can I redirect users away from a downed resource?
Can you failover traffic from one inbound ISP to another?

Then, I would explain/define any terminology that is central to the topic. If I was writing a blog about how to setup Failover, I would explain what Failover is and link to any relevant articles or tutorials.

Don't be afraid to use diagrams, just cite where you got it from. Google images does not count! Find the original source and give them credit.

Now you can get into the meat of your blog. If you are explaining a process, ie: how to do something, or a troubleshooting process... use headers to denote the steps.

For example, use H2 headings for each step and number them, like: "#2 Check if the computer is plugged in".

That brings us to our next tip... use headings! I use a Wordpress plugin to generate a table of contents for each blog based on the headings. Headings also break up your content into short digestible sections, making long articles (which technical blogs so often are) easier to read and less intimidating. So get in the habit of using headings, it'll make your life, and your reader's experience much easier!

Feel free to use lists (unordered and ordered, both get indexed by Google and will show up in featured snippets), block quotes for something important (single sentence, though), and images.

If you hit a roadblock...

Maybe text isn't the right way to convey what you are trying to get across to the reader. Try another type of medium like a graphic, flow chart, video, or a GIF.

Take a break. If you find yourself deleting and rewriting something over and over again, you need to take a break. It will come to you when you least expect it.

Go back to your keyword research and see if there's a related topic you could talk about in tandem with the current one.

Recruit a beta reader, or as I fondly call them "guinea pigs", to read what you have and give you feedback. Try to not be resistant to negative critique, after all, you did ask for their opinion. Listen and digest. If it doesn't work for you, then let it go.

Wrapping Up

Technical writing should be written by technical people, like you; not hired copywriters with no actual experience. This is your medium, your opportunity to share your experiences, talk about what interests you, and educate others. Take advantage of it.

What Web Devs Can Learn from the Top 10 eCommerce Sites on Cyber Monday

Blair McKee — Tue, 27 Nov 2018 19:34:50 +0000

Originally, I planned to only monitor network and onpage performance metrics of the top ten eCommerce sites on Cyber Monday. But after crunching the numbers, I found something I hadn't anticipated... third-party tracking tags are taxing a significant toll on page load times.

The chart above shows the top ten sites from shortest to longest DOM load time. I noticed that sites with more trackers had consistently longer DOM, total load, and finish times.

Actually, third-party trackers had more of an impact on load times than requests or page size! Some websites took over a minute to fully load because they were waiting on requests for tracking beacons.

You might know these trackers as pixels or beacons. They are very small scripts that capture information about website visitors and send that info to an external application for reporting.

You most likely use a few of these trackers on your website and think that since they are short scripts that make a quick external call and don’t change anything in the DOM, they must be harmless. Yes and no…

On their own, trackers usually won’t have any impact on user experience, since they run in the background. But, when you have dozens of requests for third-party tracking and each one takes a few hundred milliseconds to load, you could be adding valuable seconds to your load times.

After looking at the top ten sites, I found that on average these sites used 24 trackers, with the peak reaching 74 trackers on a single page. That's 74 requests that could be clogging up load times or blocking other resources from rendering.

Now these sites are not representative of the majority of the web, or even the kinds of projects you might be dealing with. But it's important to look at sites at this scale so that we can see how the little things can pile up and really impact user experience.

Before we get any deeper… we need to talk about the different kinds of load times. There are three different ways we measure page load:

DOM Load: how long it takes the browser to render all the HTML elements and scripts.
Page Load: DOM load + time it takes to download all the page content (images, video, etc.)
Finish: How long it took to send and receive all requests on the page.

Third-party trackers usually won’t load until after the DOM is loaded, which is why you will see drastic differences between the DOM load and the finish time.

For example, Amazon’s DOM load took only 1.55 seconds whereas the total load time finished at over a minute. When we reran the results a second time with an Ad Blocker enabled, the finish time dropped to 45 seconds.

Now 45 seconds is still a really long finish time. The culprit was a single resource that took over 30 seconds to load and inevitably failed. In this case, the DOM load was not impacted.

Amazon was far from the only site affected by third-party trackers. After the first round of testing was completed, I went back and reran all the tests with an Ad Blocker enabled.

I use Ghostery, a Chrome extension that prevents ads from showing on web pages as well as restrict trackers from scraping sensitive information.

I also used Sonar Lite, a free Chrome extension that uses Real-Use Monitoring to capture page loads and request timings. Shameless plug, I also work for Constellix.. but it is a fantastic free tool that makes life easier than opening up dev tools and hard reloading the page every time I want performance metrics.

In most cases, I didn’t see much of an aesthetic difference with or without the Ad Blocker, with the exception of Kohl’s who turned their website background into an advertisement. Once I enabled Ghostery, it disappeared entirely.

And pages that took a long time to render the initial paint (how long it takes to render the visual elements in the browser) still took the same amount of time.

All of this was as expected... until I crunched the numbers and compared them to the first test:

DOM loads reduced by an average of 8.9% when we used an ad blocker.
Total page loads (including images) were reduced by a whopping 17%.
Page size slashed by 24%
Requests reduced by 43%
Third party trackers were cut in half, down by 58%

You’ll notice that the number of trackers didn’t drop to zero. There are still some trackers being used even when we have the ad blocker enabled because these trackers are considered “essential” by Ghostery and all of our data is anonymized before being sent off.

But when you remove the majority of the trackers, all three load metrics, the number of requests, and page size dropped significantly.

So why should this matter to you? Well if you use third-party trackers, you need to be aware of the performance impact.

The websites we monitored in this study are the epitome of optimal web performance. They religiously use (and establish) the best practices for web performance and efficient web development. Despite that, they still suffer from the same pitfalls as everyone else due to overuse of third-party tracking scripts.

When I reran the tests with the trackers removed, the average DOM load time dropped from 1.9 to 1.7 seconds. That may seem inconsequential, but when you have thousands of millions of people using your site at the same time, every millisecond counts.

Experts estimated that over 75 million shoppers will take to the web for their Cyber Monday shopping. For the ten retail giants we monitored, that’s likely a couple million shoppers surfing their websites within a 24 hour period.

If page loads dip just the slightest bit, it could cost thousands in revenue.

That’s why these kinds of site are the best to learn from. They have teams of dozens of people working to keep their site lean and efficient, all to make sure performance doesn’t degrade when they are challenged by holiday shoppers.

Even if you don’t have the resources or man power that these ecommerce giants have, there is still so much you can learn from them and apply to your own development projects.

If there’s one thing you take away from this article, it is to be mindful of the trackers you use. Every pixel could impact performance, so don’t take those little scripts lightly.

Key Takeaways:

Sites with more trackers tended to have longer DOM and finish load times.
However, sites with more requests did not correlate with longer load times.
Pages that didn’t complete all requests had longer load times.
Lazy loading (loading images and scripts on scroll) improved page loads by a few hundred milliseconds to a few seconds
60% of the top websites had DOM load times under two seconds.
Website sizes were unusually higher than previous years averaging 3.75 Mb, nearly double the recommended size of 2Mb.
Trackers accounted for an average of a megabyte of website size.

The Results:

Here are the results from the two sets of tests. Each cell contains the difference between the first set of tests and the second set when I used an Ad Blocker. Red cells indicate an increase in load times or # of requests/trackers. Green cells indicate improvement and a reduction in load times or # of requests/trackers when we used an Ad Blocker.

Let me know what you think of this study. Were you surprised by the results? Did you see something in the data that I didn't catch? I'd love to hear your findings.