Learn how to convert your Single-Page Application (SPA) to Server-Side Rendering (SSR) on AWS. Explore the benefits of SSR and its impact on search engine optimization. Additionally, discover key techniques for implementing SEO, analytics, and user tracking to improve privacy, performance, and user engagement.
Introduction
We have one of the fastest serverless websites out there! However, having a fast website alone doesn't guarantee traffic, views, and engagements. That's where SEO and analytics come into play. In this article, I will guide you through the most efficient practices to help you achieve your goals without the need to read hundreds of articles. Let's get started so you can hit the ground running!🏃
The problem with SPA
Yes, you are right! Why does there always have to be a problem?
Let's put it this way: you're reading an exceptional article, one of the best, and you decide to share it with your friends. You click the share button and choose your favorite social media platform. A new window or tab pops up, and you write a captivating caption like, "Look, guys, this article is lit 🔥" and click "Publish."
How disappointing it is when the article doesn't have a title or a preview image? Believe me, a lot!
Alright, the lack of article previews may be a minor issue that you can overlook. However, let's look 2 more related problems.
Lack of Meta Tags
You know when you search on Google for something like "optimizing content delivery: S3 caching and CloudFront" and the article you're referring to appears right after the search query?
Well, with SPA, this doesn't happen. Since you have a Single Page, search engines only have access to a single set of meta tags, resulting in only one title and one description. If you're running a blog, it's like running a full marathon with a huge rock on your back 🥉.
Slower Load Times
Although our cache helps mitigate this issue, SPA still needs to load all JavaScript files before the website can run. It's not as critical as the lack of meta tags because caching can fix it, but it's still a factor to consider.
The solution is SSR
Server-Side Rendering (SSR) provides the solution to the problems faced by SPA. SSR involves rendering the website on the server and sending back a fully-rendered HTML to the client. This approach allows search crawlers to easily access and understand the content. Moreover, SSR enables customization of each page's meta tags and significantly improves initial page load times, resulting in better performance.
Nowadays, there are numerous frameworks to choose from. If you have been following my series, I opted for SvelteKit, which fortunately supports both SSR and SPA. This compatibility should make the transition relatively smooth and painless 👌.
Converting SPA to SSR on AWS
As it turned out, the process was quite the opposite of painless, a blood bath 🩸.
In the case of SSR with SvelteKit on AWS, there weren't many readily available libraries. While there was one existing library, it was not actively maintained and didn't provide the level of customization I needed. Therefore, I took the initiative and forked the library to create my own solution.
You can find the original library here: https://github.com/MikeBild/sveltekit-adapter-aws. You can see the author knows it's stuff.
Armed with a lot of patience, I dug deep into the project and identified numerous areas for improvement and updates. The existing infrastructure was well-built and impressive. Here's an overview of the initial architecture:
And this is how I managed to make it more complicated then it should be:
However, I needed to integrate it with our existing CloudFront distribution, which added complexity to the process. I had to create a custom resource to preserve all the new origins and cache behaviors within the existing distribution.
⚠️ If you don't know what I'm talking about, you are missing out on a really good post! You can find it here 👇
https://depascalematteo.medium.com/building-a-lightning-fast-serverless-blog-on-aws-with-sveltekit-part-4-5ca74d6dfa4a
You can find the updated npm package here: https://www.npmjs.com/package/@mdepascale/sveltekit-aws-adapter
While the documentation may not be extensive at the moment, I'll make sure to document it at my best. Additionally, I welcome any contributions to make pull requests to enhance the library.
SSR Results
The journey of converting from SPA to SSR was an enjoyable one, but now it's time to evaluate if it was truly worth it. To determine the impact of SSR, I used https://www.linkedin.com/post-inspector/ to check if crawlers can preview images and titles.
The results were positive, as crawlers were able to preview the images and titles. This is a significant victory ✅.
Next, I assessed the performance of our website using Lighthouse scores 🚀.
The migration to SSR yielded excellent results, with our website achieving the desired scores.
Now we are fully prepared for the next phase 🏆!
Top SEO Best Practices for Bloggers
Now, let's delve into some of the top SEO best practices for bloggers.
Title
Ensure that the title is between 50–60 characters in length and includes our primary keywords.
Description
Keep the description within the range of 150–160 characters and incorporate our primary keywords once or even twice.
Content
The sweet spot tends to be around 1500 words. If the content exceeds this limit, consider splitting it up. However, it's important to note that there may be some exceptions to this guideline, as it can vary based on the subject matter and context.
Header tags
Utilize header tags (H2, H3, H4) effectively throughout the content. Remember to maintain proper order, and reserve H1 for page titles.
Sitemap.xml
Creating a sitemap.xml file helps list all the pages on our website, enabling search engine bots to crawl our website more efficiently.
External links
Include links to reputable sources within our content. This not only enhances the credibility of our website but also earns bonus points when other websites reference our content.
Content freshness
Search engines prioritize fresh and up-to-date content. Therefore, updating our content ensure it stays relevant. Moreover it will help us study consistently 🤓.
Privacy-Friendly Analytics
Without analytics it's like walking in the dark without any light. We need to track visits, visits duration, users behavior and so on so forth.
Nowadays, before reading something online, you need to give access (deny if they let you) to cookies, privacy policies, TOS, newsletter signups…. I just want to read a few interesting paragraphs, I don't want to buy a car!
That's where Plausible comes in. Let's explore why it rocks:
- Really easy to use;
- Privacy friendly;
- Lightweight library;
- Open source;
- Open source (Yeah, I really like this part).
Let's look at some of the things we can do with Plausible.
Starting with Plausible
Using Plausible is straightforward. Simply copy and paste the following script in your app.html file:
<script defer data-domain="yourdomain.com" src="https://plausible.io/js/script.js"></script>
And just like that, it starts recording analytics data right away!
Proxy though CloudFront
Sometimes adblockers block analytics (thanks bad analytics!). To overcome this issue we can set up a proxy from our domain to the analytics domain.
Here's an example: if your domain is my.domain.com, you can proxy every request to my.domain.com/api/event to analytics.com.
With CloudFront, this process becomes easy. You'll need to create a new origin and two custom behaviors. Here's the guide, if you are looking for it: https://plausible.io/docs/proxy/guides/cloudfront
Add outbound links tracking
Tracking outbound links can provide valuable information, from monitoring link clicks, to assessing the effectiveness of affiliate marketing campaigns. Here's an example script to add outbound links tracking:
<script
defer
data-domain="yourdomain.com"
src="https://plausible.io/js/script.outbound-links.js"
></script>
As you can see, adding ".outbound-link" in the script's URL was enough!
Find out how many 404s
Plausible natively supports tracking 404 errors. To set it up, create a goal named "404" and add the following two scripts. The first one goes inside app.html:
<script>
window.plausible = window.plausible || function() {
(window.plausible.q = window.plausible.q || []).push(arguments)
}
</script>
And the second one goes inside your 404 page:
<script>
plausible("404", {
props: {
path: document.location.pathname
}
});
</script>
What about custom events?
Implementing custom events with Plausible is simple. We can modify our HTML classes as follows:
<!-- before -->
<button class="some-existing-class">Click Me</button>
<!-- after -->
<button class="some-existing-class plausible-event-name=Button+Click">Click Me</button>
Just make sure to create a custom event goal named "Button Click" (without the "+").
Plausible provides an easy-to-use, privacy-friendly, lightweight, and open-source analytics solution. By following these steps, you can gather valuable data while respecting user privacy.
You can find all the code here: https://github.com/Depaa/sveltekit-blog-template 😉. I'll update this repository with every new version, if you like it drop a star ⭐.
Conclusion
In this blog post, we've highlighted the issues with SPAs and provided a guide on converting to SSR on AWS. One key advantage of SSR is improved SEO, driving traffic to our website. However, SEO is incomplete without analytics. That's why we delve into Plausible, a privacy-friendly analytics solution. With Plausible, we can gather valuable data and gain insights to make sense of our SEO efforts. By combining SSR, SEO best practices, and privacy-friendly analytics, we create a powerful recipe for growth and success 💯.
Shout out to Gianmarco Pettenuzzo who's helping me developing the website✨
This series is a journey to production, and we have many more blog posts planned, here the list I'll try to keep updated:
- ✅ Serverless infrastructure on AWS for website;
- ✅ Serverless backend api on AWS for website;
- ✅ Building a high performing static backoffice on AWS with SvelteKit;
- ✅ Building a lightning fast serverless blog on AWS with SvelteKit;
- ✅ From SPA to SSR on AWS: Boost Your Website's SEO;
- Setting up pipelines, monitoring, and alerting for website;
- Deploying website to production;
- Implementing Disaster Recovery strategies while going multiregion with serverless;
- … you see, there are a lot planned, and if you want to add more points just DM me or comment right below.
Thank you so much for reading! 🙏 I will keep posting different AWS architecture from time to time so follow me on DevTo ✨ or on LinkedIn 👉 https://www.linkedin.com/in/matteo-depascale/.
overview of the AWS infrastructure we are going to built to send text notification to users when they enter/exit a particular area;
what is AWS CDK and how to start a project with a simple boilerplate;
geofencing and tracking with Amazon Location Service, well there is also a custom resource with CDK;
sending SMS with Amazon SNS.
Solution overview
Top comments (0)