forked from gatsbyjs/gatsby
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from gatsbyjs/master
Update fork
- Loading branch information
Showing
81 changed files
with
1,733 additions
and
612 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
55 changes: 55 additions & 0 deletions
55
docs/blog/2018-06-24-investigating-gatsby-build-performance-at-scale/index.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
--- | ||
title: Investigating Build Performance At Scale | ||
date: "2018-06-24" | ||
author: "Sam Bhagwat" | ||
tags: ["scalability", "builds"] | ||
--- | ||
When website teams are deciding whether to migrate an existing site over to Gatsby, one consideration is how long it takes to rebuild each site when code or content changes. | ||
|
||
In order to help teams evaluate this, we’re publishing a set of build time benchmarks. | ||
|
||
# Performance Considerations | ||
|
||
Generally speaking, Gatsby build times consist of two factors -- O(1) constant-time operations, such as connecting to remote APIs, and O(n) linear-time operations, such as processing markdown pages, transforming images, and so on. | ||
|
||
On smaller sites, O(1) constant time operations take up most of the time “cost” of building a Gatsby site. On larger sites, O(n) linear-time operations predominate. Generally, larger sites tend to be CPU-bound rather than I/O-bound, so a more powerful server, VM, or container will finish quicker. | ||
|
||
The three most memory-intensive operations that scale with site size are **processing markdown**, **creating pages**, and **processing images with gatsby-image**. | ||
|
||
# Benchmark Parameters | ||
|
||
_Site tests_ | ||
|
||
In order to measure the “build performance cost” of each of these three factors, we’ve benchmarked Gatsby build times for two different sites, one image-heavy and one markdown-page heavy. | ||
|
||
The first site is [FreeCodeCamp’s Guide](https://github.com/freeCodeCamp/guide), one of the largest open-source Gatsby sites with around 3,000 pages. The second site is the using-gatsby-image official example [copied into its own repo](https://github.com/calcsam/gatsby-image-performance-benchmarking). We’ve run two different versions of this: first, with around 25 images and second, with around 250 images. Both sites are running on Gatsby v2. | ||
|
||
Note that **using gatsby-image is not a requirement to use Gatsby**. If you have enough images that image-processing-driven build times is impeding project goals or team workflows, consider simply removing (or not implementing) gatsby-image. | ||
|
||
_Machine types_ | ||
|
||
Tests were run on three different machines; on a local development machine (2015 Macbook Pro), on an AWS t2 micro free tier instance, and an AWS memory-optimized m4 instance. | ||
|
||
_Cold start vs warm start_ | ||
|
||
Tests were run both with (“warm start) and without (“cold start”) a pre-existing, local Gatsby cache. | ||
|
||
In most cases when code changes and all cases when content changes, Gatsby will preserve the cache from your previous build, giving you a warm start. The cache is only invalidated in rare instances, for example when the plugin changes. | ||
|
||
Whether you’re able to access the cache from previous builds depends on your CI setup, but many CI providers offer the option of preserving the previous build cache. | ||
|
||
# Results | ||
|
||
For cold start builds, each additional markdown page adds around **0.17 seconds**, while each additional image processed with gatsby-image adds **between 1.5 and 2.1 seconds** to fresh Gatsby builds. | ||
|
||
For warm start builds, each additional markdown page adds **around 0.07 seconds**, while additional images processed with gatsby-image are free. | ||
|
||
Full results are [linked](https://docs.google.com/spreadsheets/d/1ki5PwVTnIyycsk800DSWIA72UAr1k1DUJnKCf_lWz4c/edit#gid=0), along with our [build script](https://gist.github.com/calcsam/4aa066a46d74b6713c053a6adc0e0f76). | ||
|
||
# Next steps | ||
|
||
Gatsby users report that Gatsby builds fail due to running against hard Node.js process memory limits somewhere around 10,000 to 15,000 pages on v1. | ||
|
||
Since v2 has improved memory usage, we want to update this number, as well as further quantify the boundary so that teams considering migrating larger sites to Gatsby have more information for their decision-making. | ||
|
||
We also want to benchmark v2 build performance against v1 build performance for various sites. |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,107 @@ | ||
--- | ||
title: Presenting the Docs Redesign Card Sort Results | ||
date: 2018-06-26 | ||
author: Shannon Soper | ||
tags: ["documentation"] | ||
--- | ||
|
||
## What is a card sort? | ||
|
||
Recently, 36 Gatsby users completed an open card sort to help make our docs here on gatsbyjs.org easier to use. Without any outside input or help, they each sorted 90 cards into categories that made sense to them and then named those categories. | ||
|
||
### Raw & beautified data | ||
|
||
I ran this card sort through [OptimalSort](https://www.optimalworkshop.com/), a software that moderates the card sort and presents the data in usable forms. If you’re curious to see the full results, you can [view the data](https://www.optimalworkshop.com/optimalsort/x87kpp82/5x34psa3-0/shared-results/fa8b66knb66qyhwh5l8j38bd273vkkm7), including raw data as well as things like a similarity matrix and a [dendogram](https://support.optimalworkshop.com/hc/en-us/articles/201997650-Interpreting-the-OptimalSort-dendrograms). | ||
|
||
## How did participants categorize the docs? | ||
|
||
People sorted the docs into the following categories: | ||
* Get Started / Welcome to Gatsby / Intro | ||
* Development environment | ||
* Releases & Migration | ||
* Core Concepts / About Gatsby | ||
* Advanced Guides | ||
* API Reference | ||
* Tutorials / Examples | ||
* Contributing | ||
|
||
These categories weren’t too surprising (I included multiple names when the some category names were equally popular). However, upon further digging into the data, I discovered some unexpected results that further refine how we might categorize the docs, write new docs, and change how we think and talk about Gatsby. | ||
|
||
## PWA | ||
|
||
No one seems to know what to do with the doc titled “Building apps with Gatsby”. In the similarity matrix data visualization, 41% of people associated it with the “Authentication tutorial” doc and 41% also associated it with the “Progressive web app” doc. A 41% isn’t *very* strong. Essentially, this means participants didn’t think it “fit” very snugly alongside any other docs. | ||
|
||
![Building apps with Gatsby is weakly associated with other docs](building-apps-with-gatsby.png) | ||
|
||
This could mean several things: | ||
1. We don’t have very many docs about how Gatsby can be used to build dynamic apps | ||
2. People don’t think of Gatsby as a tool they’d use to build apps with | ||
3. The title of the doc is too broad or too vague | ||
|
||
Without interviewing each participant I can’t be sure, but I’m inclined to think a combination of all three factors means people don’t know where to put that doc in the navigation. This might mean we need clarity in how we present what Gatsby *is* in all our informational material and marketing and that we build more docs about Gatsby being more than a static site generator. | ||
|
||
### Deployment | ||
|
||
There was a lot of disagreement about where docs about deployment should go. For example, card sort participants placed the “Build and deploy a live site” doc in 28 unique categories. Here’s a sample of the categories: | ||
|
||
![Deployment categories](deployment-categories.png) | ||
|
||
The three most common categories it was placed under are “Getting Started”, “Tutorials,” and “Deployment.” Other categories include “Examples,” “Guides,” and “Production.” Here are the deployment docs that need to find a place to call home: | ||
* Build and deploy a site | ||
* Preparing site for deployment | ||
* Deploying a site live online | ||
|
||
One solution that occurred to me is to bring Deployment & Hosting to top level navigation as their own category, since there was so little agreement on where to put them. | ||
|
||
> ***NOTE:*** If you look at the data, the number of unique categorizations isn’t always a useful number, because Optimal Sort considers “getting started” and “get started” to be different categories even though a human eye can see they are essentially the same. However, in the case of these deployment docs, there were 28 categories and many of them are *truly unique*. | ||
### Core Concepts vs. Advanced Guides | ||
|
||
There was quite a bit of overlap in the docs people assigned to these two categories. This is probably because the two categories have a close relationship with each other; they work in harmony to help Gatsby users build at an advanced level. For example, if you read about how Gatsby works with GraphQL in “Core Concepts,” there is a high chance you’ll want to start playing with GraphQL queries and find examples of these in “Advanced Guides.” I’m not entirely sure how to reflect this close relationship in the docs; the most straightforward way is probably for each doc in “Core Concepts” to have a list of relevant links in "Advanced Guides," and vice versa. | ||
|
||
Here’s a sampling of docs that people associate with both categories: | ||
* Search engine optimization (SEO) | ||
* Authentication | ||
* E-commerce | ||
|
||
List of other lonely docs that didn’t find a solid home through the card sort: | ||
* The “RFC Process” doc didn’t find a snug fit. Two people didn’t know what it meant, and 44% of people put it under Contributing, but that’s not a majority. Seems like many people don’t know where to put it. I’m wondering if the title is too vague. | ||
* There was little agreement on where the “Html.js” doc goes. There was a 47% association with Babel and a 47% association with using layouts to build reusable site sections. | ||
* “React components” highest association was a 47% association with “basic structure of a Gatsby site” and all its associated pages. This slightly low association score probably results from the fact that the .org site doesn’t teach that much React at all, and there aren’t many docs on React specifically. | ||
|
||
## Dendogram adventures | ||
|
||
These screenshots that show a portion of the dendogram show that the clearest category was "Contributing", clear because the category name and the contents of the category are consistent: | ||
|
||
![Contributing dendogram](contributing-dendogram.png) | ||
|
||
Gatsby users are in agreement on what that category ought to be called and what docs it should contain :) | ||
|
||
## Next steps | ||
|
||
### Usability testing | ||
|
||
The next step is to conduct usability testing on a new design of the .org site. I’ve already conducted 8 usability tests with several more coming (5-7 produces reliable data in conventional UX research practices) and I’m seeing more ways to improve what we place in these categories as well as many ways I can improve my usability testing :). | ||
|
||
Many thanks to all those participants who have been enthusiastic and willing to give feedback, including Korey Boone, Shannon Smith, Peter Wiebe, Abhishek Vishwakarma, Ria Carmin, and Hugo Marques, Bogdan Lazar, Cameron Steele, and Simon Koelewijn. There are quite a few more people meeting with me in the upcoming week. | ||
|
||
These are the docs categories I’ve used for usability testing so far: | ||
* Get Started | ||
* Core Concepts | ||
* Releases | ||
* API Reference | ||
* Recipes | ||
* Tutorials | ||
* Contributing | ||
|
||
Here are a few realizations from usability testing already: | ||
* sometimes people don’t see the search bar on the .org site | ||
* when searching for something in the docs or to solve an error, many people do a google search before using docs navigation or the .org search bar | ||
* the category name “Recipes” was unclear to most people, although once they see the contents of the category, most people tend to like it | ||
* the usability testing validated one of the card sort results, which is that some docs kind of fit in three categories: "Core Concepts" and "Recipes" and "Tutorials". These categories are all closely related and will need to link to each other often | ||
|
||
### What’s next | ||
|
||
Stay tuned for the results of the usability test and the new sidebar menu of the .org site, which will likely get released together :D | ||
|
||
And please read and comment on the [Doc Redesign RFC](https://github.com/gatsbyjs/rfcs/pull/5) if you have more ideas on how we can redesign the docs! |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.