Leveraging AMP for e-commerce: Eventbrite’s journey to optimized mobile pages (AMP Conf ’17)

So today, I’m going to be talking about
leveraging AMP for e-commerce, specifically
Eventbrite’s journey to optimize our mobile pages. This is very much a
learning experiment for us to start off with,
and we’ve actually been able to implement
a lot of what we’ve learned through
changing our page to AMP into our non-AMP page as well. So I’m Beck Cronin-Dixon– same shirt, different hair. I’m a software engineer
at Eventbrite specializing in search engine optimization. And I was the lead developer
for our AMP project. Feel free to come up during
the conference to chat. I always love a chat. But I’m also available
by email, Twitter, and on the AMP Slack channel,
as I hope most of you are. So first, I’m going
to describe a bit about what Eventbrite does. We’re a self-service
platform for organizers to create, manage, and
promote their events. We have a whole
selection of tools that allows them to create
their best event yet. And most specifically
for this talk, we’re the marketplace
for live events. So our job is to place
organizers’ events where their attendees can see
them, whether that’s through internal search
or through Google or any other search engine. So this leads me to the page
we actually implemented as AMP. This is our listings page. It’s the most important
page for our organizer. Therefore, it’s the most
important page for us. This page lists all the
details needed for an attendee to make the decision about
whether they’re going to purchase a ticket or not. They can also, most
importantly, purchase a ticket through this page. The reason we chose this
page rather than, say, something easier
like a landing page was this page has
very high traffic. As I said before, it’s most
important to our organizer. And we’ve also been– we’re always trying to optimize
our pages and make them faster. Currently, this page loads
between two to three seconds, but we’re always
trying to optimize it. And in our AMP version, it
loads at around one second, and quicker with
the Google cache. So we’ve actually
learned a lot from this. So this is our AMP listing page. And it doesn’t seem
like my video’s working. But anyway, as you can see,
the designs are very similar. We decided to do this
because our roll-out plan was to incrementally
roll out, so 10%, 20%, 30%. We’re at 50% at the moment. And we wanted to keep– we didn’t want to
confuse attendees with different designs. Because oftentimes, people will
find the page through Google. They’ll link to it,
and then they’ll come back to buy
tickets on desktop. So we wanted them to be able
to find the ticket button very easily. So before we were allowed
to undertake this endeavor, we had to meet
some requirements. Product laid this out for us. First of all, we
had to make sure that we met Eventbrite’s
unique brand expectations. When you land on
any of our pages, we take pride in you
knowing that you’re in an Eventbrite page. We have similar
styles across pages. We’re very strict
with design for that. And also, we have a
beautiful style guide that sort of makes
sure that we have those restrictions in place. Next off was it had to
improve user experience. So not only meet the
same expectations for user experience
as the non-AMP page, but, actually, we
had to prove that we could make this a better
experience overall for the attendee– and not
just through speed as well. So we wanted to take a– so this was an
experiment for us. And we wanted to take also
some learnings from this page and move it to our
non-AMP page as well. Another requirement
we had to meet was the ticketing process
should be consistent. So we have a whole
team that works around like purchase flow and
the ticketing page, and we had to make sure
that, first of all, that attendees could
still purchase tickets, whether it’s a big
on-sale or not. That’s very important. But also that they
saw the same ticketing process in the non-AMP
page and the AMP page. There had to be no
confusion there. We also had to make sure that
some of our real-time data was coming down. So that includes like wait list. Also, we say a ticket is
unavailable if somebody’s in the checkout at the moment. But if they leave,
then that ticket becomes available straightaway. When you have thousands
of people trying to buy tickets, very
limited amount of tickets, you’ve got to make sure you have
that real-time data coming down constantly. Another requirement we had
to meet was maintainability. We had to make sure that if
we built this page that we could be able to scale. If we decide to use
AMP for other pages, we wanted to be able to
use those components, the global components, so
the footer, the header. But also, we wanted
to make sure that we could use the same designs that
we have throughout our site. So were we able to– if we found something
worked for the AMP page, could we port that over to the
non-AMP page pretty easily? And most importantly, we had
to make sure it was effective. This kind of goes back
to all the points, but we had to make sure that we
were doing this for a reason, that the user got
something out of it, not just increased speed–
that’s very important. That’s very much a big
reason why we looked at this. But we also had to make sure
that users were converting. We had more click-through rates. So first I’m going to talk about
the challenges that we faced, how we overcame them,
and some of the lessons that we learned through this. So first up was maintainability. As I said before, we had to
make sure that this would scale. So how did we accomplish that? Because this was
an experiment, we didn’t want to just
go in and use– we’re currently using
Backbone and Handlebars, but we’re porting over to React. So we didn’t want to be
in that like– we didn’t want to make it in
Backbone and Handlebars just to have to port it over. So we actually– what
we’re using as well is Mako templates, which is
Python’s dynamic templating system. It allows us to use a
lot of conditionals. So we’re using that. And because that’s pure
HTML as well in there, it’ll be easier to port that
over to React when the listings page decides to go that way. And it also means that some of
those smaller HTML templates, we can just push over
to the non-AMP page because they are using Mako
and Backbone for templating. So that’s how we do
our templating system, and it allows us to use a
lot of conditionals in there and personalize the page. What we’re doing to
keep our design in line is we’re using Sass
with a Grunt task. The reason why– we were already
using Sass, so that was great. But what we added
to the Grunt task is we actually– we render the
Sass, and then we minimize it. But what we also
do is we strip out any blacklisted tags from
AMP that might be ported over from our style guide. So we’re not using everything
in our style guide. The first thing I did when we
decided to do our AMP pages was like, all
right, well, let me see what happens when I load
our whole style guide in line. Yeah, we went way over. That was never a possibility. And we didn’t want it to be. That’s not what
AMP’s about, right? This is an opportunity to show
that you can limit your CSS, you can optimize
your HTML, and you don’t have to use
JavaScript for everything. So what we did was we’re
using a lot of imports, which I’ll show in a minute,
so we could keep in line with our design. But we also had some
blacklisted coding in there. So the important tag came
up quite a few times, which we shouldn’t have
anyway, but it was in there. We also had charset UTF-8 at
the top of a lot of our files. These sort of code is not
like– it won’t break the page if we strip that out. So I’m stripping that
out of any import files that we’re doing for CSS. And then we just print
it out to the page. So next I want to talk a bit
about dynamic templating. The Mako template
was great for us because we have conditionals. And you can use this if you’re
rendering your JavaScript server side. You can use this as well with
React or Backbone or Angular. But for us, we have a lot
of different event statuses or ticket statuses. So whether it’s a
live or ended event or whether our
tickets are sold out, we show sort of a different
template or a different design. So the example here
of what you’re seeing is the live event
versus the ended event. And you can tell they’re
very different templates. On the ended event, we focus
more on the related events. So people can quickly go
into our site that way. If you clicked on
the View Details, you actually get the exact
same information you see and the same template loaded in
there through an AMP accordion. So we’re using just
conditionals like this, event container is ended. But that makes it
really easy for us. And also, we use a lot
of the smaller files. So I was saying before
that, for scalability, we needed to be able to
share those components. So we’re using AMP
header, AMP footer. Now, this is pretty logical,
but I just wanted to– there’s this myth out
there that AMP is just for pages that just have a title
and the content printed out, and it’s always the same. It doesn’t have to be. You can build it for these pages
that are continually changing. Another thing that we
need is personalization. So for any time we’re
pointing at an AMP page or pointing to an
AMP page on our site, we can do personalization. So that’s like if
the user is logged in or they’re logged out,
we can change it also through those conditionals. So obviously, that
doesn’t work when it’s coming from the Google cache. It’s not too much of
a priority for us. But sometimes, we just like
to have those little tweaks for times that when we are using
the AMP page through our site. So next up, I want to debunk
the myth about the CSS limit, that it limits you
in design-wise. I feel like we created
a beautiful page. We had recently gone
through a redesign for our non-AMP version. And as you saw, that
our AMP version is pretty similar to
our non-AMP version with a few small, little tweaks. So when we started
to build this, we were very worried
about the CSS limit. We’d heard a lot of
stories about people saying we can’t create a nice page. We can’t design for AMP. If you’re really,
truly passionate about optimizing
pages but keeping user experience and design,
then AMP can do that as well. So one thing that
allows us to do that is using Sass, so using
a CSS preprocessor. And it also helps for when
you want to go quickly. So we’re able to use this
complex logic within our Sass. So the first one is actually
us creating spacing classes. So we have a grid unit that are
like increments by five pixels. And that was– I just
had to write like, what, four lines, five lines
of code there instead of having like 20? And even like, I’m not
using a lot of those, but I will be in
other AMP pages. But even doing some
things like that, we still didn’t go over the
CSS limit, nowhere close to it. So yeah, Sass is
great to use for using complex logic within your CSS. It’s also great if you want to– like us, we wanted
to include styles from our existing style guide. Our designers work really hard
to create a cohesive brand image. And a lot of ways
we do that is we limit developers putting
in their own hex codes or their own grid units,
those sort of things. So what we’re able to do is
we store them as variables. And I was able to port
all our variables, which is quite a lot,
into our AMP page from our existing style guide. And none of that gets
rendered into the page. That’s just used when
rendering from Sass to CSS. And I was also able to
use import statements to import existing styles. So an example of that
is the loading spinner for what we’re using
for our amp-lightboxes. I didn’t really want to play
with that animation again. I just wanted the
exact same thing. So instead of having
to duplicate that, I could just import it. Same with our settings. So next, I’m going to
move onto ticketing. So part of our ticketing
process is that– I did have a video here. But what it is is you
click on that green ticket, and we’re actually
doing a new page load. So this is one
place where we had to make a bit of a leeway,
a compromise, as you will. So we need JavaScript. This is a place
where we absolutely need JavaScript on the page. So this is the user
experience here. You click on the Tickets
button, and we actually load a new page, which
is our tickets widget. And as you can see, at the top,
you have a Back to Listings button. That will take you
back to the AMP page. So the reason why we absolutely
need JavaScript on this page is because we have to
deal with wait listing. We have to deal
with real-time data. There is no way around that. And I don’t know if AMP– like, this is a very
niche case for us, and I don’t know if AMP– AMP shouldn’t be for every
single use case either. They’re trying to put
limits, and they’re not trying to force every page
on the web to be an AMP page. Sometimes, you just need
to do something like this or use an iframe. We went with this approach
rather than an iframe because we don’t know how long
those tickets are going to be, like for different places. So this only has four tickets. Some places have
like 100 tickets. We’ve seen forms where
it’s 100 tickets long and a lot of description. So we didn’t want to
stick that on the page. So we decided with
the new page load. We also didn’t want to have
to depend on like a component, like an amp-lightbox that’s
loading an AMP iframe and then loading
our ticket widget. So we were quite
lucky that we had a team that actually had
made this end point for us beforehand so our
organizers could show their own tickets
on their website and you wouldn’t ever
have to leave there. So the great thing
about this too is we have that Back to Listings
button, which still connects the tickets widget to the page. So the user still feels
like they’re in a modal, they’re in that same flow. And as we’ll see later on,
too, that for other places, we need iframes or to show
any of that sort of content, we include that Back to
Listings button there. So it’s a cohesive flow. So another problem that we had
was our user-generated content. So for our listings page, the
organizer is in charge of that. That’s how we want it. We want them to show any
information that they want in a certain limited range. So we were quite
lucky that we already stripped out on Create– we already stripped out CSS,
any CSS or any script tags. So we didn’t really have
to worry about that. What we did have to
worry about was images. And I know what you’re saying. Why couldn’t you just have
done AMP dash, put an AMP dash in front of the image tag? Well, the problem
was the aspect ratio. So we don’t tell our organizers
how to position images within their descriptions. So they can put them
next to each other. They could have them as full
page, anything like that. So there was a couple of things
we could have done with this. What we thought about is
we could have just showed the non-AMP version for any
page that had an image in it. But I didn’t want to exclude
anybody from this experience. So what we ended up doing
was if the organizer didn’t have an image, we’d just print
it out to the page as normal. But if they did, we’d
create an abstract. So we’d strip out
the image tag– this is on the server side–
strip out the image tag, we’d do a character
count limit of 500, and then we’d
print out the page, as you can see up there,
and add a Read More button. When you click the
Read More button, it loads an amp-lightbox with
an iframe inside that prints out the whole image. And then as you can
see from before, we have that Back
to Listings button. So it all looks cohesive. This is a short-term
solution for us. A long-term solution
is on the Create side, we take that aspect ratio and
save it as data attributes. Now, what we could
do on the server side is make a request to s3 to see
how that the image size is. We didn’t want to
do that either. We want this page quick. But what we’ve also
found out and what we’re thinking about
putting on our non-AMP page is that people actually
like that abstract. Sometimes an
organizer’s description takes up– they have
to scroll 50 times just to get to the
venue information or to see the map for the venue. So we’re actually
thinking about putting this on the non-AMP
page as well, because it is a nice
experience, and users are used to clicking the Read
More and it’s opening a modal. Yep, so that was meant to– anyway. Another problem we had was
lightboxes and iframes. So like the description
that you saw, we’re actually using,
in quite a few places, this opening a lightbox that
then loads an iframe for any of our content that we just
can’t get around using just specifically AMP for. So this was working well. I have an Android device,
and I was using Chrome Tools. And for our first iteration,
I was like, all right, this works well. And then we had a testing party. You know– test
early, test often. And we realized that
the amp-lightbox didn’t scroll on iOS. And that wasn’t a bug. That was actually a
decision by the AMP team because the amp-lightbox
is made mainly for images and short content. But I had promised Product
that this was a great design. And then I came back
to them and said, hey, can we just load
the iframe on page? No, no, we like this idea
of a fake modal coming up. All right. So I went and I had a look. What could I do? And I found
webkit-overflow-scrolling touch that I could put on the iframe. So I gave up the
scrolling on the lightbox. That was a decision, but
what about the iframe? I came up with this,
and it worked quite well except we had another
testing party, and I realized that, when
you clicked Back to Listings and then you clicked Back into
the lightbox, nothing rendered. So I was back to square one. I needed help. So I actually went to
the Slack AMP channel and asked if anyone else
was having that problem. I got told, put
up a GitHub issue. That seems like a bug. And so I did. I put one up. And straightaway,
I got feedback. And I got told, actually,
this is a duplicate issue. Somebody’s already had this. I had put my GitHub
issue in November, and this was dated back to July. So it was five
months beforehand. So I was like, oh, OK. So what I did was I sent
a whole bunch of comments, and questions, and
asking and asking. But I was nice about it,
but I put that pressure on. And what I realized was
when I started doing that to that old GitHub issue, more
people started popping up. They started being
like, I want this too. We’re actually thinking
about doing AMP, but we would like the
lightbox to scroll. And so with all of us together,
we actually got like– AMP prioritized this. They actually changed
their mind about what the lightbox should be, what
the functionality for this should be. And so we actually got
an attribute scrollable, which was fantastic. The only problem for me was that
it came out during the code, like just before
the code freeze. So I actually had to wait a
couple of weeks, which, ugh. But anyway, so now
in the documentation, you’ll be able to see under
attributes, scrollable. So with the help of– so this is a case where the AMP
team are looking for feedback. They’re looking for ways
to– like, what’s a priority? What are people looking
for in the community? And that would scroll
if it worked right now. So now I want to go
back to those key points that I’m trying to make and
talk about what us at Eventbrite learned as a whole. So the first is like the
love of the customer. We went down this
endeavor event, not because it was
this cool, new thing, but because we had
a problem to solve. We needed to find a way for– our pages were
pretty performant, but we’re always
looking for more to do. And I went on this– I wanted to prove that we
didn’t need so much JavaScript. We should be like
optimizing our CSS per page. And so AMP seemed
to fit that toolbox. That was the tools
that I needed. So always follow what
your customers want. Always look to enhance
the user experience. And then I want to talk a
bit about the AMP community– that us as developers,
and product managers, and designers,
and whatever else, AMP can’t do this alone. We have a responsibility to tell
the AMP team what do we need. Even if you can’t
contribute, that doesn’t mean you
don’t have a voice. You should get on that
AMP Slack channel, and you should open
up a GitHub issue. I mean, I’ve opened up a bunch
of them, and most of them have been closed as duplicates. But at least my
voice is heard there, and at least they know that
somebody else wants something. I can’t stress enough how our
participation, the community participation,
will make AMP work. You may sit here and think, OK,
AMP’s not what I want it to be. But the only way it is, the
only way that the team’s going to know to push it
in one direction is if we all tell them,
we all talk about it. The panel we just had
up here was fantastic. I bet you the AMP team
are going to go back with a whole lot of
things to discuss and features they
should implement. So next I want to
talk about iframe. I know that people are
like, oof, iframe, jeez. But sometimes, you need it. And Sebastian said it’s
the duct tape for AMP, but that’s not a bad thing. For us, we wanted
to iterate quickly. We didn’t want to sit around
for a lot of things and wait, so we used iframe until a
component became available for us or until we had
another way around it. A good example of this is
our organizer contact frame. I was like, great,
there’s a form. I can use that. But then I realized that
there’s no reCAPTCHA, and that was very important
to us to stop bots. And I put up a GitHub
issue, and it’s coming, which is fantastic. But for the meantime, we’re
doing that whole loading a– you press the Contact Organizer. It loads the lightbox. It loads the iframe. And I have an end point
for that contact form– not the best solution,
but it works. The other alternative was
like to hold off the project until we got the
reCAPTCHA form or not include that, which Product
would not let me do. And last of all, I
want to see this more. I want to see accelerated
mobile pages, enhanced design, and user experience. Everyone talks about
the speed, and everybody knows that– fantastic. But I really feel like the
CSS limit doesn’t limit us. It actually forces us to take on
best practices for CSS as well. It forces us to think,
what’s important? What’s most important
on this page? And it helps us enhance
the user experience. I honestly feel that it’s not
a speed or design and user experience. It’s an “and” right there. These don’t have
to be sacrificed. You can create beautiful
pages with AMP. I think we’ve seen that today. And I want to get people away
from thinking that AMP is just for static sites and for
just using the styling that comes with the components. You can really tweak
those components. You can take a hold of
them and really do a lot. So yeah, I really feel that
AMP has a lot of potential. It’s got a little
way to come, but it’s going to be the community
that helps it along, too. So get out there, get
in the Slack channel, put up those GitHub
issues, be part of it. Thank you. [APPLAUSE] [MUSIC PLAYING]

, , , , , , , , , , ,

Post navigation

One thought on “Leveraging AMP for e-commerce: Eventbrite’s journey to optimized mobile pages (AMP Conf ’17)

Leave a Reply

Your email address will not be published. Required fields are marked *