Google's Search Signals For Page Experience - SMX Advanced 2021 Patrick Stox

Editor's Notes

• #2: Patrick Stox – Product Advisor, Technical SEO, & Brand Ambassador at Ahrefs Please ask your questions in the chat and I’ll answer in the live Q&A after the presentation. Page Experience was announced about a year ago
• #9: Lots of Google signals are small factors
• #13: I say probably because you could technically still make a page mobile friendly without a viewport but it’s way more work and will be difficult to maintainI’m the lead author for the SEO Chapter of the Web Almanac for 2021
• #14: HTML or CSS fixes
• #21: If you have an issue, there’s a ton of documentation on cleaning up different issues. There’s also the webmaster help forum and they can help guide you.
• #22: Authentication, Data Integrity, and EncryptionYears ago I wrote a very popular guide on migrating to HTTPs on Search Engine Land
• #23: Look for the lock. Fun fact, Google doesn’t actually validate certificates, they just look for HTTPs
• #25: All kinds of things about referral data, using a content security policy called upgrade-insecure-requests to fix mixed content issues at scale, redirects, and more
• #27: You’ll have to visually check for these
• #31: You’ll get a boost for jumping up categories but once you hit good you kind of cap out, there’s not an additional boost for improving after this.
• #33: But it’s basically going to be some kind of image or text
• #37: You know when you click something and nothing happens
• #38: Not all users will interact with a page, so they may not have an FID value. This is also why lab test tools won’t have the value because they’re not interacting with the page. Use Total Blocking Time (TBT) instead.
• #39: Javascript competes for the main thread.  There’s just one main thread, and JavaScript competes to run tasks on it. These get flagged with little red tags in Chrome Dev Tools if they’re too long
• #46: Notice how our font re-styles between 5.1s‑5.2s, shifting the layout as our custom font is applied.I like this view because I can see changes along with the waterfall to see what was loaded at that time.
• #48: This is usually the territory of devs, so you’re generally going to have to work with them. You’ll generally need to sell the idea that speed is important and maybe even do some testing, but it’s rare that SEOs will actually be the ones implementing speed changes
• #49: This is the source of data, metrics taken at 75th percentile of users, so ¾ people are having a good user experienceAt least so far it doesn’t look like sites have made significant improvements. You get some benefit in ranking until you hit good, after that the signal just caps
• #50: Field = real user data, lab data = tested under specific conditions Can you get both lab and field data at scale? Not without the PageSpeed Insights API. We’re planning to add to Site Audit in Ahrefs. You can use that for free in Ahrefs webmaster tools ahrefs.com/awt
• #51: 28 day moving average, so any changes you make will take some time to be reflected hereYou can also track your own RUM data if you want and send to Google Analytics for instance
• #52: You’ll want to look at this to help you prioritize. Look at the issue and click into these and you’ll see groups of pages with the same issue. Then you can look at why specifically they’re not meeting the metrics in pagespeed insights and try to resolve the issues.Many sites struggle with LCP.
• #54: Smaller JS files, smaller CSS files, smaller font files
• #55: CDNs basically give you a way to connect and serve your site that’s closer to users. It’s like having copies of your server in different locations around the world
• #56: If you host your files on the same server, additional connections don’t have to be made
• #57: A browser would typically wait for the HTML to finish before starting a connection, but here it’s starting before it normally would DNS-prefetch has better support than preconnect
• #58: Cached files can also be re-used across pages. So any subsequent page visits will be faster.
• #59: They’re fast for users, but AMP pages may not actually test well in lab tests.
• #61: Preload is similar to what we saw with preconnect for the connections, it starts loading preloaded resources earlier by prioritizing them in the browser.
• #63: Basically loads images later in the process or when a user is close to seeing them.Many systems kind of handle this for you now.
• #65: you’re taking critical parts of the CSS and putting it directly into the HTMLYou can also inline images, but caching is more complicated.
• #67:  hide text for up to 100ms, then only use the web font if it is available - never swapping
• #68: Ideally you’d chunk the needed parts so they’re smaller, then load the rest later
• #70: Maybe async things like analytics to get that data sooner, but in general anything not needed until later or that doesn’t have dependencies you’ll want to defer