Search

EDITED

We have done several steps to optimise the page speed of our symphony sites:

  1. Optimisation of the .htaccess (Gzip, Deflate, Cache) http://pastie.org/9804726

  2. Minified and combined Css, Js, Html (indent=no)

  3. Asynchronous loading of render-blocking JavaScript and CSS in above-the-fold content Js: http://pastie.org/9804730 Css: http://pastie.org/9804731

  4. JIT + Imager.xsl (https://github.com/firegoby/Imager.js)

  5. Optimisation of the images: download of all uploaded images and lossless compression with Imageoptim and upload again.

  6. Mobile optimisation, detection with https://github.com/DavidOliver/device_categorizr: Mobile menu only loaded on mobile device, disable unnecessary js, css components, content on mobile

  7. Symphony CacheLite Extension: https://github.com/symphonists/cachelite6 Works pefect with our frontend cms. We work with external database server (in the same datacenter) Reduced loading time with 4 seconds.

Conclusion: Website loading time went from 8s to 2,79s. Google Page Speed insights gave us 90/100 (website is loading a lot of images on the home)

Tools to check Speed and performance:

https://developers.google.com/speed/pagespeed/insights/

http://www.feedthebot.com/pagespeed/

http://gtmetrix.com/

http://seositecheckup.com/

Does anyone has more suggestions, advice? Does anyone know why all internal page links need a trailing slash? If not the link gets redirected to the link with a trailing slash..

Does anyone know why all internal page links need a trailing slash?

I think this is related to how symphony handles things. There's a 301 redirect added within the htaccess. to ensure all links have the trailing slash. I believe if it were not that way, you'd have to redirect the other way around, you don't want two urls serving the same page.

Btw in addition to those you can always enable things like Datasource Caching on the Symphony side, with Cacheable datasource, which could lead to having a much improved time to first byte. There's also full page caching which you could do, or element caching through cachelite if not mistaken, but the benefits of that might vary according to your website.

Seeing you're asking this question do you have any particular issue with page load speed on some website or just a generic query?

Gunglien, thank you for the info: - Trailing slash, indeed, but never noticed it before - Datasource Caching: works great - Are there any other things i can do on the Symphony side?

Can i load all my utilities in the master.xsl or do i load them as needed per page?

I've never tested for efficiency by reducing the amount of imported templates, but presumably they would have some impact. What I tend to do us common utilities go in the master. then Section related templates are loaded on an as-needed basis depending on the websites. Some you load everything others just load parts as needed.

If you want to know where you can speed things up, you might want to look at your ?profile pages, and see what takes longest from your site. Then you can see if you should be improving your templating, maybe XSLT is taking too long, or you have something wrong in your code. But that would be my starting point if you want to improve speed further.

My hostingprovider is telling me that the mysql database is running on a different server then the webserver, so 'cache_driver' => array('default' => 'database',) is making the site slower. Is this true?

They advice me to use APC, i have added the APCcache extension https://github.com/symphonists/apccache but how do i activate this?

Yes if you have the database on a separate extension that could make an impact. But the impact would depend on the distance you have in between the two servers, and delay in getting the results. If you check the profile by installing the Profile extension and appending the ?profile to your page url you will know exactly what's clogging up your website.

As for APC I've never used the extension, but you have to make sure it's enabled on your server first of all, otherwise the extension won't use the APC cache as requested. Also have you considered using multiple servers on the Frontend to deal with load? or having a more powerful server maybe?

Gunglien, It's a basic site, i have attached some screenshot of loading time and profile. The size is very small, not a lot of data, no need for multiple servers, but takes a lot of time:

Engine Initialisation 0.7452 s Page creation started 0.8240 s XML Built 2.9777 s Page Built 3.0390 s XML Generation 0.0253 s XSLT Transformation 0.0000 s Page creation complete 4.1236 s

Total Database Queries 298 Slow Queries (> 0.09s) 0 Total Time Spent on Queries 1.2431 s Time Triggering All Events 0.0145 s Time Running All Data Sources 2.7570 s XML Generation 0.0191 s XSLT Transformation 0.0000 s Output Creation Time 0.0000 s Total Memory Usage 5.02 MB

Attachments:
RecordIt.png, Google Chrome.png, Google Chrome 3.png and Google Chrome 2.png

Wannes that's a bit more helpful, the problem certainly lies within your data sources. To generate your data sources it's taking you 2.7 seconds.

I think the best solution would be to make sure that you have Cacheable datasource enabled for each data source, make sure you set reasonable timeframes which make sense for your website. It's ok to make some valid for a very long time if they don't really change.

Note that Cacheable datasource, stores the cache files within files on the server, so you will not be effected by having the database server segregated. Last time I used it this was the case. Make sure that the XML output within the debug page, shows you the time (how old it is) if it doesn't show then you have some problem with the setup. Using the extension you should kill quite a bit of your datasource generation time.

Gunglien, Thank you for all the feedback, problem was indeed the datasource / database queries to the external dataserver, cacheable datasource worked fine, but needed configuration: setting time for every DS and adding the flush to each event (we build a frontend cms). Cachelite did the job perfectly. This in combination with an adapted .htaccess gave us a loading time of 2,79s. .htaccess: gzip: html and css, deflate: js seems to be the best combination

http://pastie.org/9806385

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details