My previous PHP issue is still unresolved and I just received the attached information from my host (Ipower/ipage) My site takes forever to load if at all.
Below is what my host posted when I logged in yesterday.
re: PHP Scripting
How PHP works at iPage
"iPage’s PowerPack allows you to write scripts using PHP. To ensure that your PHP scripts work smoothly, please refer to the following information before you get started:
"How PHP works at iPage
iPage’s PowerPack allows you to write scripts using PHP. To ensure that your PHP scripts work smoothly, please refer to the following information before you get started:
Path to your Web document root: /home/users/web/b5/ipw.jswphoto/public_html
This is important, as most of your scripts will need to specify this location. For example, this is required if you’d like your PHP script to upload files.
I have no idea what I am supposed to do. When I contact ipower/Ipage, the refer me my developer.
Suggestions and help appreciated.
A significant slowdown of a photo website following a PHP change is typically caused by technical incompatibilities or server-side resource constraints introduced by the new version or its configuration.
Common Causes Linked to PHP Changes
Incompatible Themes or Plugins: The most frequent cause of post-upgrade slowdowns or “critical errors” is outdated software that is not fully compatible with newer PHP versions (e.g., upgrading to PHP 8.2 in 2025). Outdated photo galleries or image processing scripts can fail silently, causing high server wait times.
Low PHP Memory Limits: Photo websites are resource-intensive. If a PHP update resets your memory_limit to a default value (like 128M), the server may struggle to process high-resolution images, leading to extreme slowness or crashes.
Missing PHP Extensions: Image-heavy sites often rely on specific extensions like GD or ImageMagick to generate thumbnails on the fly. If these are not enabled in the new PHP version, the site may resort to slower fallbacks or fail to process images entirely.
Deprecation and Slow Queries: Newer PHP versions may throw numerous “deprecation notices” if the code is old. If your server is configured to log these to a file or display them, it can significantly degrade performance.
Core Photo-Related Performance Issues
Unoptimized Images: Large, uncompressed files (especially those over 1MB) are the primary reason for slow visual sites. High-resolution images consume excessive bandwidth and take longer to load.
Dynamic Resizing Overhead: If the site uses PHP to resize images in real-time instead of serving pre-sized thumbnails, it places a heavy load on the server for every visitor.
Lack of Caching: Without proper server-side or browser caching, the server must re-process every image and page request from scratch each time.
Recommended Troubleshooting Steps
Revert and Test: Temporarily revert to the previous PHP version to confirm the update is the cause.
Enable Debugging: Use WP_DEBUG (for WordPress) or check the PHP Error Log to identify specific script errors or slow functions.
Increase Memory: Use your hosting control panel (like cPanel) to increase the memory_limit to 256M or 512M.
Optimize Media: Convert images to modern formats like WebP or AVIF, which can reduce file sizes by up to 80% without losing quality.
Audit Scripts: Use tools like Google PageSpeed Insights to see if images or server response times are the bottleneck.
Hi @Jim-W, we can rule out most of the above: Backlight doesn’t process images on-the-fly and galleries serve static image files. The slowness also appears on pages that have no images.
It looks like the slowest piece is the dynamic CSS and JavaScript files that Backlight returns. These look to take up to 31 seconds for one or the other (only one at a time seems to be slow to load, and in my limited testing it’s usually the JavaScript file). The generation of these files does require considerable processing (they’re generated based on the settings in your templates), however it should be much more performant than this. Backlight caches the generated files, so that processing should not be occurring for every request. The equivalent files on my own site take around 30 milliseconds to return, a thousandth of the time I can see on your server.
If I load the same files directly then the time is closer to two seconds. Still too long, but a big improvement on 31 seconds. I wonder then whether your host has some contention with multiple PHP requests - e.g. simultaneous requests for JavaScript, CSS and the page content itself.
Sorry, I don’t have much to suggest to improve this. If this was my own host, I’d look at trying a different version of PHP (in case the implementation and configuration is different - Backlight performs well across all modern versions of PHP, so trying a different version may help avoid any implementation issues on the host). I’d also see whether there are options for using Apache’s PHP handler or PHP FPM.
Can you visit the PHP Info page in Backlight (available under Admin > Special Links > PHP Info) and let me know the values for the following?
PHP Version (in the page title)
Server API
GD (is there a section for this and is “GD Support” set to ‘enabled’?)
memory_limit
Thanks for your input. I tried changing the php versions I tried all versions available to me, 7.4, 8.3, and 8.4. of the three, 8.3 works best. Do you think reloading my current version would help. I could not fine where CD support is located… doesn’t mean its not there. will keep looking. I also republished all my albums but didn’t seem to help. One thing I did find out, was that if I went to a specific album from inside Lightroom classic the album loaded what appeared to be normal. Not sure that means anything.
Would reloading my current version (5.0) or install 6.0?