Hi All,
I have been working to redesign our site using Drupal. The site is nearly finished, but appears (from our end) to be having performance issues. If I open the page from a fresh instance of firefox, I could wait 5+ seconds for the front page to load. Navigating from page to page seems to be the same. I have turned on boost and caching/aggregation of css and js. According to pagespeed (78 out of 100), I still need to put a longer expiration on pictures, but so far my efforts in our .htaccess file have been unsuccessful.
Our host, ipage.com, has reported that they don't see any issues from their end, so I thought I would see what others thought.
For comparison, our current site is at www.acsawater.com and the new site is at www.acsawater.org.
Thank you for any suggestions,
Casey
Comments
It is not bad. BTW you marked
It is not bad. BTW you marked your post D8 but of course you are on D7.
I would not tolerate it on one of my sites, but then I have reluctantly accepted that I need to spend a lot more on hosting for Drupal, i.e. get a decent VPS or dedicated server and tune it for Drupal. You cannot compare Drupal with a static site, or a Wordpress site which has a fraction of the code. A Drupal site with some major contributed modules added is a heavy powerful piece of software. Generally shared hosting, if it works at all, is right at its limits running a moderately complex Drupal site.
Obviously the host is not going to accept there is a problem, they almost never do. I would think that running a moderately complex site on shared hosting this performance is fairly typical, and so long as you are getting low traffic it will work ok, albeit a little slowly
You would probably do better on a real Drupal specialist host, though for this type of site a VPS makes more sense (and not just the small 'starter' VPS, spending $75 per month on an unmanaged Linode + backup is not unreasonable). If you are expecting a lot of read traffic, and if you do get a VPS, it is a good idea to install Varnish, which caches the pages so the server does not have to assemble them fresh every time someone calls them. I know boost is supposed to do something similar, though is not as fast. If set to do so, Varnish will serve cached pages and cached static resources from RAM.
I would not worry too much about the graphics. You have almost no, and only small graphics, and ensuring browsers cache them will make very little difference to user experience.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Good catch on the D8 vs D7. I
Good catch on the D8 vs D7.
I was afraid you were going to say something like that. Cost is an issue for us, so I might have to give this a rethink.
Thanks,
Casey
.:
As far as i see, pages are not being served by boost.
------------
Volvo, Video, Velcro. (I came, I saw, I stuck around.)
.
According the status page boost is enabled, and when I check the headers X-Drupal-Cache reports a HIT (if I've visited the page recently).
At the moment, HTML in boost has a max life of 1 day; I could try increasing that to see if it helps. It is also my first time using boost, so I could be setting something incorrectly.
Casey
I have been getting very
I have been getting very acceptable page load times on your site from central Europe just now.
There is still the problem is that shared hosting can be good, usually only if the other sites on the same server are not using too many resources. When one other user on the shared server, or on an OpenVZ VPS (software used for the cheaper VPSs) starts abusing or over-using the server, then all other users may suffer.
There are almost daily posts on whether or not Drupal works on shared hosting, with opinions both ways. Today there was useful contribution by a hosting company to one of the many threads on this topic: http://drupal.org/node/1462980#comment-5713166
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
check your status report...
Check your status report to see if it indicates that your HTTP request status has failed.
If so, put in place the workaround that this error suggests, which is adding this line to the bottom of your settings.php file:
$conf['drupal_http_request_fails'] = FALSE;
Between disabling overlay and putting this patch in place my site went from glacial to lightning ... the slowness was even more frustrating because it was a totally new install - free of contributed modules - running on a powerful local server.