AMP Integration with Sitecore

In my previous post on AMP we discussed about what is AMP (Accelerated Mobile Pages) all about, advantages of using AMP,constraints and some of the basic things which we should consider while using AMP with Sitecore.

As part of this blog post- i would like to go further and see how the integration of AMP can be done with Sitecore.

amp-project

Before we start i want to re-iterate some of the rules and constraints that comes with AMP and obviously all for good reasons.

  • No inline styles
  • All CSS in AMP Page should not be more than 50 KB
  • No custom JS plugin (iframe)
  • Strict validation rules and etc.

We have completed one AMP implementation successfully and want to share how we executed it with Sitecore. We targeted home page as our primary landing page and based on the analytics data we had business idea was to start with home and get some performance improvements there.

Thanks to Sitecore stack exchange which gave me idea on how to get started with this- https://sitecore.stackexchange.com/questions/1597/how-do-i-implement-accelerated-mobile-pages-amp-with-sitecore

Here are the steps we followed in our execution journey.

  1. Create AMP specific device layout to separate AMP and Non-AMP page and we leveraged query-string parameter to differentiate the layout- in our case we used querystring “amp=true” for the same.AMP-DeviceLayout
  2. Sitecore Page layout- As next step we created a new Sitecore layout file which was different from the regular layout file, you can refer the basic version of AMP HTML here
<!doctype html>
<html amp lang="en">
  <head>
    <meta charset="utf-8">
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <title>Hello, AMPs</title>
    <link rel="canonical" href="http://example.ampproject.org/article-metadata.html">
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <script type="application/ld+json">
      {
        "@context": "http://schema.org",
        "@type": "NewsArticle",
        "headline": "Open-source framework for publishing content",
        "datePublished": "2015-10-07T12:02:41Z",
        "image": [
          "logo.jpg"
        ]
      }
    </script>
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
  </head>
  <body>
    <h1>Welcome to the mobile web</h1>
  </body>
</html>

Also, you can have the same placeholders what you have defined in regular layout file, thing which you have to make sure is that you are aligned with the HTML which AMP follows.In addition to this you have to add all the AMP plugins in your layout file, this is again based on what feature you are building as part of AMP page, some of the plugins which we used are:

  1. amp-sidebar
  2. amp-accordion
  3. amp-carousel
  4. amp-social-share

https://cdn.ampproject.org/v0/amp-sidebar-0.1.js
https://cdn.ampproject.org/v0/amp-accordion-0.1.js
https://cdn.ampproject.org/v0/amp-carousel-0.1.js
https://cdn.ampproject.org/v0/amp-social-share-0.1.js

3. Linking AMP and Non-AMP versions– In some cases, you might want to have both non-AMP and an AMP version of the same page, If Google Search finds the non-AMP version of that page, how does it know there’s an AMP version of it?

From https://www.ampproject.org/docs/fundamentals/discovery  – In order to solve this problem, we add information about the AMP page to the non-AMP page and vice versa, in the form of <link> tags in the <head>

Add the following to the non-AMP page:

<link rel="amphtml" href="https://www.example.com/url/to/amp/document.html">

And this to the AMP page:

<link rel="canonical" href="https://www.example.com/url/to/full/document.html">

4. Renderings- Next step would be create separate renderings for the components you are planning to add as part of AMP version of your page. This is to make sure we can support both AMP and Non-AMP versions, prepare list of components that need to be converted to AMP and organize accordingly in Sitecore.

5. Set the presentation layout– Next step is to set the presentation of the page, in our case we had two presentations for the same page- one set for Default layout and one for AMP (Mobile specific) with different set of renderings.

6. Data Bind– As in our case page was already there- we didn’t do anything different to bind the data- we just pass the same data models to AMP renderings and we were all set. You just need to make sure you are calling correct renderings based on the device.

7. Test and Validate- Once you are done with the implementation you need to make sure that AMP page is working as expected, there ware two ways you can verify AMP page- in this case as we used different device for AMP with querystring- we just need to open the URL with correct querystring, so for example- if your page URL is http://www.something.com , then you can access AMP version of it using http://www.something.com/?amp=true

As part of your test you also make sure to run the validations to see if your AMP page version is aligned with the guidelines of AMP. In order to validate the page you can use browser developer console, for example- if your AMP page URL is http://www.something.com/?amp=true , you can append #development=1 to check for any validation errors- http://www.something.com/?amp=true#development=1, see the below AMP validation errors for ref:

validator_errors

8. Deploy–  Once the AMP changes are deployed it may take some time to crawl the page, and once the page is submitted to google you can see your AMP version in google search result with the lightening badge next to it.

google-lightning-badge

URL to verify if page is valid AMP or not- https://search.google.com/test/amp  and provide you AMP page URL.

Valid-AMP

Notes:

  • After the deployment we were able to see the AMP lightning badge in google search results- but few days after it was missing from google search results- we checked this and found that as content authors added some inline styles to one of the field which was making AMP not to submit the page to google because of AMP validation errors.
  • AMP can be used with both Mobile and Desktop, however it is more specific to Mobile user experience to get higher performance and engagement and reduce the bounce rates.
  • If you want your visitors to see AMP version even when the hit the page directly, this can be achieved by adding some device detection rules in Sitecore, we can identify the requesting device and based on which context device can be updated dynamically in Sitecore.

