Forum Moderators: phranque

Message Too Old, No Replies

Thoughts on mod pagespeed?

         

csdude55

7:53 am on Dec 14, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



As I'm setting up the new VPS, I see mod_pagespeed in the Apache modules:

[developers.google.com...]
[modpagespeed.com...]

I'm finding very limited information on it, so I would love to hear any experiences that you guys and gals have had... especially benchmark comparisons and incompatibilities.

When I tried to install it, I saw that it automatically removes mod_ruid2... I'm running PHP as CGI, anyway, so I guess that doesn't matter?

phranque

8:02 am on Dec 14, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



this module looks like it optimizes the response for best possible Google PageSpeed score.
not that there's anything wrong with that...

robzilla

9:09 am on Dec 14, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



It's better to optimize manually but if you don't have the time or expertise, the module could be helpful in reducing load times. With emphasis on could, as it very much depends on your site, so it's best to run your own benchmarks (as always). And enable filters sparingly as there is a cost to them.

JorgeV

2:48 pm on Dec 15, 2020 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month



Hello,

mod_pagespeed is doing what, some of us, are doing ourselves. It applies different tricks to reduce the size of pages and images. Removing spaces, line breaks, regrouping or removing some CSS rules, merging some external files, etc. As said, it's better to do this yourself, when you design your pages.

Adding a extra step before sending the page to the client, is not necessarily an improvement.

csdude55

12:41 am on Dec 16, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Well, I wanted to give you all an update.

My old VPS is running CentOS 6.10 xen hvm, and it has two Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz and 8G of RAM, on a 100G SSD. It's running Apache 2.4 and PHP 7.4, with CGI as the handler.

The new VPS is running CentOS 7.9 virtuozzo, and it has twenty four Intel(R) Xeon(R) CPU E5649 @ 2.53GHz and 8G of RAM, on a 200G SSD. It's also running Apache 2.4 and PHP 7.4, but with FastCGI as the handler. I also installed HTTP/2, and installed mod_pagespeed last night.

I'm testing a subdomain on my primary account. The first test (on the old VPS) uses MySQL locally, then I changed the A record for the subdomain to point to the new VPS for the second test. This second and third test use mysqli_real_connect() to connect to the old VPS for MySQL, using MYSQLI_CLIENT_COMPRESS.

So you can see that there are a few variables at play here: operating system, CPU, handler, HTTP/2, mod_pagespeed, and latency for the remote MySQL.

I should also mention that Analytics is active for both tests, but not Adsense.

Using webpagetest.org, my results were:

# Old VPS
First Byte: 0.470s
Start Render: 1.100s
First Contentful Paint: 1.043s
Speed Index: 1.912s
Document Complete Time: 2.384s
Fully Loaded Time: 6.207s

# New VPS without mod_pagespeed
First Byte: 0.478s
Start Render: 1.000s
First Contentful Paint: 0.964s
Speed Index: 1.611s
Document Complete Time: 1.986s
Fully Loaded Time: 4.006s

# New VPS with mod_pagespeed
First Byte: 0.516s
Start Render: 0.900s
First Contentful Paint: 0.914s
Speed Index: 1.524s
Document Complete Time: 1.584s
Fully Loaded Time: 6.370s


I'm kind of guessing that "First Byte" on the new VPS will improve once I move MySQL over. And I'm also guessing that "Fully Loaded Time" is relying on images and Analytics, so it's less important than "Document Complete Time".

Based on that, it looks like the improved hardware and using FastCGI and HTTP/2 improved the "Document Complete Time" by 398ms, and then mod_pagespeed improved it by another 402ms! Combined, that's a gain of 800ms, which I think is significant :-)

phranque

2:27 am on Dec 16, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



So you can see that there are a few variables at play here: operating system, CPU, handler, HTTP/2, mod_pagespeed, and latency for the remote MySQL.

mod_pagespeed is doing what, some of us, are doing ourselves.

it would be interesting to measure the difference between mod_pagespeed vs "old school" methods.

csdude55

4:23 am on Dec 16, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I would definitely be interested, too! I've already done things like compressing images, CSS, and JavaScript, minimizing HTTP connections (which may have been a complete waste of time, if I understand HTTP/2 correctly), etc, but obviously it did something beyond what I had already been doing.

