Sierra Mariola Gazet

Showcase
1

This community site is made with GRAV, using the Quark theme with a custom.css:

I have always worked with Drupal, but I like Grav a LOT more.
BTW, the site is in Dutch, but can be read in English and Spanish.
Hope you like what you see.

2

@TonHaarmans, Congrats on your first Grav project.

I think spending some time on performance will serve the site right. It felt slow, so I did some research.

  • Traffic lights generated by Google Chrome Lighthouse (home page):
    image
    Take some time to play with it, it will give you a wealth of suggestions.

  • Network traffic (home page):

    • 2.6 Mb upload
    • load time: 27 sec
    • 76 requests (14 css, 19 js, 35 jpg/png)
      • You might want to have a look at the docs on Asset Manager to bundle/minify css and js files to reduce traffic.
      • Loading of some css/js might be delayed using defer
      • You could have a look at the plugins used and see if their css is really needed. Eg. you don’t use a login, but login.css is nonetheless being loaded.
      • Images could be optimized for different screen sizes using srcset.
      • Image quality could be trimmed down. Eg. the corona image could have a quality setting of 20% without noticeable degradation and saving 70% in file size.

  • The build-in ‘honeypot’ strategy to prevent spam on your contact form might be a lightweight and yet effective alternative to reCaptcha.

3

Thanks a lot for your feedback. I deed some work on the performance of the site and I think it’s a lot faster now. Hope you can confirm this…

4

@TonHaarmans, Yes there is improvement…

  • Load time up from 27 sec to 3.6 sec. Well done!
  • Transferred bytes down from 2.6 to 2 MB
  • Lighthouse is still not very impressed though:
    image
  • Added external functionality and internal scripts:
    Are they beneficial to the visitor and/or essential to the working of the site and/or the business?

    • The site uses both statcounter and google analytics. What is the added value of running both?

    • How often do users use the Google translate option? Is it popular enough to load/run its scripts? NB. The Google Translate element overlays the menu.

    • Likewise the added Facebook buttons and their required scripts and css.

    • This is the first time I encounter browser-update.org which is supposed to notify users when they do not use the latest version of their browser.
      Although, I haven’t found any malware warnings on the web, I wonder if this is really such an important plugin to run on every page on every visit.
      Would you feel OK when out of the blue a site offers you to install the latest version of your browser? No thank you… I wouldn’t.

    • I see a bunch of scripts of which I do not understand the purpose. Two examples:

      • A script with class Zooming() which listens to .listen('a[rel="lightbox"], but there is no anchor with rel="lightbox" on the page.
      • Or a script with $(".slider .gallery-container"), but there is no element with class ‘slider’
  • There is a cookie consent popup, but there is no option to decline. And yet, already 11 cookies are being set (paypal, statcounter, browser-update, google , facebook) before given consent.

Just my 2 cents…

5

Thanks again! I will look into these issues asap. Concerning the scripts, they are not used on the home page, but on other pages. I don’t know how to keep scripts that are declared on base.html.twig from running on pages where they shouldn’t work…Perhaps you do?

6

@TonHaarmans, There are multiple approaches I can think of to enable/disable plugins.

  • A plugin could use a specific template for pages it should be activated on. Eg. lightslider.md
  • A custom template could be defined and assigned to a page: mytemplate.md. The template could then add css/js to the page.
  • A plugin could provide a ‘route’ property in its config which can be assigned a route or array of routes which can be handled by the code of the plugin leading to enabling/disabling its templates/assets.
  • A property in the header of the page could be set: contactform: enable: true and read in Twig: {% if page.header.comments.enable %}
  • A custom or existing config file could be used to set routes for the different plugins. In Twig the page url could then be tested against the config:
    {% if grav.config.myconfig.comments.route == page.url %} or
    {% if grav.config.plugins.comments.route == page.url %}
  • And maybe more…
7

Great, thanks again. I’ll have a look. You might have guessed, I’m actually a noob with Grav…

8

@TonHaarmans, Someone who launches a functional website build from scratch with Grav, can hardly be called a noob…