盖茨比乔布斯_为什么我们将已有20年历史的网站迁至盖茨比

盖茨比乔布斯

We knew we had a problem.

我们知道我们遇到了问题。

In 2019, SitePoint was getting Lighthouse Speed scores under 10 on mobile, and between 20 and 30 on desktop.

在2019年，SitePoint在移动设备上获得的Lighthouse Speed得分低于10，在台式机上达到20至30。

Our efforts to control UX bloat were failing in the wake of a publishing business environment that sprang new leaks just as we’d finished temporarily plugging the last one. Our reliance on advertising, controlled by external parties, was a major obstacle to improved site performance. Our traffic growth had turned into decline.

在发布业务环境不断涌现新漏洞之后，我们控制UX膨胀的努力失败了，就像我们暂时完成了最后一个漏洞的插入一样。 我们对广告的依赖(由外部各方控制)是改善网站性能的主要障碍。 我们的流量增长已变成下降。

On a site that provided people with a place to come and learn to code with best practices, this was not a good look. And it wasn’t a site we could feel proud of, either.

在一个为人们提供了一个学习最佳实践代码的地方的网站上，这种外观并不好。 这也不是我们引以为傲的网站。

To make matters worse, operational bottlenecks had arisen that made adaptation a tricky logistical business. Our team was struggling to make changes to the site: having focused on our Premium experience for several years, we were down to one developer with WordPress and PHP experience. To test out code changes, the team would have to wait in a queue to access our staging server.

更糟糕的是，出现了运营瓶颈，这使适应成为一项棘手的物流业务。 我们的团队正在努力对网站进行更改：专注于我们的Premium经验已有数年，而现在只有一名具有WordPress和PHP经验的开发人员。 为了测试代码更改，团队必须在队列中等待访问我们的登台服务器。

It wasn’t energizing work for anyone, and it certainly wasn’t efficient.

它并没有激发任何人的工作，而且肯定没有效率。

It was time to make some changes, and we set out to look for a solution. After a lot of research, we decided that Gatsby would be a great fit for our team. It would play to our talent strengths, help us solve all of the issues we had identified, and allow us to keep using WordPress for the backend so the editorial process wouldn’t need to change.

是时候进行一些更改了，我们着手寻找解决方案。 经过大量研究，我们认为盖茨比将非常适合我们的团队。 它将发挥我们的才能优势，帮助我们解决所有已确定的问题，并允许我们继续使用WordPress作为后端，这样就无需更改编辑过程。

为什么我们搬到盖茨比 (Why We Moved to Gatsby)

The end result.

最终结果。

Early in the research process, Gatsby started to look like a serious frontrunner. SitePoint isn’t a small site, so we knew that the tech we chose had to be able to handle some pretty intense demands. Gatsby checked all of our boxes:

在研究过程的早期，盖茨比(Gatsby)开始看起来像是一位真正的领跑者。 SitePoint不是一个小站点，因此我们知道我们选择的技术必须能够处理一些非常强烈的要求。 盖茨比选中了我们所有的框：

• We could code everything in React, a tech that every member of the front-end team knows and uses daily.

  我们可以使用React编写所有内容， React是前端团队的每个成员每天都知道和使用的技术。

• Gatsby is super fast at its core — performance was at the heart of this project, and we could start from a good footing.
  Gatsby的核心是超级快速-性能是该项目的核心，我们可以从一个好的基础开始。
• The entire site is rendered as static, which would be great for SEO.
  整个网站都呈现为静态，这对于SEO来说非常有用。
• We could build it as a new project, which meant no worrying about the existing codebase, which brought a huge amount of legacy code with it.
  我们可以将其构建为一个新项目，这无需担心现有的代码库，因为它带来了大量的遗留代码。
• We could use Gatsby Cloud, allowing the team to get feedback on the build at any time just by pushing the branch to GitHub.
  我们可以使用Gatsby Cloud，使团队可以随时将分支推送到GitHub，以获取有关构建的反馈。
• DDoS attacks on WordPress wouldn’t cause us issues, as the front-end is completely stand-alone.
  WordPress的DDoS攻击不会引起我们的问题，因为前端是完全独立的。

具有styled-components更易于维护CSS (More Maintainable CSS with styled-components)

Since we were going to rebuild the site from scratch, we planned to make some design changes at the same time. To help with this work we decided to use styled-components.

由于我们要从头开始重建站点，因此我们计划同时进行一些设计更改。 为了帮助完成这项工作，我们决定使用styled-components 。

styled-components keeps the site’s styling easy to maintain, and we know where to look when we want to change the style of something — the style is always with the component.

styled-components使网站的样式易于维护，并且我们知道当我们要更改某种样式时应在哪里查看-样式始终与组件有关。

我们如何进行构建 (How We Made the Build Happen)

We started by following Gatsby’s basic docs and pulling in our posts with the gatsby-source-wordpress plugin.