robzilla

10:25 am on Dec 16, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



You've mentioned elsewhere that the two servers are 35ms apart. The Webpagetest test machine is in a third location, so you'd need to factor latency into your comparison somehow. I wouldn't rely on Webpagetest results alone, especially not single runs, but also try to understand what mod_pagespeed is actually doing. Each filter has an effect and a cost (mostly CPU*), because like GZIP compression it's all done on-the-fly, and you might not benefit from all of them.

(* The host machine may have 24 cores at its disposal, your VPS probably does not. Running lscpu from the command line will tell you how many cores your VPS is assigned.)

Something that mod_pagespeed does on-the-fly that I prefer to do manually is minify CSS and JS files. They don't change all that often, so it's a bit wasteful to minify and compress them on every single request. After I modify them I run a script that minifies and pre-compresses these files, thereby relieving the CPU of some stress. The difference is minor but certainly noticeable on benchmarks with hundreds or thousands of requests per second.

You might also look into Brotli support for your web server, if it isn't already included.

JorgeV

1:02 pm on Dec 16, 2020 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month



Hello,

Beside minifying CSS, JS, HTML, you can experiment with compression level , as well as data chunk size. If you compress a page in one block , it will take less time to download, but the first bytes and first paint will come later (this is relative, we are talking of milli seconds), so, by experimenting you can find the right balance.

You might also look into Brotli support for your web server, if it isn't already included.

+1 for Brotli.

Also , don't forget about cache, even if you have a dynamic page, some part of it can be cached, and not regenerated each time. For example, on each page of m ysites, there is a list of recent messages, I generate this list only one time per hour, instead of it generating for each requests. etc.

csdude55

6:59 pm on Dec 28, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Another notation on the module...

I didn't notice this before, but when I go to one of my less-used sites I see that it's forcing CSS to load at the end instead of where I put it. So where my design had a small CSS file at the top and then loaded the full CSS page to cache at the end, now the whole thing is being postponed. Which isn't a huge deal, except that there's a 1-2 second period where the first page looks terrible and then suddenly appears to fix itself.

Any idea where to find pagespeed.conf? I'm on CentOS and the docs say it'll be at /etc/httpd/conf.d/pagespeed.conf, but it's not.

[modpagespeed.com...]

csdude55

7:53 pm on Dec 30, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



It took awhile, but I found it:

/etc/apache2/conf.modules.d/510_pagespeed.conf

I don't know if the "510_" is dynamic, so YMMV.

Right now I'm having an issue with the CSS caching. I have 60+ domains parked on top of the main domain, and they all include the CSS with their own domain:

<link rel="stylesheet" type="text/css" href="https://www.parked_domain.com/includes/styles_uni.css">


The module changes it to something like:

<link rel="stylesheet" type="text/css" href="https://www.parked_domain.com/includes/A.styles_uni.css,qh=1604823036.pagespeed.cf.LpeAzd2rBd.css">


On one of the higher traffic parked domains, I see that everything looks fine. But on several others (the lower traffic domains), the CSS takes a few seconds to load so every page looks bad at first and then flickers to where it's supposed to be. And it's not just the first page load, I'm seeing it on every page! So for whatever reason, it's not caching on those domains at all.

I don't know that I want to exclude CSS from the module entirely, but I'm not sure how else to fix it. Any ideas?

csdude55

3:32 pm on Jan 5, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Another update...

I had a user comment that many pictures on the site weren't loading properly. Specifically, I have a list on one page that shows anywhere from 25 to 1,000 thumbnails, then when you click on the intro there's a second page with larger photos. It looks like the thumbnails after the first 10 or so weren't loading, but everything loaded fine on the details page.

He said it was happening on both his phone and computer, but I don't know if his phone was using his home WiFi (implying the same internet provider).

I couldn't duplicate it on my end, but I had him click a direct link to the thumbnail and he said it loaded just fine. So it wasn't an issue of connectivity.

I could see from the console that mod_pagespeed was converting the images to .WEBP format, which it's supposed to do:

[modpagespeed.com...]

For the sake of testing, I uninstalled the module entirely, and now the user has confirmed that everything is working fine. So that was definitely the issue!

My next plan is to reenable it tonight, then modify the configuration to exclude CSS and the directory with thumbnails:

