so i hope you are ready with energy for
the talk okay but if you want an app
that's fine i don't have a problem with
that um so we're going to talk about web
performance okay so i will start
presenting myself really quickly okay
maximilian is my name max is fine i'm
first on twitter
um i'm a mobile web developer so i have
been doing web development since that
browser okay since 1995 so long time ago
uh using front page for example
and as we mentioned before i've been
traveling a lot for doing consulting
training in 66 countries this is my
first time here in serbia
so i'm also been doing training for a
lot of companies and consulting
and you can find content and trainings
uh from me on different providers such
as linkedin learning uh people is known
as linda or safari i have all four a
couple of books okay there is a kind of
a trick there
so because we have original books these
are the original books and those are
translations on languages that i don't
understand
so um
[Music]
the last two books are basically on the
topic that we will be covering the next
35 minutes probably 34 now so uh
performance okay web performance how
many of you are currently creating
websites or web apps
okay
perfect and how many of you are creating
fast websites
okay only 10 and there are a couple of
okay let's see we're going to talk about
that and how you can hack the web
performance how we can push that even
further that's the whole idea of this
talk so i have two goals for this talk
the first one is to show you new tricks
that you can start applying in your own
websites or web apps pretty soon and the
other one is to make you feel bad okay
about what you're doing right now so
let's start with that
so um
i know that you know
that your users are currently not happy
and probably you are losing money
okay you or your customers or your
clients are losing money why because of
the performance or because the web is
slow
your website is slow i'm sorry to tell
you that
so some quick information about this
half a second delay it's increasing user
frustration by 26 percent
okay that's a lot
half a second delay is reducing google's
traffic and that's money for google okay
in terms of ads for example uh 100
milliseconds only uh delay will decrease
amazon's sales by one percent these are
all the information okay so there are a
lot of information data that you can get
on this problem
and i'm pretty sure that you know
that today we are not talking about page
load as a metric there are new uh
metrics that are user-centric not about
like javascript metrics but about from a
user's point of view and we have first
meaningful pain that is when something
meaningful appears on the page that is
not just a line or a background color so
something that the user's
user's brain is currently parsing the
then we have first interactive because
it's not just to see something on the
screen we should be able to interact
with that
like for example scrolling or touching
so sometimes you see a page but it's not
working
okay
and visually complete is finally when
you are seeing the actual content that
is not page load
and i'm sure that you're creating your
own custom metrics because that's
something that it's really important so
what is important for your users what
are you expecting your users to do on
your website on your web app and then
you measure that
and so i know you know that performance
is important and we don't need just the
metrics we need goals because if how
fast is fast
probably you say oh my website is
loading in 15 seconds really fast right
well not really so we need to set our
goals
currently
the goals in the market are around this
first meaningful pain should be between
one and three seconds so the user is
typing the url or clicking on a link and
after maximum three seconds it should be
seeing something meaningful on the page
and that means on not on your computer
and wi-fi that means on any context
including um let's say a low-end device
with a 3g connection with a slow 3g
connection
first interactive has like one more
second to make that content interactive
so to two to four seconds so um now you
need to think about this and see how how
close are you to these goals today
so i know that you're already doing a
lot of stuff like optimizing the network
transfer such as for example enabling
gcp on text-based files on your server
you are currently working with tls and
http 2.
you are using css as appetizer
okay so where here in serbia appetizer
is like a big plate but typically the
appetizer should be small right so css
should be a small
and you should start with that so the
css should be the first thing that
you're going to deliver to the browser
because css will block rendering which
is small and
um as an appetizer and javascript as
dessert at the end
okay we need to defer javascript as much
as possible so javascript is your
baklava basically
so uh
you are already optimizing images okay
you're already creating a great image uh
with with png or jpeg you're optimizing
that
and you have an http cache policy
you are currently using service workers
right everyone is using service workers
right
no
so you should avoid the redirects that
is when you go to a website and that
website says now you know you know what
no no it's not here you need to go there
and you go there it says no it's not
here you need to go there so for example
you type a url and then first you go to
https which is fine but when you get
there it says oh you're a mobile phone
now you need to go to mdot and then you
go to mdot and it says oh you want a
home page you need to go to m dot slash
homepage so all those redirects are
basically wasting time so you are not
doing that
i already know
this is basic web performance techniques
that are you're all doing that stuff
what's the problem
the problem is even with all those
techniques the average time to load the
mobile landing page today is 22 seconds
it's really far away from our goals okay
so it's really far away
so and this is from google by the way so
if
a page is taking more than three seconds
to load
more than half of the user will start
leaving that page at that time so you
are losing users you are losing
conversion you are losing money
because we are not doing web performance
for the sake of web performance has to
to measure with the with with your with
our clock we are doing this because of
conversion okay we want conversion in
our websites so that's why we're doing
web performance
and one of the problems is that we have
been always underestimating mobile okay
since the beginning
so for example today you can say that
it's ios and android but from a web
point of view
is it safari and chrome only
so the answer is no
so if you if you have tested your
website on on mobile browsers it
shouldn't be just ios
with safari and chrome
android with chrome there are a lot of
browsers out there samsung in the
browser uc browser opera mini chrome on
ios that is not actually chrome so these
browsers are currently having like a
good market share so more than three
percent
and that means millions of users that
are currently using those browsers and
also we have facebook that now has a
name facebook mobile browser
what i'm saying is when you the user is
browsing on facebook and clicking on a
link by default that link is not being
browsed in the browser but inside an
in-app browser that in a browser is
using a different engine both on ios and
android so have you ever tried your
website there how it looks like how it
works in terms of performance is it the
same as safari or chrome it's not so um
and it's a lot of a lot of users are
currently on that situation and also
when we are talking about the mobile web
that is more today more than half of our
users on some situations it can be 70
and 80 of your users on mobile browsers
we are typically using cellular networks
and i know that you're thinking about
this oh we have 4g now so we shouldn't
we don't need to worry about performance
we shouldn't need to worry
but to be honest if you look at that
information
that's for a couple of months ago
so less than 30 of the users worldwide
are currently in 4g
okay
and
it's not so much and also sometimes when
you have we are like you're a lucky 4g
device uh user you're also a lucky 4g
data plan user you're also a lucky user
that is currently in a city
with 4g coverage
okay so lucky users on that situation 10
of the time you are downgraded to 3g
okay so it happens a lot i'm currently
in 3g here
i'm in roaming even with the iphone 10
i'm in 3g
so um that happens a lot it's not just
because it's um eastern europe i've been
in san francisco so in the middle of
silicon valley i was driving like
half an hour north and it was in qg
okay juji in the middle of silicon
valley so that happens a lot with our
with your users so you need to be very
careful about that and when we are
talking about 3g 4g or even 5g
um typically your brain is thinking
about bandwidth okay so oh it's fast 4g
is faster yeah it's faster but the
problem is not the bandwidth the problem
is the latency
so if you think about this if you if you
have at home
a 50 megabits per second connection and
you go to 100 megabits per second are
you browsing the web faster
probably not it's better for netflix
it's better for youtube it's better for
downloading big files but not for
browsing the web because when you are
when we are browsing the web browser is
downloading a lot of small files
and the latency if you look there into g
is really big it can be up to one second
that's the round trip time that takes to
get data from the server
3g is better up to 450 milliseconds
4g it's even better like a quarter of a
second but if you compare that with the
home the dsl connection or an office dsl
or cable connection
4g has 10 times
the latency of your home connection so
even those 4g lucky users
have big latency
then that's the problem okay so that's
why we need to push web performance even
further
so we need to hack web performance so i
have here a couple of tricks okay that
uh you're gonna start analyzing and
using in your own websites or web app to
push the web performance further so
we're going to start talking about the
first load how we can hack the first law
so the first time that the user is
accessing your website and it's
currently being downloaded from the
server
we should try to avoid more than one
round trip this is a very extreme case
okay but it's interesting i have i have
done a lot of consulting and we did uh
this trick and it's incredible how fast
you can get the first load
so
in tcp we are not getting too deep into
tcp and networking but basically there
is something known as a slow start so
even if you're not a network engineer
you know that on the internet basically
the data is split into packages okay tcp
packets
so uh the problem is how big are those
packets
okay so if we can try to fit our website
in one packet it will get faster because
it won't need another round trip
that's basically taking the latency
and there is something known as initial
congestion window
that in linux based servers it's around
14.6
kilobytes in fact it's kiwi bytes and if
you don't know what a kibi byte is
google that later um
[Music]
so 14.6 so if you can fit
your your first response from the server
so it's only for the first response this
in
14.6k
it will fit in one tcp packet okay only
one
so the problem you say oh 14 it's not
too much but we are g zipping our files
so that's around 70k of html which for
example for the viewport of a mobile
device it might be okay
if you can fit the html there
cdns are also playing with different
values of this
initial congestion window so you can see
a couple of
experiments going on
on this idea so if you can deliver the
atf content what is the atf content
above the fold so
above default is the content that you
see in the first scroll
so if you can fit the content for the
first scroll on a mobile device of your
website or web app in 14.6k
she shipped
you will
render the content as soon as possible
and you can also embed css and
javascript needles for that first
initial load only and if you still have
a space you can embed the logo and i'm
talking about embedding known an amg tag
with a source logo jpeg or logo png i'm
talking about using base64 and data uri
because we want to embed that in one
html response
another thing that you can do now to
increase web performance is to avoid the
http to https resurrection so we you
should know i'm pretty sure that you
know that you need to move your websites
to https so it's mandatory today every
website should be in tls so https the
problem is that when the user is typing
the url it's not typing https
column forward slash forward slash so
and the browser is going to http by
default so we have a redirect there that
can take around 300 to 500 milliseconds
and we have a tiny budget and
maybe half a second is a lot so we want
to avoid that um
the solution is something known as hsts
and it's
some kind of a protocol
that you're going to add in your in your
http header
and you're going to say on that first
access to http hey browser you know what
my website from now on it's we always in
https so a stop
go into http by default okay so next
time the user will go directly to https
and we are going to save up to half a
second and also when you have this you
can go and opt in into that website and
then a browser such as chrome safari
firefox and edge are taking the list as
a white list pre-loaded in the browser
so a new user
will type your url and if you are in
that white list it will go directly to
https avoiding one resurrect okay
so um after the first load was after the
first
response was sent to the
to the browser we need to hack the data
transfer okay so okay how can we send
the data even faster over over that
network or uh the wireless network so
first i want to talk about something
known as quick
okay there is no typo there that's the
name quick without okay
and it's an experimental protocol
to provide an http 2 based api over udp
and not tcp
in fact if you are using chrome
and you are browsing google website can
be gmail google.com google drive you are
currently browsing the web using quick
okay so um quick will reduce latency
a lot because it's not using tcp it's
using udp uh but it's it's compatible
with http too so basically it's
compatible with uh all your current um
let's say websites and architecture
it has something called zero rt
rtt so round trip time connection
establishment so you can analyze that
later but it means that when the user is
um
coming back to your website it will have
zero round trip time to get that
connection open
okay so it's increasing a lot in fact uh
for the google search pay is increasing
the performance by three percent
a youtube has reduced thirty percent of
buffering
thanks to using quick
facebook has a similar protocol for uh
their app it's improving performance by
two percent and according to google
three quarters of every request on the
web
can be faster if we use quick instead of
uh normal hdb2 quick is experimental but
it's currently available on chrome and
it's there are some works in other
browsers as well and of course you need
to add something on your server so you
can serve your website using quick if
the browser is compatible with quick
okay
cool so um
softly
repeat with me softly
so um this is a new
algorithm
for shiship that will encode your she
sips
compressing more okay it can save up to
eight percent of the data transfer
so the same html when you send that over
the wire or the wireless channel um it
will occupy less bytes
okay
so uh the problem is that it's 80
times slower so it consumes 80 times
more cpu for compressing not for
decompressing
but because it's gc based it works with
ie6
it works with every browser so you can
start applying this on your server and
then you will save data transfer so your
website will appear faster on users
devices and you will save data transfer
in the meantime
and if we wanted to push this even
further there is another protocol known
as broccoli by the way we are talking
about german names here um
in this case you can say up to 25
compared to gsip but it's not just
incompatible so you need a browser
compatible with broadly and so you can
check the encoding header by the way
there are a couple of broadly compatible
browsers today uh including chrome
including some versions of safari and
firefox
so you need to check the encoding header
and then send the broadly version
um
for linkedin for example it has saved
four percent
in loading time so if you take four
percent from here three percent from
here two percent from here okay and
because we have a tiny budget you can
actually save a lot of time and you can
actually be closer to your performance
goals
so facebook has saved in css okay and
also a serving javascript files using
broadly and by the way with broadly
remember that we mentioned the 14.6k
threshold for the initial response if we
are using broadly we can say we can
store up to 80 85
kilobytes of html
on on one tcp packet
readable streams this is also
interesting is coming right now on some
browsers it will let you process the
data as soon as arrived so let me give
you a quick example it's typically today
if you have a web app it can be a react
application it can be a
angular application or view or whatever
i'm vanilla js so you are downloading a
json file you are parsing the json file
client side and you're rendering
something on the html okay that's
basically the idea but let's say you're
downloading 100 uh
items i know
clients cds whatever you're downloading
so you're starting parsing that json
file only when you have the 100
you cannot like take a chunk of the json
as soon as it's arriving from the
network you're receiving the file using
ajax or the fetch api
you are using you are receiving the file
when you have the the total file
so what if we can start receiving from
the network layer
pieces
chunks of the response and start
analyzing each chunk and start rendering
as soon as
one part of the json is available so
that api is called readable streams is
available on some browsers and you can
start playing with it and it can save on
pain metrics when you are doing uh this
kind of client-side uh rendered
solution
so
that's for the initial
page and also for sending device from
the server to the client
what about
loading the rest of the resources images
videos web fonts style sheets and
javascript files
so um
we have new modern cache control systems
that you can start using
for example
if how many of you are react or angular
developers let's see
okay quite like 20
so you're probably using the cli
probably i don't know or webpack at
least so
these clies when you're compiling your
your apps are creating uh file names
with hash for your resources for example
your your style css
file it's not the styles.css dot hash
like
xh024 dot css and every time you change
that file the name changes so now we
have um
a way
to for the browser to say you know what
instead of doing conditional requests we
know for sure
that that file
will never change because if we are
changing the css file react or angular
cli will change the file name
so we know for sure that it's not going
to change so we asked the browser hey
browser if you have a cached version of
that file use it
because i will never change it on the
server and that's uh known as a cache
control immutable
okay that is currently
available on those browsers in chrome
it's kind of great because chrome is not
supporting it yet but it has a
like a similar intelligent solution that
is
finally getting to the same result
and also there is a common new pattern
um
that is available mostly with service
workers not sure how many of you have
played with service workers
let's see
okay quite a few only one percent
so um
we need to change that but there is a
new pattern there known as a stale wire
revalidate like you always serve the
file from the cache
okay so from the local cache so you
serve the file really quickly it's in my
local cache so here you have it but it
might be outdated because maybe on the
server you have a new version so then
the browser is updating that in the
background so the next time you request
that resource it will be updated that's
known as statewide revalidate if you
have played with service workers it's a
common design pattern and now that
design pattern is coming to browsers so
you can specify that you want to use
that behavior stale where we validate
and the browser will do that for you it
will give you the cached version when
you are actually i mean an img tag and a
script
it will it will take it from the cache
but in the background it will go and
update the resource for the next time
okay
warming up engines
so when the browser is trying to
download uh
resources we can try to warm up the
engines and help the browser to start
some processes as soon as possible for
example dns queries when you are
downloading files from a different
domain from different origin
uh a dns query is needed so you can
like change resolve the name to an ip
address and that might take up to 200
milliseconds and that's a lot because we
have a tiny budget so and also
connecting to tcp and the tls connection
can be another 200 milliseconds when you
are connecting to another server
so we can announce dns queries as soon
as possible at the top of your html you
can add a link with a rel dns prefetch
and you're announcing the browser hey
browser later i will request a file from
that server so you can start the dns
right now beforehand
also you can use preconnect in this case
it's not just the ens query it's also
going to create the tls and tcp
connection to that server okay even if
the browser doesn't know that you will
need the resource from that server
and on both
you can use an http header instead of
html so when you are answering with your
html you are going to say hey browser
you know what later this html will need
this than this domain so let's start the
connection right now
to bundle and not to bundle so what is
this
so this is a typical question that i
receive in terms of javascript and css
so um
typically you have 10
50 100 css file and javascript file i've
seen that
um so should we create like one big
bundle or should we create a lot of
script tags and link tags for different
files on http 2
bundling seems like an admin pattern
however it's not
banding is still a good idea in fact
this is a tweet from paul irish saying
that from the the chrome team saying
that today
band is still the best possible ideas to
create one big javascript file one big
css file but big however here i'm
talking about only the necessary content
for rendering initial
rendering not the whole website or page
so we need code splitting first
and then
for the initial rendering only one file
okay so that's the idea so don't create
a find mega by javascript file because
that's not the idea it should be really
small only for the important part and
then you
defer and download the rest
so web fonts
web fonts are nice okay we can change
the default fonts that we are using on
websites but we have a problem that
probably you have seen that
the flash on and off and style text what
is this you access a website you see the
logo you see the background and no text
and text on the web
was always non-blocking text was just
text it was there by automatically we
don't need to wait but now when we're
using web fonts we are waiting for the
font
and that's a problem so
now you have on css a way to define how
do you want to load this with phone
display so look for phone display so you
can specify the algorithm so you can
create a more performant solution for
this and finally for resource loading we
have preloading
so uh preloading is even uh like a
better
way of the pre of prefetching or the dns
prefetch or the pre-connect so it's we
are pushing it even further we can help
the browser prioritize the most
important resources for example the font
file
okay so you use a link rel preload
and you're going to say this is a style
sheet this is a web font this is a
script tag and you will need it later so
but i start downloading it now
so we can help the browser to download
the most important files
sooner
with more priority okay and that will
save a lot of time for your
metrics
you can also of course use an http
response header in instead of a link
type as well
hacking images
so we know that the picture is worth a
thousand words the problem is that if it
loads
okay so we need to load pictures
so first you need to embrace responsive
images okay that means you need to
deliver not one image not three versions
of the image okay because today a lot of
traffic is coming from images and you
can improve a lot your metrics if you
create end versions that is the version
that is exactly the one that is needed
for that particular user
also it's time to replace normal
standard jpeg and png files
remember softly the one i mentioned
before for gcp
the same algorithm works over deflate
and png are using deflate meaning that
you can compress your png files 20 more
using this new algorithm okay and it
works everywhere because it's still png
and also we have a jpeg version of this
it's called ghastly another german name
uh that will let you in like compress
your jpeg files even more without
reducing quality
so these are new compression algorithm
that are open source are available right
now so you can start uh helping your
users with uh performance okay so start
working with that
and the last thing that i have for you
has to do with how to hack user
experience
so
with something known as reactive web
performance
so
i'm pretty sure that if you're a netflix
user you have seen this in action from a
network point of view it's difficult to
see netflix with a buffering
system typically netflix is changing the
quality of the streaming as soon as the
pathway is changing okay this is a
similar idea about the web
so we can know about the context today
using client-side performance apis
network information api device memory
client hints apis so basically you can
detect the current connection of the
user
the bandwidth the latency you can detect
the current available memory so you can
know if it's a feature phone
if it's the latest android device and
make a decision about that
because maybe you have the latest
android device the latest iphone device
but you are in 2g in roaming so it
doesn't make any sense to send a very
super high quality ultra resolution to
that device because it will never arrive
and that's a bad experience we need to
keep the the user the the consistency
and the consistent experience so for
example if you're in roaming don't send
web fonts
we can change the service workers cache
policy so if we are in 2g
we'll say okay let's go first to the
cached version
because it will be slow and we want to
improve users experience
we can reduce the amount of loaded data
and maybe
you can send a low resolution image not
matter the device pixel radio or the
resolution okay you might have a 4k
screen
but if if you have a very slow network
it doesn't make any sense to send that
picture you can just then send a low
resolution image
so are you feeling bad now
about what you're doing
yeah no yes
so
performance is top priority okay if you
want to succeed on the web on web apps
it's operating because it was proven
that it has to do with conversion it
will give you conversion so you need to
push it even more you need to start you
need to learn how to
uh measure with the new metrics and it's
a really worthwhile effort so okay so
please please take uh take time and
to improve the performance of
your website okay please please do it
so
um that's an iphone okay by the way um
make it fast please so that's all for me
so thank you
and see you later because i have another
talk on progressive web apps on the
other room okay
thanks