Next Step- As a next step we are checking on making AMP page responsive, but it depends on the components as some components heavily relies on custom JS plugins which can’t be integrated with AMP, there are several components available in AMP as well which can be leveraged, but if same UI & functionality can be achieved while making page responsive can only be confirmed after analyzing existing controls from AMP library- https://www.ampproject.org/docs/reference/components

Making AMP page responsive comes with an advantage that you don’t have to maintain two different versions of the page which make the maintenance part easy- but we should also make a note that we have to work within boundary of AMP guidelines- which sometimes can be a challenging part for responsive design.

I hope this would be useful for guys who are starting with AMP in Sitecore.

Please share your feedback and comments.

References:

Happy learning 🙂

Introduction to AMP and Sitecore

Performance of application is one of the important business KPI (Key Performance Indicators) which heavily contributes to the success of business.There are ways to improve the performance of the website like performing optimization, resources upgrade and etc.

amp

Apart from traditional approaches to improve the performance, there is a lot of buzz and talk going on for AMP (Accelerated Mobile Pages- powered by Google ) these days.

As per wikipedia– “The Accelerated Mobile Pages Project (AMP) is an open-source website publishing technology designed to improve the performance of web content and advertisements. The AMP Project led by Google is a competitor to Facebook’s Instant Articles,[1] and includes several other large search, social and web publishing platforms around the world.”

As part of this blog post– I would like to discuss if AMP can be leveraged for Sitecore applications, advantages and disadvantages and what are some key points to be considered before we plan to integrate AMP with Sitecore.

Advantages of AMP:

  • Speed and Performance-AMP provides a great user experience across many platforms
  • AMP complaint content always gets displayed first in search(organic search).
  • Increased mobile device site loading.
  • Boost in Ranking.
  • Reducing the page bounce rate and better conversions.

Constraints:

  • No custom JS/Plugins allowed, which can affect some of the execution efforts like Pagination, listing, search,etc..
  • All CSS in AMP Page should not be more than 50 KB.
  • Multiple Versions required (AMP and No-AMP).
  • Increased development time- Increases developer time in 2 times(AMP and Non AMP layouts).
  • Strict validation rules
  • Inline CSS styles.

To Consider:

Now, before we proceed for Integrating AMP with Sitecore, let’s check following:

  • Impact on Analytics and Sitecore Analytics?
  • How it affects the website functionality, like carousels, products and other features?
  • Impact on Personalization in Sitecore?
  • Do we need separate layout or can be managed with same default layout.

Though we know AMP is a performance booster, but it’s worth to check above points and do a analysis to understand the Integration.

Apart from just AMPiying your website another important factor is to analyze and understand what pages should be migrated to AMP like:

  • Home page
  • Landing pages and other top performing pages which contribute to the overall business.

Also, when when AMP should be served?- when user is trying to search contents from Google- via organic search(this is default behavior) or when user hit your page directly is a point of discussion and depends on business requirements, Let’s discuss above points as part of my next post on AMP.

Case Studies:

Here are some case studies are available and can be used as reference to understand it better.

I am very excited about AMP and it’s integration with Sitecore, i am pretty sure you guys are too?. I hope this give you a starting point and makes you think about AMP and how it can be leveraged with Sitecore.

References:

Happy learning 🙂

Sitecore | Shared vs Final layouts

One of the new features of Sitecore 8 is the introduction of versioned layouts.

Language Version Layouts give content editors the ability to create different layout definitions for each language version for an item. In Sitecore 8 there is now a Shared Layout and a Final Layout tab in the presentation details dialogue of an item. This is where the magic for the versioning is configured.

The Shared Layout section stores the renderings that are shared across all language versions of an item, while the Final Layout section, stores the renderings that are specific to the current language version you are editing. The Final Layout details panel displays the final combination of presentation details, and determines what is rendered when viewing the current version of the item.

imagelayout

This new feature allows Sitecore users to design and market pages based on different languages. Content editors can now not only update the datasource on a component based on personalization rules, but can also present a different layout structure, including or removing components per language version.

This gives the content editor and marketing team a wider range of variations. If a multi-language site has a different marketing plan or promotional offers based on the language, marketers are no longer restricted to rendering the same components for all languages. The language version layouts open many doors for a customized user experience.

There are however some things that Sitecore users need to remember about this new tool. Currently there isn’t a way to update the shared layouts field from the Experience Editor.

***********************************************************************

Question : What layout do you modify when you edit a page in Experience Editor?

Answer: Final Layout

Before Sitecore 8 regardless of item or language version, it used to update the shared layout,as there was no final layout present.when we open a page item we basically create a delta against page template, and will be presented with the page layout with the delta merged which gets updated to _Renderings field.

From Sitecore 8, we still create delta of what we have in the page template, but the page layout will be presented and updated to _Final Renderings field, which is versioned per language.

Please share your feedback and comments, as how we can make this a great learning platform, much appreciated.

Happy learning 🙂