Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

We all know that site speed matters not only for users but also for search rankings. As marketers, how can we measure and improve the impact of site speed? Mat will cover a range of topics and tools, from the basic quick wins to some of the more surprising and cutting-edge techniques used by the largest websites in the world.

Mixcloud is the online radio hosting platform of choice for todays DJ’s and radio stations.

I’m a techie at heart.

Rankings

Mobile Rankings I would argue that Site Speed on Mobile just makes the problem more obvious

No ever bought from a site because it was slower to load, they got to stare at the page for more time. It just doesn’t work like that

I believe Google allocate an amount of time per domain, and therefore the slower the site is the less it’ll scrape. We’ve seen shifts which match this logic in Webmaster Tools, such as the reported one above.

Google has indicated site speed (and as a result, page speed) is one of the signals used by its algorithm to rank pages. They can also clearly measure Site Speed from Chrome and use that as a signal if they so wish.

Research has shown that Google might be specifically measuring time to first byte as when it considers page speed. In addition, a slow page speed means that search engines can crawl fewer pages using their allocated crawl budget, and this could negatively affect your indexation.

Google has indicated site speed (and as a result, page speed) is one of the signals used by its algorithm to rank pages.

And research has shown that Google might be specifically measuring time to first byte as when it considers page speed. In addition, a slow page speed means that search engines can crawl fewer pages using their allocated crawl budget, and this could negatively affect your indexation.

TTFB - Time to First Byte

80% of load time is once the page is sent to the browser. TTFP - Time to First Paint TTFMP - Time to First Meaningful Paint TTI - Time to Interaction FPS - Frame Per Second, interaction speed

Explain about 3G testing Multiple runs Videos

Explain about 3G testing Multiple runs Videos

Explain about 3G testing Multiple runs Videos

Major issue with this, is that is measures async and external scripts as well, which in our case don’t block rendering, and can easily be loaded after the effect.

Use a CDN, is often wrong. You might have to confirm some domains are on your CDN. Also timings etc on Google Analytics

Use a CDN, is often wrong. You might have to confirm some domains are on your CDN. Also timings etc on Google Analytics

This will flip to Mobile mode, I’ve not yet figured out why

It swaps to mobile, I’ve not seen a good way to keep it on Desktop yet, which can be an issue if you have 2 different sites

HTTP Head of line blocking

Head of Line blocking (in HTTP/1.1 terms) is often referring to the fact that each client has a limited number of TCP connections to a server (usually 6 connections per hostname) and doing a new request over one of those connections has to wait for the previous request on the same connection to complete before the client can make a new request.

HTTP/1.1 introduced a feature called "Pipelining" which allowed a client sending several HTTP requests over the same TCP connection. However HTTP/1.1 still required the responses to arrive in order so it didn't really solved the HOL issue and as of today it is not widely adopted.

HTTP/2 (h2) solves the HOL issue by means of multiplexing requests over the same TCP connection, so a client can make multiple requests to a server without having to wait for the previous ones to complete as the responses can arrive in any order.

You want to see h2

Sharding hurts in HTTP2 world

Static assets are things which don’t change

These tools essentially take the code your developers produce, and process it in ways that make it run on the browser and as part of that they optimise it for the browser as well.

Removes white space Collapse variable names down Essentially make it a whole lot smaller, less bytes == less to download and less to parse

Developers are lazy, this essentially finds the code they don’t use and stripes it out.

Tree shaking is the concept of removing dead code by analysis, and can radically help you to reduce the size of your Javascript bundles

For example on Mixcloud we download just the Javascript you need, then we will download the rest in the background as you need it.

Reduce the bytes at the start and ready for when the user needs the code

Ideally use Content addressable urls, these should automatically update on the content changing.

We use Hashes of the content. if not ?V=1 would work.

Slight preference for putting it in the name and not the query params as some caches can ignore them.

Note the (from memory cache) 0ms

“Images are still the number one cause of bloat on the web.” If you do one thing make after this talk Fix your images! They account for a huge amount of Content on the page, and are usually fairly easy to fix up.

A site on optimising images, is still getting this wrong

- Vector / Raster - SVG/CSS3 or even Font’s are great for simple shapes - You can use fonts instead of SVG’s if you so wish.

Under many scenarios progressive JPEG’s will actually be smaller However the perception of speed can help a lot

You can either set the image color, or you can use a very tiny blurred version and load these in quickly. This will only give you a perception of speed and won’t help with actual speed, infact it’ll make it slightly slower

You can either set the image color, or you can use a very tiny blurred version and load these in quickly. This will only give you a perception of speed and won’t help with actual speed, infact it’ll make it slightly slower

If you are not caching the CSS you are wasting a lot of time on page render, and parsing. CSSDOM

The main issue with this, is the CSS might be needed on another page, but its not a bad place to start looking for way to save bytes

A flavour of what is possible, We can at pageview calculate the necessary styles to render a page, and only send down that CSS, so the page render is super quick and removes all css bloat.

If you are not caching the JS you are wasting a lot of time on page render, and parsing.

Most ad and tracking scripts want to run inline, and aren’t good neighbours. If you see them running before the all important First Paint line in the waterfallls, find a way to contain them and at least rewrite their <script> tags to be async

6.
GoogleBot will crawl more pages
Read more: https://mitchfournier.com/2011/08/03/reducing-page-load-times-dramatically-increased-my-googlebot-crawl-ra
This is due to Page Speed, which is a component of Site
Speed.
We’ve seen shifts in indexing based on Site speed as well
but often less pronounced.

9.
Page Speed: Time To First Byte
Essentially how fast can you get the HTML to the
browser

10.
Read more: https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics
Site Speed: Can mean many things to different
people
State Purpose Metric
Is it happening? Did the navigation start successfully? Has the server
responded?
First Paint
Is it useful? Has enough content rendered that users can engage with it? First Meaningful Paint
Is it usable? Can users interact with the page, or is it still busy loading? Time To Interaction

34.
- HTTP Header Compression (HPACK)
This will just work, and shaves off a good 1-2k depending on your use of cookies
- Request Priorities
Allows the browser to set request priorities and ensure that it get the most important
ones first
- Server Push:
WARNING this is very very hard to get right, and you’ll make it worse if you get it wrong
Other benefits of HTTP2

49.
The more elements in the HTML:
• The more bytes there are to download
• The slower the Javascript interactions will be
• The slower scrolling will be
Be especially careful with any parts of the HTML which involve loops
Reduce the number of HTML elements
Bad
Good
<div id=“my-list-item“>
<li>My Content</li>
</div>
<li id=“my-list-item“>My Content</li>

54.
Vector Images: Use SVG
• Prefer vector to raster images when possible
• SVG are just simple XML files, exportable by all major image editors
• Compress very well using gzip
• Its also possible to build images using CSS3 or fonts

55.
Choose the right image format
Always check the file size after converting the image, this isn’t a hard and fast set
of rules

69.
Remove all the bloat (aka tracking pixels and 3rd party scripts)
At least ensure they are embedded using async, so they don’t block page render
I would recommend you setup a regular review and remove session.

70.
In Summary
Everything comes down to one of 4 techniques
1. Reduce the number of assets
2. Reduce the size of assets
3. Make the assets load faster (DNS / Caching / CDN’s)
4. Prioritise the order of assets
5. Use HTTP2 ;)
It might not be your job, but hopefully you can now point
your development team in the right direction