# sites are loading CSS out of order, causing awkward page loads. Move CSS to the header, but 
# if this doesn't work then you can disallow */styles*.css
# https://www.modpagespeed.com/doc/filter-css-to-head
ModPagespeedEnableFilters move_css_to_head

# thumbnails aren't loading properly, exclude the directory until there's a solution
# https://www.modpagespeed.com/doc/restricting_urls
ModPagespeedDisallow "*thumbs/*"


This page is exactly the one I was hoping to improve the most, though, so I'm disappointed that it's not working seamlessly.

robzilla

6:45 pm on Jan 5, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



That's the problem with automated optimizations, you don't know exactly what's happening where. Unless you dig into the documentation and figure out what every filter does, of course. The module can be quite powerful, making certain optimizations more accessible and easier to deploy, but it's not really a plug-and-play, one-size-fits-all solution.

JorgeV

10:33 pm on Jan 5, 2021 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month



Hello,

I would say, keep things simple.

phranque

11:57 pm on Jan 5, 2021 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



I had a user comment that many pictures on the site weren't loading properly. Specifically, I have a list on one page that shows anywhere from 25 to 1,000 thumbnails, then when you click on the intro there's a second page with larger photos. It looks like the thumbnails after the first 10 or so weren't loading, but everything loaded fine on the details page.

were there any clues in the web server access and error log files?

csdude55

12:28 am on Jan 6, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Nothing I've been able to find, @phranque. They don't appear to have thrown an error anywhere, so I'm taking a wild guess that it was an issue of the internet provider timing out before completing the connection.

@JorgeV, I like to KISS, too ;-P LOL In this case that probably means to get rid of whatever's causing the stress, but it DID speed things up considerably! And in my case, load time means money. Tweaking it seems to be akin to throwing things and seeing what sticks, which is a bit of a pain when I can only do a few updates late at night (when the server load is low) and then wait to see if people complain before moving on to the next idea. This one was running for 3 weeks before someone said something, though! I could be tweaking this for the rest of 2021...

phranque

12:44 am on Jan 6, 2021 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



They don't appear to have thrown an error anywhere, so I'm taking a wild guess that it was an issue of the internet provider timing out before completing the connection.

a "human" request for the thumbnail page without immediate subsequent requests for thumbnail images is a clue.

csdude55

4:59 am on Jan 7, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Another update...

The code I gave earlier didn't quite work, after all. It did fix the issue with the thumbnails, but I was still having the awkward glitch from CSS loading incorrectly. So unless someone has a better suggestion, I had to disallow CSS entirely, too:

# sites are loading CSS out of order, causing awkward page loads. This didn't work:
# ModPagespeedEnableFilters move_css_to_head
# so disallow entirely on CSS
ModPagespeedDisallow "*.css"

# thumbnails aren't loading properly, exclude the directory until there's a solution
# https://www.modpagespeed.com/doc/restricting_urls
ModPagespeedDisallow "*thumbs/*"


(Note, you have to restart Apache after modifying this file)

I'm pretty sure that disallowing it on CSS eliminates several of the optimizations, though, like automatically converting background images to sprites. So this was the LAST thing I wanted to do, but I'm not sure if there's a better alternative :-(

robzilla

9:17 am on Jan 7, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



like automatically converting background images to sprites

Probably hurts more than it helps. Browser support for HTTP/2.0 is at ~96%.

zulu_dude

11:52 am on Jan 7, 2021 (gmt 0)

10+ Year Member Top Contributors Of The Month



If the page is that image-heavy, have you considered using a CDN? I changed one of my busiest (and also image heavy) sites to use one and it made a significant difference to the load speed as perceived by users. Didn't actually do any formal testing of the load time, but the positive user feedback was enough to warrant it in my case.

csdude55

8:14 pm on Jan 24, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Just for those future readers, today I discovered that Pagespeed was choking on PNG images. It tried to convert this:

example.com/images/male.png

to this:

example.com/images/200x200xmale.png.pagespeed.ic.xnE3iHQleX.webp

The original would load just fine, but their modification was returning a broken image. I don't know if this is a new thing (maybe an automatic update to the module?) or if it's been doing that all along, but I just now noticed it today.

The only way I could find to fix it was to Disallow *.png in the configuration.