Is Laravel Livewire SEO friendly?
Share

Is Laravel Livewire SEO friendly?

Kornel M. Novak

Intro

Laravel Livewire is on the hype recently. It promises to use the same stack on the backend and frontend with Laravel. By using Livewire, you can create dynamic interfaces like with Vue.js or React. Because, at the end of the day, not everybody has the aspiration for front-end development.

SEO compatibility requirements appear with almost any web project which has public pages. Vue.js, React and Angular is not the technology of choice for SEO optimization for many developers. Due to the complexity of rendering, the developer has to do extra efforts to provide accessible HTML content for the web crawlers. (Yes, we're talking about SSR)

The promise of Livewire is that it is completely SEO friendly. At the end of the request chain, it renders as any Laravel Blade template.

So let’s dive into and check out if it is more suitable for SEO-optimized development than SPA frameworks.

But what does it mean to be SEO-friendly exactly?

Search engines, Google and Bing (and some smaller ones), are using bots to crawl the web. The goal of such a bot is to learn what (almost) every webpage on the web is about. Then bots are helping to store the information so it can be retrieved when needed. They create information cards based on the title, description, and content of the page. When a user tries to find something on the web these cards help search engines show the most relevant information to their search queries.

The bots, called crawlers are not capable of running JavaScript code asynchronously. They can only see what is available at the moment of accessing a page. If your framework of choice (Next, Nuxt, etc.) is not capable of turning reactive templates into pre-rendered HTML pages you’re in for SEO trouble.

Creators of these frameworks took note of the problem so they began to provide server-side rendering (SSR) solutions. Next.js utilizes SSR from the ground, for Nuxt.js you have to opt-in at the start.

To make the SSR approach work, you have to understand the requirements of your client. But this is only the first step, you also have to plan the architecture in sync. This is hardly the case for most of the Web projects. Clients are changing specifications every minute. So rewriting everything gets costly through execution.

There are also some constraints on the usage of SSR style framework modes listed by the Vue.js SSR guide:

  • Some external libraries may need special treatment to be able to run in a server-rendered app.
  • More involved build setup and deployment requirements. Unlike a static SPA deployed on a static file server, a server-rendered app requires a specific environment to run.
  • More server-side load. Rendering a full app in Node.js is going to be more CPU-intensive than serving static files. If you expect high traffic, prepare for the server load and use caching strategies.

Lately, developers started using Static Site Generators to solve the complexities of SSR. With generators, static site rendering happens on the backend, based on data and template definitions. So for pages with small content changes, we also suggest using SSG instead of SSR. One of the many frameworks to do that is VitePress.

How does Livewire create HTML pages?

Livewire components are completely stateless. The magic happens behind, so it appears that the components own some kind of state. But actually, each interaction with a Livewire component calls for the server. The plugin fetches every information change from the server, via AJAX requests. When, due to user interaction, the server response changes data on the page, Livewire handles updates on the DOM.

Interactions in components happen using Livewire attributes on the DOM. That tells Laravel that Livewire's inner logic must handle the element's action.

<input wire:model="search" type="text" placeholder="Search users..."/>

Crawlers will only see the initial state of the Livewire components. That is why components are SEO-friendly, but only at their initial state.

If you want to know how Livewire rendering is different than Inertia.js's, please read our article about Inertia.js vs Livewire.

Is SEO optimization needed for initial loading?

Livewire is tightly integrated with the Laravel framework. That means, in the back, Livewire uses Laravel’s render engine to create the initial HTML template.

Caching of components is also handled via the Laravel cache storage. That means, you can rely on Laravel caching techniques to optimize page loading times.

Livewire, on the front uses a handful of JS code to communicate with the backend. The plugin verifies any tempering activities with the front-end code by using timestamps, so theoretically the Livewire frontend plugin could slow down page loading time. But since most of your code will live on the backend, the size of manual JS code will be small. Yet it is still important to minify your JS assets for faster loading times.

Also, let's not forget that Livewire delegates most of the heavy work to your server-side. That means the server must handle all the business logic. Especially in high-load environments, this requires some optimization from the developer's side.

There are some HR benefits to Livewire as well. The learning curve is much lower. Most programmers, especially newcomers, are eager to work only on the backend. Yet small companies don't have enough resources to separate backend and frontend roles. Learning web development with Laravel and Livewire is a better experience for them. Also, don't forget that Vue.js and Javascript can be overwhelming.

So to wrap-up, we like the benefits of full-stack work on the back. On a daily basis, we don’t think that Livewire sacrifices the SEO benefits of pure Blade templates.

But we want to know what is your experience with Livewire? Do you prefer Inertia or Livewire? Don't hesitate to share some insights with us!