SearchLove San Diego 2018 | Mat Clayton | Site Speed for Digital Marketers

Editor's Notes

• #2: Hey I’m Mat, I’m the CTO and Co-founder of Mixcloud. Mixcloud is the online radio hosting platform of choice for todays DJ’s and radio stations. I’m a techie at heart.
• #4: Rankings
• #5: Mobile Rankings I would argue that Site Speed on Mobile just makes the problem more obvious
• #6: 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
• #7: 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.
• #9: 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.
• #10: TTFB - Time to First Byte
• #12: 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
• #14: Explain about 3G testing Multiple runs Videos
• #16: Explain about 3G testing Multiple runs Videos
• #17: Explain about 3G testing Multiple runs Videos
• #20: 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.
• #25: Use a CDN, is often wrong. You might have to confirm some domains are on your CDN. Also timings etc on Google Analytics
• #26: Use a CDN, is often wrong. You might have to confirm some domains are on your CDN. Also timings etc on Google Analytics
• #28: This will flip to Mobile mode, I’ve not yet figured out why
• #29: 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
• #36: 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.
• #38: You want to see h2
• #39: Sharding hurts in HTTP2 world
• #41: Static assets are things which don’t change
• #42: 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.
• #43: Removes white space Collapse variable names down Essentially make it a whole lot smaller, less bytes == less to download and less to parse
• #44: 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
• #45: 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
• #50: 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.
• #52: Note the (from memory cache) 0ms
• #57: “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.
• #58: A site on optimising images, is still getting this wrong
• #59: - 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.
• #65: Under many scenarios progressive JPEG’s will actually be smaller However the perception of speed can help a lot
• #66: 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
• #67: 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
• #69: If you are not caching the CSS you are wasting a lot of time on page render, and parsing. CSSDOM
• #71: 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
• #72: 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.
• #74: If you are not caching the JS you are wasting a lot of time on page render, and parsing.
• #77: 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