Core Web Vitals to affect Google rankings May 2021

philwareham · 2021-02-07 10:37:57

In case you weren’t aware, core web vitals will start affecting your site SEO around May this year. Now would be a good time to get your site’s performance up to scratch.

I’ve been working hard to get the official Textpattern sites as quick as possible. They pretty much pass Core Web Vitals in Lighthouse now – although server response time could do with tweaking a little bit (I need to investigate where the bottleneck is).

etc · 2021-02-07 12:17:18

philwareham wrote #328592:

I’ve been working hard to get the official Textpattern sites as quick as possible. They pretty much pass Core Web Vitals in Lighthouse now – although server response time could do with tweaking a little bit (I need to investigate where the bottleneck is).

Thanks for your work, Phil. I get a 99 score on an average PHP 5.4 server, so you should be able to hit 100!

philwareham · 2021-02-07 12:40:32

etc wrote #328595:

Thanks for your work, Phil. I get a 99 score on an average PHP 5.4 server, so you should be able to hit 100!

Currently for the .com site homepage (our heaviest page) I’m getting a Lighthouse score 99 on desktop and 94 on mobile after my latest round of updates. The initial server response time is stopping the 100 score on desktop and I need to find out why (it’s either the server itself or Textpattern causing the 400ms delay I’m seeing before HTML is served up.

Anything you can think of on Textpattern side that would cause delays? Maybe a slow request or something?

I will also liaise with Pete as I think he was contemplating putting Varnish cache into the server which would probably help.

etc · 2021-02-07 14:29:57

philwareham wrote #328596:

Anything you can think of on Textpattern side that would cause delays? Maybe a slow request or something?

A 304 response is reasonably fast (~50-60ms), so the server looks ok and we must check the templates (pulling content from other sites?) I would start by creating a fake section with empty page. If it loads okay, then create a dev theme and debug piece by piece.

Edit: plugins.textpattern.com/plugins/ for example looks faster.

colak · 2021-02-07 18:14:22

philwareham wrote #328596:

Currently for the .com site homepage (our heaviest page) I’m getting a Lighthouse score 99 on desktop and 94 on mobile after my latest round of updates. The initial server response time is stopping the 100 score on desktop and I need to find out why (it’s either the server itself or Textpattern causing the 400ms delay I’m seeing before HTML is served up.

I’m getting 83 on mobile and 98 on desktop on our .com site. Where it fails is on “First Contentful Paint (FCP)”

etc · 2021-02-07 23:08:12

philwareham wrote #328596:

400ms delay I’m seeing before HTML is served up.

Caching latest forum news saves ~100ms, but the performance score is still under 90.

colak · 2021-02-08 05:11:17

Could the js files move under the footer?

colak · 2021-02-08 07:19:55

Another suggestion as the site mainly fails on mobile devices. What if some of the content is not visible on mobiles? ie use a plugin to filter out some content.

bici · 2021-02-08 07:40:13

so what does this all mean for us plebes? do we need to care?

colak · 2021-02-08 07:57:30

bici wrote #328607:

so what does this all mean for us plebes? do we need to care?

I guess it has to do with search engine visibility. As much as it sucks G has the lion share of the market/prospective visitors. Using a less controversial language, having your site load quickly for your visitors is actually a good thing.

I am testing my sites on developers.google.com/speed/pagespeed/insights/ and I am getting high 90s scores both for desktop and mobile devices.

philwareham · 2021-02-08 08:31:54

colak wrote #328604:

Could the js files move under the footer?

No that would be worse for performance, we don’t do that as a rule now. It is faster to load the scripts in the head section of the HTML and then either defer (it you need the script to run after page load) or async (if the script can run as soon as possible). With either of those options the script is loading in parallel with other code and therefore thew page is ready faster.

If you load scripts in just before closing </body tag (the older method) then it is a render blocker while the script loads, or (if you then load those asynchronously) a time to interactive blocker, while the page waits for the script to finish loading and fire. Because the browser only starts loading the script late into the process.

Even IE supports defer so there is absolutely no reason not to use it. Scripts also load in the order they were deferred so you can, for example, load something like jQuery in this way as long as any scripts that use jQuery are deferred after that in the code order.

gaekwad · 2021-02-08 10:05:05

I’m testing Varnish cache, Nginx FastCGI cache and Memcache at the moment, and juggling site migrations to new servers, and work stuff to pay rent, and living arrangements that involve paying more rent in the near-ish future, so…still here, but busy, and I will get to everything when I can. Thanks for your patience.

High level: we’re moving away from a single $10 server which ran everything site-wise to four $5 servers which can be tuned and tweaked more readily when sites are migrated to their new homes. Once things are in place, we can sensibly cache the living daylights out of stuff and that will make a difference. Thanks again for your patience.

Textpattern CMS

Textpattern CMS support forum

#1 2021-02-07 10:37:57