我们从遵循Gatsby的基本文档开始，并使用gatsby-source-wordpress插件添加帖子。

This was a big initial test for us: we had to see if it was even possible to use Gatsby for our site.

这对我们来说是一个很大的初步测试：我们必须查看是否甚至可以在我们的网站上使用Gatsby。

After 20 years of blogging, we have over 17,000 posts published. We knew the builds would take a long time, but we had to find out if Gatsby could deal with such a massive amount of content. As you’ve probably figured, the test delivered good news: Gatsby works.

经过20年的博客撰写，我们已发布了17,000多个帖子。 我们知道构建过程将花费很长时间，但是我们不得不找出盖茨比能否处理如此大量的内容。 正如您可能已经想到的那样，该测试传递了一个好消息：盖茨比工作正常。

A quick tip for other teams working with large sites: to make development a better experience, we used environment vars to prevent Gatsby from fetching all of the site’s posts in development. There’s nothing quite like a 60 minute hot reload to slow progress.

对于使用大型网站的其他团队的快速提示：为了使开发更好，我们使用环境变量来防止Gatsby获取网站上所有开发中的帖子。 没有什么比60分钟的热装慢慢了。

if (hasNextPage && process.env.NODE_ENV != "development") {
  return fetchPosts({ first: 100, after: endCursor });
}

From this point, we ran into some limitations with the WordPress source plugin. We couldn’t get all the data we needed, so we moved to the WordPress GraphQL plugin.

从这一点出发，我们在WordPress源插件中遇到了一些限制。 我们无法获取所需的所有数据，因此我们转到了WordPress GraphQL插件 。

We use Yoast to set our metadata for SEO, and had to ensure we were pulling in the correct information. We were able to do this with WordPress GraphQL. By doing it this way, the content team could still edit metadata the same way, and the data would still be dynamic and fetched on each build.

我们使用Yoast为SEO设置我们的元数据，并且必须确保我们提取了正确的信息。 我们能够使用WordPress GraphQL做到这一点。 通过这种方式，内容团队仍然可以以相同的方式编辑元数据，并且数据仍将是动态的，并且可以在每次构建时获取。

During the build, we would have three or four people in the team working on parts of the new blog. In the past, if they wanted to get feedback they’d have to push to our staging server and make sure nobody was already using it.

在构建期间，我们团队中将有三到四个人处理新博客的各个部分。 过去，如果他们想获得反馈，就必须推送到我们的登台服务器，并确保没有人正在使用它。

We found that Gatsby Cloud was a great solution to this issue. Now when someone pushes to a branch in GitHub, it creates a build in Gatsby Cloud along with a preview link. Our developers could share this link and get immediate testing and feedback much more effectively than before.

我们发现Gatsby Cloud是解决此问题的绝佳解决方案。 现在，当有人推送到GitHub中的分支时，它会在Gatsby Cloud中创建一个内部版本以及一个预览链接。 我们的开发人员可以共享此链接，并比以前更有效地获得即时测试和反馈。

This faster feedback cycle made it easy to have multiple people on the team working on the build and put an end to a major bottleneck.

这种更快的反馈周期使团队中的多个人员轻松构建并消除主要瓶颈变得容易。

启动日乐趣 (Launch Day Fun)

On the big day, we launched the new site and ran through our initial tests. The new blog was flying — every page load felt instant.

在重要的一天，我们启动了新站点并进行了初步测试。 新的博客如火如荼 -每个页面的加载都是即时的。

We ran into some problems on SitePoint Premium, which started running into slows and even crashes. The culprit was a new element on blog pages that pulled in the popular books people were currently reading. It would do this via a client-side API call, and it was too much for Premium to handle due to the amount of traffic we get on the blog side.

我们在SitePoint Premium上遇到了一些问题，它开始运行缓慢，甚至崩溃。 罪魁祸首是博客页面上的一个新元素，吸引了人们当前正在阅读的流行书籍。 它会通过客户端API调用来完成此操作，由于我们在博客方面获得的流量很大，Premium无法处理太多。

We quickly added some page caching to the API to temporarily solve the issues. We realized we were doing this wrong — we should have been sourcing this data at build time, so that the popular books are already loaded when we serve the page to the user.

我们很快在API中添加了一些页面缓存以暂时解决问题。 我们意识到做错了-我们应该在构建时就采购这些数据，以便在向用户提供页面时已经加载了流行的书籍。

This is the main mindset shift you need to make when using Gatsby: any data that you can get at build time should be fetched at build time. You should only use client-side API calls when you need live data.

这是使用Gatsby时需要进行的主要思维转变：应在构建时获取任何在构建时可以获取的数据。 仅在需要实时数据时才应使用客户端API调用。

Once we’d re-written the API call to happen during the build, the first load of a blog page was even quicker — and Premium stopped crashing.

