One place for hosting & domains

      Archives hassan latif

      Nameservers vs. DNS: A Complete Guide


      If you’re thinking about migrating your site to a new hosting provider, you may be wondering what it will mean for your domain registration. Perhaps you’re worried visitors will be unable to access your content if you switch web hosts.

      This is why it’s important to understand what nameservers and the Domain Name System (DNS) are and how they work. This understanding can help you manage your migration more efficiently.

      In this post, we’ll take a closer look at nameservers and DNS records. We’ll also show you how you can access these essential components of your site. Let’s get started!

      Nameservers vs. DNS Records: What They Are and How They Work

      A nameserver connects your domain name with the Internet Protocol (IP) address of the server that hosts your website. Thanks to nameservers, browsers like Google Chrome and Mozilla Firefox can direct users to the right page when they type in a site address.

      Typing a site address into Google.

      For example, if you type “myblog.com” into Google, the nameserver tells the browser where that domain is located (i.e., the address of your web host). Without this information, the browser wouldn’t be able to display the site.

      Nameservers form part of an online database known as the Domain Name System (DNS). This system is part of the  Transmission Control Protocol (TCP) and the Internet Protocol (IP), which defines how computers communicate via the internet and private networks.

      DNS plays an important role, as it aids the conversion of simple domain names (e.g., myblog.com) into an IP address (e.g., 12.34.56.78), which computers then use to identify one another on the network. Effectively, DNS functions like a phone directory. It contains records of web devices, such as computers and servers, and their associated IP addresses.

      Every domain has its own DNS records, which include the nameserver. These are generated when you register your domain name with a hosting provider or a domain registrar. Therefore, your nameserver points your domain name to the IP address of your host or registrar.

      Your Great Idea Starts with a Great Domain

      Don’t let someone else register your URL. Search DreamHost’s 400+ TLDs to find the perfect fit for your website.

      How the Browser Finds Your Website

      Everything that is connected to the internet has an IP address, including websites and servers. There are millions of IPs in use all over the world, and they are all unique. Your site will have its own IP address, which your host provides.

      However, your domain name needs to be able to connect with your site’s IP address. For example, when you enter a site’s URL into an address bar, your browser will try to access the corresponding page. To do this, it will go through some steps that the user doesn’t see.

      First, the browser connects to the target site’s domain registrar. Then the registrar points the browser to the target site’s hosting provider (e.g., dreamhost.com). Once the browser arrives at the web host, it will look for the correct nameserver (e.g., ns1.dreamhost.com).

      The process is practically instantaneous, so as users, we don’t fully appreciate the additional steps. However, should you decide to change your hosting provider, you’ll need to point your domain name to your new host. This is a vital step. Otherwise, users will not be able to find or access your site.

      How to Use Nameservers and DNS Records

      Knowing how to access your domain’s DNS records, including your nameservers, can help you arrange a smoother transition to your new host. Let’s take a look at the different ways you can locate and manage these important records.

      Locating and Managing Your Nameservers

      Your domain’s nameservers can be found in your web hosting account. These might also be available on the hosting company’s documentation page.

      The nameservers for domains managed by DreamHost are:

      • ns1.dreamhost.com
      • ns2.dreamhost.com
      • ns3.dreamhost.com

      If you’re a DreamHost client, you can also log in to your hosting account to view your nameservers. To start, navigate to Websites > Manage Websites in the side menu.

      Managing your websites in DreamHost.

      Next, find the domain you wish to edit and click on the DNS tab on the right side of the screen. This will bring up a page with your nameservers.

      Locating your nameservers in DreamHost.

      Note that if your domain is registered with a different company, you won’t be able to update your nameservers from your DreamHost account. To manage your nameservers, you’ll need to log in to your account with the company that manages your domain.

      If your domain is registered with DreamHost, you’ll be able to edit your nameservers. For instance, if you wish to replace your current nameservers, you can simply erase them from the box and type in your new ones.

      You can also manage your domain from the Registrations page in your account. For more information about this, you can read our complete instructions for editing your nameservers on DreamHost.

      Alternatively, you can find out what a website’s nameservers are by performing a WHOIS lookup. Nameservers are public records, so it is possible to find this information by using a third-party tool.

      Several sites offer this service, including lookup.icann.org.

      Running a WHOIS search.

      You can type the domain into the search bar, and a list of records will appear. For example, here are the nameservers for google.com:

      Viewing nameservers in a WHOIS search.

      Note that a WHOIS search can also show the personal details of the domain’s owner, including their name and email address. Some hosting providers and domain registrars offer WHOIS privacy, which protects the identity of the user.

      Locating and Managing Your DNS Records

      Your DNS records are just as easy to locate and manage. You can log in to your hosting account to view your records and make changes to them. If your domain is managed by a third party, such as a domain name registrar, you’ll need to log in to your account with that company.

      If you have a DreamHost account, your DNS records can be found on the same page as your nameservers.

      Viewing your DNS records in DreamHost.

      You can add a new DNS record to your domain by clicking on the blue Add Record button. As you may notice, there are different types of records you can create. Let’s take a closer look at the most common ones.

      A Record

      The address record is the most basic type of DNS record. It is used to point a domain (or subdomain) to an IP address.

      CNAME Record

      The canonical name record points a domain to another domain, as opposed to an IP address. This is used when a site has subdomains, such as shop.myblog.com or donations.myblog.com.

      Adding a CNAME record in DreamHost.

      These are subdomains of myblog.com. Let’s say that each of these subdomains has a CNAME record containing the value “myblog.com.” Since the DNS is looking for an IP address, when the CNAME record is accessed, a further lookup is carried out at myblog.com (as this is the value contained in the CNAME file).

      It will then return the IP address stored in myblog.com’s “A” record. This means that these subdomains are aliases of the main domain, and the canonical name (or “true name”) of these subdomains is actually “myblog.com.”

      MX Record

      A mail exchange record is used to direct emails to an address registered on your domain (e.g., hello@myblog.com) per the Simple Mail Transfer Protocol (SMTP), the standard protocol for email.

      It is important to ensure that your MX records point to the right mail server. If not, emails won’t be delivered to your account. We also recommend that you back up your emails before switching to a different host.

      Adding an MX record in DreamHost.

      NS Record

      As mentioned previously, this is the nameserver record. You can use this setting to change your nameservers so that they point to your new hosting provider.

      TXT (Text) Record

      This one allows you to insert text into your DNS records. Originally, the TXT record was designed for human notes, such as site descriptions or development details. However, it is possible to include machine-readable data.

      Adding a TXT record in DreamHost.

      This record can help you to protect your site against spam. It also enables you to verify your domain, such as by adding a Google Site Verification record. It is very common to have multiple TXT records for a single website.

      Monitoring Your DNS Records

      When updating your nameservers and other domain records, you’ll need to take DNS propagation into account. This is the time it takes for your DNS records to update across the internet. For example, when you modify your nameserver to point to your new hosting company, this change can take up to 72 hours to come into effect.

      At DreamHost, we offer a DNS propagation checker to help you monitor your records. To access this tool, simply click on DNS checker on your Records page.

      Accessing the DNS Checker in your DreamHost account.

      On the next page, you can check your website’s current IP address and DNS record information. Our interactive maps show you the status of your records across nameservers in different locations.

      Using the DNS checker to view the status of your records.

      The green checkmarks on the map indicate that your DNS is up-to-date in the specified locations. Meanwhile, a single red cross suggests there might be a problem with the DNS server in that location.

      If you see multiple red crosses, it may mean that you haven’t configured your DNS at the company where you registered your domain. However, this could also be a sign that your new DNS settings haven’t yet finished updating.

      DNS Management Made Easy

      Whether you need help identifying a domain’s nameservers, understanding a DNS query, or choosing a web host, we can help! Subscribe to our monthly newsletter so you never miss an article.

      Nameservers vs. DNS in a Nutshell

      Understanding how nameservers and DNS Records work can ensure a smooth transition when migrating your site to a new host. It is imperative that your domain name points to the correct nameserver. Otherwise, site visitors will be unable to access your pages.

      At DreamHost, we make your life easier by managing the entire transition process, including your domain transfers. We also enable you to manage your own domains and DNS from your hosting account, and our service comes with free privacy protection for your domain.



      Source link

      7 Great Web Accessibility Examples to Inspire You


      Here at DreamHost, we believe everyone should be able to use any website on the internet, regardless of any disability they may have. However, while we care about web accessibility, we also understand that designing a website that’s both accessible and visually attractive can be challenging.

      The good news is that accessible websites don’t have to be ugly. On the contrary, some stunning websites out there are designed with accessibility in mind — which we could all learn a thing or two from.

      In this post, we’ll start by showing you what strong web accessibility looks like. Then we’ll show you seven of the best web accessibility examples on the internet and see what we can learn from them. Let’s get started!

      Create a Website for All

      We make sure your website is fast and secure so you can focus on the important stuff.

      What Great Web Accessibility Looks Like

      According to The World Bank, over 15% of the global population has some form of disability. These can include:

      • Visual impairments: Some users have visual impairments that inhibit their ability to see clearly or perceive color contrasts
      • Hearing impairments: This includes deafness and partial hearing loss.
      • Physical disabilities: Some people have mobility impairments that can impact their dexterity and ability to make precise movements, possibly making using a mouse difficult.
      • Cognitive disabilities: Conditions like dyslexia and dementia can affect a person’s cognitive abilities.

      It’s important to keep all of these different challenges at the forefront of your mind when creating your website to ensure there are no barriers to disabled users. To help web designers with this, W3C has developed a set of Web Content Accessibility Guidelines (WCAG).

      Solid web accessibility means adhering to these guidelines and carefully following the four guiding principles of web content accessibility. These guiding principles state that all websites should be:

      1. Perceivable
      2. Operable
      3. Understandable
      4. Robust

      Ensuring that your website is “operable” might mean implementing keyboard-friendly navigation for people who cannot use a mouse. “Perceivable” might mean making sure to use high-contrast colors for people with visual impairments.

      We’ve already outlined 10 practical ways to implement the web accessibility guidelines and make your website more accessible (including advice on accessibility testing and UI components). Now we’re going to look at some examples of websites that are already doing it right.

      7 Great Web Accessibility Examples to Inspire You

      Below, we’ve listed some of our favorite web accessibility examples. These seven websites set the bar when it comes to accessibility.

      1. Scope

      The Scope home page.

      Scope is a disability equality charity based in England and Wales dedicated to creating a fairer, more equal society. As a champion of disability equality, you’d expect that this organization’s website would be as accessible as possible — and it is.

      Not only does it fully adhere to WCAG 2.0 and WCAG 2.1 guidelines, but the site is even customizable for individual users. For example, users can change the site’s colors, increase the text size, or even turn on text narration to have the content read aloud.

      If you look at the top-left section of the home page, you’ll see an Accessibility tab. Click on this, and the site will bring you to its accessibility page, which includes instructions on how to adapt the experience to your needs, links to assistive technologies, and a list of known accessibility issues that are being worked on.

      Scope uses short sentences and large, clean fonts throughout the site for maximum readability. Plus, the site is fully compatible with screen reader software.

      Despite already being a fantastic example of website accessibility, the team at Scope continues to make improvements. Every three months, they test the website for accessibility and make updates where necessary.

      2. Paralympic.org

      The IPC home page.

      Paralympic.org is the official website of the International Paralympic Committee (IPC). The IPC is a powerful advocate of social inclusion, and its website is a testament to that.

      It features keyboard-friendly tab navigation and an instant “scroll-to-top” button to make it easy to move around the page. Images and videos are large and highly visible, and there’s plenty of white space to make visual elements stand out.

      If you go to the home page, you’ll notice a text size adjuster in the top-right corner of the screen. This is easily visible and allows users with visual impairments to quickly customize the size of the text to meet their needs.

      3. KidzWish

      The KidzWish home page.

      KidzWish is an organization that provides therapy, support services, and an annual Christmas party for children who are disadvantaged or have a disability. It caters to many people with different disabilities, so naturally, it needed to build a website that was as accessible as possible.

      It definitely achieved that goal. The KidzWish website is wonderfully designed, with a logical structure, keyboard-friendly navigation, high-contrast colors, and large text. Plus, it’s easy to navigate with prominent, clickable elements.

      The design is also very child-friendly. It boasts a bright, bold color scheme and tons of fun graphics.

      4. SSE Energy

      The SSE Energy home page.

      SSE Energy is a UK-based energy company. Its website features information about tariffs and bundles and includes a main login portal for its customers to service their accounts.

      The company has done a wonderful job of making the site accessible to all by using large readable text and a clear interface. It also incorporates keyboard navigation to make it easy to get around the site.

      The designers went above and beyond to ensure that the site is accessible to visually- and hearing-impaired users. There are SignVideo services for British Sign Language users, and the color contrast meets WCAG guidelines.

      Customers can also request bills in Braille and larger formats. In addition to all of this, the site is compatible with assistive technology.

      5. BBC iPlayer

      The BBC iPlayer home page.

      BBC iPlayer is the BBC’s online streaming service. Its website is where users go to watch programs online. It’s also another fantastic web accessibility example that we can all learn from.

      First, the website is both very easy to navigate and compatible with assistive technology. You can move around the page by clicking on the Tab button. Navigating over the iPlayer logo brings up an option for Accessibility help, which links to a resource page with a lot of useful information for users with disabilities.

      The content is logically laid out, and all buttons use a clear visual design with high contrast colors. There are also keyboard and mouse-accessible tooltips that provide extra information for users and descriptive alt text for all images.

      The video content is also accessible. All shows on BBC iPlayer feature subtitles. There are also audio-described and signed content categories.

      6. NSW Government

      The NSW Government home page.

      The NSW Government website is the government hub for the New South Wales area of Australia. It’s perfectly designed to make it easy for residents of all backgrounds and abilities to use.

      This site features tab navigation, making it simple to navigate pages using a keyboard or screen reader. Thanks to large fonts and contrasting colors, it’s also extremely readable and is compatible with assistive technology.

      7. GOV.UK

      The GOV.UK home page.

      GOV.UK is the central hub for all U.K. government web pages. It can be used to access everything from information about benefits and disability aid to visa and immigration support.

      The U.K. Government has done an amazing job of making its site accessible for everyone who needs it. The site features keyboard navigation and ARIA attributes, making it easy to find pages and navigate the site. It also is adapted to support 300% zoom for visually impaired users.

      DreamHost Takes Inclusivity Seriously

      We regularly report on diversity, accessibility, and representation in the tech industry. Subscribe to our monthly newsletter so you never miss an article.

      Make an Accessibility Statement

      Making sure your website is as accessible as possible is both a moral and a professional obligation. It might seem like a challenge, but it’s worth it. You can simply follow in the footsteps of the web accessibility examples above to create an inclusive website that all users can enjoy.

      Ready to build your accessible website? Let us take care of the technical side for you, so you can devote more of your time and energy to what matters: the design. Sign up for our Shared Unlimited Hosting Plan and get unlimited, secure hosting for all of your websites!



      Source link

      How To Convert a Gatsby Site to a Progressive Web App


      The author selected the Internet Archive to receive a donation as part of the Write for DOnations program.

      Introduction

      Gatsby is a popular framework for turning source material into static HTML files that are ready for instant deployment. Because of this, it is often called a Static Site Generator (SSG). As an SSG, it already has a positive impact on user experience (UX) by turning multiple content sources into an optimized website, but there is another layer available for UX improvement: Progressive Web App capabilities.

      A Progressive Web App, or PWA, is a type of website that goes beyond the usual limits of web capabilities, using newer technology to bridge the gap between your browser and your operating system. PWAs encompass a lot of different features, such as offline browsing, installation support, and newer web APIs. By combining these features, PWAs deliver your users an improved overall browsing experience, as well as the option to use your website like any other application, complete with its own icon and app window.

      Although there is a lot that goes into making an optimal PWA, Gatsby provides tools and support to streamline the process, such as a manifest file plugin (gatsby-plugin-manifest) and an offline plugin (gatsby-plugin-offline). This tutorial will walk you through using these plugins, as well as audit tools like Lighthouse, and by the end you will have learned how to take a Gatsby site and turn it into a fully-functional Progressive Web App.

      Prerequisites

      Before starting, here are a few things you will need:

      • A local installation of Node.js for running Gatsby and building your site. The installation procedure varies by operating system, but DigitalOcean has guides for Ubuntu 20.04 and macOS, and you can always find the latest release on the official NodeJS download page.
      • Some familiarity with JavaScript, for working in Gatsby. The JavaScript language is an expansive topic, but a good starting spot is our How to Code in JavaScript series.
      • An existing Gatsby project that does not yet have PWA support, but is otherwise functional. For satisfying this requirement and building a new Gatsby project from scratch, you can refer to Step 1 of the How to Set Up Your First Gatsby Website tutorial.
      • (Optional) An icon file for your website. In order to be installable, your PWA will need an icon with an original resolution of at least 512 x 512 pixels. If you do not have an icon in mind, this tutorial will instruct you to download a sample icon in Step 2.

      This tutorial was tested on Node v14.17.2, npm v6.14.13, Gatsby v3.9.0, gatsby-plugin-offline v4.8.0, and gatsby-plugin-manifest v3.8.0.

      Step 1 — Preparing Your Content (Optional)

      As a prerequisite, you already have created a functional Gatsby site that can be built and deployed. However, you might not have any content for your site yet. In this step, you will prepare a sample smart home user guide site to demonstrate what kind of content benefits from PWA features.

      As a smart home user guide is something likely to be visited multiple times by the same user, it makes a great example to showcase the main features of a PWA. The app-like qualities of a PWA, such as installation support and home screen icons, make it accessible on both mobile and desktop devices, and thanks to offline support, even when your home network fails, you or other residents can still access the guide.

      Building off the starter template, you can add a new page for the smart home guide under src/pages. Create a file named src/pages/internet-issues.js, and add the following sample page code:

      src/pages/internet-issues.js

      import * as React from "react"
      import { Link } from "gatsby"
      
      import Layout from "../components/layout"
      import Seo from "../components/seo"
      
      const IndexPage = () => (
        <Layout>
          <Seo title="Internet Issues" />
          <h1>Internet Issues - Troubleshooting</h1>
          <p>Having issues connecting to the internet? Here are some things to try in our house.</p>
          <ul>
            <li>Your Device
              <ul>
                <li>Is airplane mode on? Is WiFi enabled?</li>
                <li>Is the device within range of the router or physically connected to the network via ethernet?</li>
                <li>Are you connected to the correct network?</li>
              </ul>
            </li>
      
            <br />
      
            <li>The Router / Modem
              <ul>
                <li>Have you checked the ISPs status page to check for an outage? You can use your smartphone and mobile data to check this.</li>
                <li>Have you tried rebooting the router and/or modem?</li>
                <li>Have you checked to make sure that all physical connections to and from the router and modem are secure?</li>
              </ul>
            </li>
          </ul>
      
          <br/>
      
          <p>
            <Link to="/">Back to homepage</Link> <br />
          </p>
        </Layout>
      )
      
      export default IndexPage
      

      In this page code, you’ve provided troubleshooting instructions to your housemates or guests for when they are having trouble connecting to the internet. You have done so with a bulleted list, providing a link back to the homepage for easier navigation. Since this is a Gatsby project, you’ve created the entire page as a React component, which will nest your list inside a reusable Layout component and return the page as JSX so Gatsby can process it. For an optimized navigational experience, you’ve also used a Link component to link back to the homepage, instead of a regular HTML a tag.

      Make sure to save the file after updating it, and you can go ahead and close it since you won’t need to update it again in this tutorial.

      This page will be accessible at your_domain/internet-issues/, but you will also add a link to it from your homepage to make it easier to get to.

      Open up src/pages/index.js, and add a direct link to the new page within the React component IndexPage, as shown in the following highlighted code:

      src/pages/index.js

      import * as React from "react"
      import { Link } from "gatsby"
      import { StaticImage } from "gatsby-plugin-image"
      
      import Layout from "../components/layout"
      import Seo from "../components/seo"
      
      const IndexPage = () => (
        <Layout>
          ...
      
          <p>
            <Link to="/internet-issues/">Internet Issues Troubleshooting Page</Link> <br />
            <Link to="/page-2/">Go to page 2</Link> <br />
            ...
          </p>
        </Layout>
      )
      

      Save and close index.js with the added link.

      You’ve now built a brand new page for your smart home user guide and added a link to get to it from your homepage. In the next step, you will be adding a special file known as a manifest file, which instructs web browsers on the specifics of your PWA setup.

      Step 2 — Adding a Manifest File

      The next step is fulfilling one of the core requirements of PWAs by adding a manifest JSON file, manifest.json. The manifest file tells the web browser details about your site and how to display it to the user if it is installed on the users’s OS, specifying details such as what icon to use and how it should be launched. You will use gatsby-plugin-manifest to generate this file by initializing the plugin in your Gatsby config file.

      First, install the Gatsby plugin by running the following command in your Gatsby project directory:

      • npm install gatsby-plugin-manifest

      Next, you will provide some details to the plugin that tell it how you want the PWA to appear and act. You do this by editing the main Gatsby config file that lives in the root of your project directory, gatsby-config.js. Open this file and add the following code:

      gatsby-config.js

      module.exports = {
        plugins: [
          ...
      
          {
            resolve: `gatsby-plugin-manifest`,
            options: {
              name: `My Smart-Home Guide`,
              short_name: `SH Guide`,
              description: `Guide for residents of the ABC123 Smart Home`,
              start_url: `/`,
              background_color: `#0a68f0`,
              theme_color: `#0a68f0`,
              display: `standalone`,
              icon: `src/images/pwa-icon.png`,
              icons: [
                {
                  src: `/favicons/pwa-icon-192x192.png`,
                  sizes: `192x192`,
                  type: `image/png`
                },
                {
                  src: `/favicons/pwa-icon-512x512.png`,
                  sizes: `512x512`,
                  type: `image/png`
                }
              ]
            },
          }
      
          ...
        ]
      }
      

      Note: If you have started with the gatsby-starter-default template, you will already have some values for this plugin in your config file. In that case, overwrite the existing values with this code.

      There are a lot of values in this file, so here is a quick explanation:

      • name and short_name should correspond with the name of your site and how you want the site to appear to users when installed. short_name appears on the home screen of the user’s device, or other places where space is limited, and name appears everywhere else.
      • description should be text that describes the purpose of your application.
      • start_url is used to suggest to the browser which page should open when the user launches the PWA from their launcher. A value of /, as used here, tells the browser you would like the user to land on your homepage when opening the PWA.
      • background_color and theme_color are both directives to the browser on styling the PWA, and the values should correspond to CSS color strings. background_color is only used while waiting on the actual stylesheet to load, as a placeholder background color, whereas theme_color is potentially used in multiple places outside the PWA, such as surrounding the icon on an Android home screen.
      • display is a special value because it dictates how your entire site acts as a PWA, and, unlike other fields which support hundreds of different combinations, can be one of four possible values: fullscreen, standalone, minimal-ui, or browser. In your config, the value of standalone makes the PWA act like a standalone application outside the standard web browser. In practice, this means that it acts similar to a native application—it gets its own launcher icon, application window, and the URL address bar is hidden.
      • icon is not one of the standard manifest fields, but is a special field within the context of gatsby-plugin-manifest. By using this property, and providing a path to a file that meets the minimum requirements (at least 512x512 pixels, square), the Gatsby plugin will automatically transform the image into a site favicon, as well as inject into the manifest as the required icons manifest property. By specifying icons with an array of filenames, sizes, and image types, you are invoking the Hybrid Mode Configuration of the manifest plugin. This takes your single source icon file and transforms it into the filenames and sizes specified. This is not strictly necessary, but it avoids any possible issues with deployments in environments like Apache, which don’t work with the default /icons directory.

      Make sure to save the config file with your changes, but keep it open for the next step, where you will be adding another Gatsby plugin and configuring offline support.

      In the manifest values, the path used for icon was src/images/pwa-icon.png, but you still need to place an image file at that location before it will work. If you have a square image file that is at least 512 x 512 pixels, you can copy it to that path. Otherwise, you can use a pre-formatted image file selected for this tutorial. To use the tutorial icon file, either download the sample icon file for this tutorial and save it at src/images/pwa-icon.png, or if you prefer the command line, use cURL from your project root directory:

      • curl -o ./src/images/pwa-icon.png https://assets.digitalocean.com/articles/67869/1.png

      This will download the image to the correct part of your Gatsby application. This is the only image file you’ll need; Gatsby will automatically generate the 192x192 version.

      You have now configured your Gatsby project to serve a manifest JSON file with the correct values, which is a required part of enabling PWA capabilities. In the next step, you will be addressing another requirement of PWAs, offline support, by adding the feature via a service worker plugin, gatsby-plugin-offline.

      Step 3 — Adding Offline Support with Service Workers

      Another key component of PWAs is offline support, which you will implement with a piece of web technology known as a service worker. A service worker is essentially a bundle of JavaScript code that runs separately from all the code tied to the UI of the page you are on. This isolated code is also granted special privileges, such as the ability to alter the behavior of network requests, which is critical for implementing offline support. In this step, you will set up a robust service worker through the gatsby-plugin-offline plugin, configured through your Gatsby config file.

      Start by installing the gatsby-plugin-offline package and adding it to your dependencies. You can do so with:

      • npm install gatsby-plugin-offline

      Next, load the plugin through the Gatsby config, the same gatsby-config.js edited in the previous step:

      gatsby-config.js

      module.exports = {
        plugins: [
          ...
      
          {
            resolve: `gatsby-plugin-manifest`,
            options: {
              ...
            },
          },
          `gatsby-plugin-offline`,
      
          ...
        ]
      }
      

      Make sure to save the configuration file after adding the new plugin.

      Warning: Both the docs for gatsby-plugin-manifest and for gatsby-plugin-offline specify that gatsby-plugin-offline should always come after gatsby-plugin-manifest in the configuration array, as shown in this code snippet. This ensures that the manifest file itself can be cached.

      At this point, you’ve both added offline support and created a manifest file for your app. Next, this tutorial will explain the third necessary part of a PWA: having a secure context.

      Step 4 — Providing a Secure Context

      The last of the three basic minimum requirements for any PWA is that it run in a secure context. A secure context refers to a web environment in which certain baseline standards are met for authentication and security, and most often is referring to content served over HTTPS.

      A secure context can be achieved in many ways. Because of this, this tutorial will describe a few different strategies to get a secure context, then move forward with testing your Gatsby site locally.

      If you are deploying your Gatsby project through a static host, such as DigitalOcean’s App Platform, then it is likely that HTTPS is supported out of the box, with no setup required. For more information on deploying your app on App Platform, check out the How To Deploy a Gatsby Application to DigitalOcean App Platform tutorial.

      If you are deploying on a server that does not automatically provide HTTPS, but you have SSH access, you can use Let’s Encrypt to obtain and install a free TLS/SSL certificate. For example, if you are using Apache with Ubuntu 20.04, you can follow How To Secure Apache with Let’s Encrypt on Ubuntu 20.04 to use Certbot to handle this process. If you are deploying to a shared host, you will want to check their specific documentation pages for if, and how, SSL certificate installation might be available.

      For local testing, you don’t have to deal with obtaining or installing an SSL certificate. This is because most modern browsers treat localhost sites as a secure context, even without a TLS/SSL certificate installed or HTTPS protocol.

      You now have successfully added PWA support to your Gatsby project by meeting the three baseline criteria: HTTPS (or a localhost secure context), a manifest file, and a service worker. The next step is to test and verify that it shows up correctly, with PWA features enabled.

      Step 5 — Running Local Tests

      In this step, you will run some local tests to make sure your PWA functionality is working properly. This is an initial testing step before using the Lighthouse tool for a more comprehensive audit.

      To locally test your Gatsby site’s functionality as a PWA, build it and then serve the generated build directory:

      • npm run build
      • npm run serve

      Once it is ready, you will see the following:

      Output

      You can now view gatsby-starter-default in the browser. ⠀ http://localhost:9000/

      You can now visit that URL in your web browser, and if the browser supports PWAs, you will encounter some special additional UI elements. For example, on Chrome desktop, there will be a new button exposed in the address bar that, when clicked, asks if you would like to install the Gatsby site as an app, as shown in the following image:

      Screenshot showing a popup menu, originating from the Chrome desktop address bar, asking if you would like to

      If you want to test your site locally on a smartphone, this is possible with something like Chrome’s remote debugging tool (Android only), or a localhost tunneling service such as ngrok. On mobile, you will encounter the same option to install your site as an app, as shown in the following:

      Screenshot from an Android device, showing a

      This PWA prompt is different for each device, operating system, and browser. Additionally, certain features such as Add to Home Screen might only be available on certain devices. Certain browsers running on specific devices might not support PWAs entirely; check caniuse.com for more information on platform support.

      You have now verified that your Gatsby project can be built and served locally, with your browser successfully detecting that it offers PWA functionality. The next step will be a final check against what you have put together, and using the Lighthouse tool to check if there are areas for improvement.

      Step 6 — Running an Audit with Lighthouse

      At this point, you have a Gatsby site that meets all the core requirements for a PWA: it has HTTPS, a manifest, and a service worker for offline support. However, the concept of a PWA goes beyond any single requirement—it encompasses all of the facets working together, plus adhering to general guidelines. With this in mind, your last step is to use an audit tool to verify that you meet the baseline criteria, as well as gather information on how you can further optimize your Gatsby project to meet PWA best practices.

      There are a few different ways to audit your site as a PWA, but at the moment the gold standard is the Lighthouse Tool. If you have desktop Chrome installed, you can run an audit against your site directly in the web browser DevTools.

      First, navigate to your Gatsby site in Chrome, then open Chrome DevTools by right clicking anywhere on the webpage and selecting Inspect in the right click menu. Next, click the Lighthouse tab under DevTools. If you don’t see it, click the >> label next to the right-most tab to show tabs that are hidden due to size constraints.

      Now, to actually run the report, uncheck everything on the Lighthouse tab except for Progressive Web App, and then hit Generate Report to analyze your site:

      Screenshot showing the Lighthouse tab in desktop Chrome DevTools, with only the Progressive Web App report category checked

      You can also generate this report programmatically, via the Lighthouse Node.js CLI. This command will run the PWA-only audit and then open the report for viewing:

      • npx lighthouse http://localhost:9000 --only-categories=pwa --view

      However, using Lighthouse via CLI does not bypass the need to have Chrome installed; this just makes it easier to automate the process.

      The report generated by Lighthouse tells you a few things, broken down into categories. Some of the most important are:

      • Installable: This is the most important category, and addresses whether or not your site meets the three baseline criteria for being an installable PWA—HTTPS, manifest files, and a service worker.
      • PWA Optimized: These are things that you should be doing for an optimal PWA user experience, but aren’t strictly required for your PWA to be functional. Think of these as best-practice suggestions. Some examples of these are creating a custom splash screen to display during mobile app loading, setting a theme color for the address bar, and providing fallback content for when JavaScript is unavailable. If you’d like to look at the full list, check out the official Lighthouse documentation.

      By using the Lighthouse tool to audit your Gatsby PWA, you not only now have a functional PWA, but also have an idea of how it meets PWA requirements and best practices.

      Conclusion

      After following these steps, you now have a Gatsby site that can also function as a modern installable Progressive Web App, with strong offline support. You are now providing your users with the best of both worlds: They can browse your site as a normal web page, but they can also use it as they would a native application, with its own launcher icon, display window, and the reliable performance they expect from native applications.

      If you are looking for more ways to deliver the most optimized PWA experience possible, in addition to the Lighthouse PWA audit, Google also has a published a PWA checklist that will help. If you would like to read more on Gatsby, check out the rest of the How To Create Static Web Sites with Gatsby.js series.



      Source link