kevinrodriguez-io / blog-gorilla

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Node minimim version Slack: next-js


next-js-seeklogo com ContentfulLogo64 CloudRun

Welcome to the Next-JS Workshop

We're going to learn a lot here. Please refer to the slides for more information.

Contents of this workshop

  • NEXT JS: Isomorphic react, the importance of SSR for SEO. We will use Next 9 features!.
  • Contentful: We will explore the award-winning, headless CMS and integrate it on our project.
  • SEO and Internationalization Techniques: Techniques to bring our NEXT.JS application to a broader user base.
  • Dockerize our application and upload it to a private registry: We will learn how to Dockerize our NEXT.JS application and upload it to Google Cloud Registry.
  • Deploy our application to Google Cloud Run: Finally we are going to deploy our application to Google Cloud Run (Extra: Linking to firebase hosting).

Important Concepts

Isomorphic / Universal

Isomorphic/Universal code usually refers to code that can run on both client and server environments. When we talk about Isomorphic/Universal code in the context of a frontend framework such as React, we have to know that the server is perfectly capable of rendering our react components even if you are not in a browser’s window. This is very important and will enable several scenarios that bring benefits to our projects, the browser is able to “inflate” the components generated by the server-side react code.

  • This is a concept that was born on the Javascript ecosystem: The term universal is bound to javascript due to it being the lingua franca of the internet and by having the ability to run on NodeJS and the browser.
  • It’s pretty new (But not so much): Javascript on the server is not a new thing, but it enabled really powerful scenarios.
  • Not to be confused with cross-platform (Although it is): The code runs on both client and server

Universal vs Static

While Universal javascript takes the needed resources to serve a route on demand, sometimes it is better to statically export all of the contents of a website. Static exporting means taking all of your routes, and generate them as static .html files that can be served via a CDN. It is usually cheaper, since it doesn’t involve the usage of processing power or memory consumption * but it is not always the best tool for the job, specially if you have:

  • Complex authentication logic
  • Lots of content that is updated regularly
  • The content is expected to grow a lot over the years

Generally * universal javascript is more flexible and provides a broader set of configurations

When choosing Universal vs Static ask yourself some questions:

  • Will I need to read cookies from the clients?
  • Will I need any specific integration between the client and the server?
  • According to the expected user base, is it cheaper to serve static files and atomically build the website every time an entry changes, or is it better to serve requests on-demand?

SSR and SEO

  1. On CSR(Client-side rendered) applications, if your first contentful paint is really slow, web crawlers will timeout and your content will probably not be well indexed.

  2. Google’s web crawlers may take up to three days to crawl javascript-generated content, depending on the available resources.

    • Google’s web crawler work by indexing the content two times, the first time it indexes the server-side rendered content, if the web app uses CSR, it will defer the client-side generated content to be indexed on a second time.
  3. Most social engines and preview generators are not compatible with javascript-generated content.

  4. SSR apps perform way better at SEO than CSR apps, because you have control over: Site Metadata, Correct HTTP Status Codes.

  5. Googlebot uses Chrome 41, which doesn’t support ES6 features, so you should be transpiling your client-side code!

  6. There’s a misconception in the community that Google will always index CSR content, but this will not always be true, Google improves constantly, but it won't cover all of the client-side scenarios, specially when it comes to lazy loading or onScroll events.

Recommended video: Deliver search-friendly JavaScript-powered websites (Google I/O '18)

First-Contentful Paint

  • First Contentful Paint (FCP) measures the time from navigation to the time when the browser renders the first bit of content from the DOM. This is an important milestone for users because it provides feedback that the page is actually loading.

  • This metric is important in terms of user interaction and perception of the speed of the site.

  • Can be improved by:

    1. Removing render-blocking resources like CSS and Javascript (Tree-shaking, bundling, minifying, etc), and try to use the least amount of Javascript possible to render the page.

      • Next JS uses code-splitting, so it avoids downloading the whole js bundle. 💪🏼
    2. Minimize the number of render-blocking external stylesheets and scripts upon which the page depends. See Render-Blocking CSS and Loading Third-Party JavaScript.

    3. Use HTTP Caching to speed up repeat visits.

    4. Minify and compress text-based assets to speed up their download time.

  • Try it on lighthouse

For more information, please refer to the slides.

About


Languages

Language:JavaScript 86.3%Language:CSS 13.7%