一旦我们重新编写了在构建过程中发生的API调用，博客页面的第一次加载就更快了，并且Premium不再崩溃。

我们仍然需要解决的问题 (What We Still Need to Solve)

While it’s hard to overstate how much better our on-site experience is today, there are still a few pain points we need to solve.

尽管很难高估我们今天的现场体验有多好，但仍有一些痛点需要我们解决。

If a new article is published, or if content is updated — as it is multiple times per day — we need to re-run the Gatsby build before these changes show up.

如果发表了一篇新文章，或者更新了内容(每天多次)，我们需要在这些更改出现之前重新运行Gatsby构建。

Our solution for that right now is a simple cron job that runs at pre-scheduled times over the course of a day. The long-term solution to this is to add a webhook to the WordPress publish and update button, so that a new build is triggered once pressed.

我们目前的解决方案是一个简单的cron作业，该作业在一天中的预定时间运行。 长期的解决方案是在WordPress的“发布和更新”按钮上添加一个Webhook，以便一旦按下即可触发新的构建。

We also need to get incremental builds running. Right now, the entire site needs to be rebuilt each time, and given our content archive, this can take a while. Gatsby just introduced incremental builds as we went live, and we’re working on implementing this on our site. Once that’s set up our builds will be much faster if the only thing that has changed is content.

我们还需要运行增量构建。 现在，每次都需要重新构建整个站点，并且鉴于我们的内容存档，这可能需要一段时间。 当我们上线时，盖茨比(Gatsby)刚刚介绍了增量构建，我们正在努力在我们的网站上实施该构建。 一旦设置完成，如果唯一改变的是内容，我们的构建将更快。

Our speed score is still not where we want it to be. While the site feels subjectively very fast, we are still not getting consistent scores in Lighthouse. We want to get both mobile and desktop into the green zone (scores of 90+) for optimal user experience and SEO.

我们的速度得分仍然不是我们想要的。 尽管该网站在主观上感觉非常快，但我们在Lighthouse中的得分仍然不一致。 我们希望使移动设备和台式机都进入绿色区域(得分超过90)，以获得最佳的用户体验和SEO。

我们会再做一次吗？ (Would We Do It Again?)

A launch of this type would normally be a pretty nerve-wracking event, and take a lot of work from the team on launch day.

这种类型的发射通常是一件非常令人不安的事件，并且在发射当天需要团队的大量工作。

With Gatsby, our launch was really easy. We just had to move WordPress onto a new domain, and point sitepoint.com at the Gatsby version of the site.

有了盖茨比，我们的发布真的很容易。 我们只需要将WordPress移到新域上，然后将sitepoint.com指向该站点的Gatsby版本。

Then we sat back and watched the numbers to see what happened to our traffic. Within a few days, the data was starting to come in and we were seeing a 15% increase in traffic. User engagement metrics were up across the board.

然后，我们坐下来看着这些数字，看看交通状况如何。 几天之内，数据开始出现，我们看到流量增加了15％。 用户参与度指标全面提高。

It’s not hard to figure out why the effects were so immediate. We had better SEO running on static HTML and CSS pages, and massive speed improvements made possible by the move to Gatsby.

不难弄清楚为什么如此Swift的效果。 我们已经在静态HTML和CSS页面上运行了更好的SEO，并且通过改用Gatsby可以大大提高速度。

Since we made the move, we’ve increased our Lighthouse speed scores from 6-15 on mobile to the 50-60 range, and from the 30s on desktop into the 70s. We wanted to ensure speed remained top of mind with this change, so we’re using a great tool called Calibre that runs speed tests over a number of top pages each day and alerts us to the scores. We are using this tool to continue to improve our score, so I hope to have another article for you in three months when we get everything to stay in the 90+ range.

自从我们行动起来之后，我们将Lighthouse的速度得分从移动设备上的6-15提高到了50-60，从台式机上的30s提高到了70s。 我们希望确保通过此更改使速度成为首要考虑因素，因此我们使用了一个名为Caliber的出色工具，它每天都会在许多首页上进行速度测试，并提醒我们得分。 我们正在使用该工具继续提高我们的分数，因此，我希望在三个月内让我们一切都保持在90+以上的水平为您撰写另一篇文章。

The team loves working in Gatsby. The blog codebase was something that nobody wanted to work on. Now, everyone wants to take those cards thanks to the great developer experience.

团队喜欢在盖茨比工作。 博客代码库是没人想从事的。 现在，由于拥有出色的开发人员经验，每个人都想拿这些卡。

If you’ve been eyeing a move to Gatsby and wondering if it’s ready for prime time, take our advice — it’s worth the switch.

如果您一直打算转移到盖茨比，并想知道是否已经准备好迎接黄金时段，请听取我们的建议-值得一试。

翻译自: https://www.sitepoint.com/our-gatsby-redesign/

盖茨比乔布斯