Jump to content

SVG-based image lazyloading as a matter of enjoyable UX


Andreas Augustin
 Share

Recommended Posts

Hey!

We use Processwire in for Blue World Content Section and did some fancy SVG Primitive lazyloading for our images.

How do you like it: https://www.blue-tomato.com/blue-world/

We also wrote an article about how we did it:

https://dev.to/btdev/hey-user-you-already-see-me11---svg-based-image-lazyloading-as-a-matter-of-enjoyable-ux-1de9

  • Like 6
Link to comment
Share on other sites

  • 1 month later...

I had to first deactivate uBlock Origin, because there was a JS error. Not sure why though. Maybe - if possible - move these to somewhere else? (Not sure if they were blocked strictly because of the domains, or because of the JS-content)

I'm talking about the first two in the screenshot

blue-tomato-js-console.thumb.PNG.da20de9d9cd96eded5390668c2ab8d1e.PNG

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By Chris Bennett
      2021 update
      These things change and get tweaked over time, as stuff always does.
      We can make the size declaration a little more relevant.
      Declare a selection of sizes for your svg to "encourage" chromium-based browsers to use it instead of the larger bitmapped 192x192 and other assorted icons.
      We also need to thread the needle to ensure app start icons don't get confused and end up with an icon that is smaller than desired.
      Declare it last, after your png fallbacks - last one that is suitable size *must* get the nod. Counter-intuitively, declare that your svg is 150x150.   (adjusted for 2021) 👉 "sizes": "48x48 72x72 96x96 128x128 150x150 256x256 512x512 1024x1024",
      { "name": "Alfresco bar + bistro, Eumundi", "short_name": "Alfresco", "description": "Relaxed outdoor dining on our spacious deck in Eumundi", "start_url": "/", "display": "standalone", "background_color": "#acbd72", "theme_color": "#acbd72", "icons": [ { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon-48x48.png", "sizes": "48x48", "type": "image/png", "purpose": "any" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon-192x192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/maskable-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon.svg", "sizes": "48x48 72x72 96x96 128x128 150x150 256x256 512x512 1024x1024", "type": "image/svg+xml", "purpose": "any" } ] } Cross-Origin-Resource-Policy (CORP) manifest/icon bug
      A slightly-related testing note, if you are incorporating Cross-Origin-Resource-Policy (CORP) to enhance site security.
      Please note there is a chromium bug which affects chromium dev tools ability to properly display your manifest icons:
      Chromium DevTools bug: Cross-Origin-Resource-Policy prevents manifest icons from loading

      This long-term bug doesn't seem to affect the way the manifest itself works or the icons, just their display in Dev tools > Application > Manifest in  Chrome, Edge, Brave, Opera... sheesh.
      Firefox Dev tools continues to happily display them without a problem.
      ------------------------------------------------------------------------------------
      Quick tip for 2020 web manifests, which I couldn't find anywhere else.

      Wanted web manifest on Chrome/Edge to download the tiny favicon svg, instead of the larger 192x192 png it wanted to by default.
      Not a big deal, but mildly annoying: 15kb (non-scalable) png vs 1.5kb (infinitely scalable) svg.
      After a little head-scratching and fiddling around, came up with a solution that seems to do the trick.
      Declare it last, after your png fallbacks - last one that is suitable size *must* get the nod. Counter-intuitively, declare that your svg is 150x150.   (adjusted for 2021) Mine isn't. Never has been, it's a scalable vector graphic.
      Simply declaring it is 150x150 in the manifest is enough to get the job done.

      Suspect the Chrome/Edge engine declares that any non-specified svgs are given that 150x150 size and anything else returns as a "fail".
      Without declaring a size on it, or declaring it as anything other than 150x150, it just wouldn't load. 
      Weird, but works, so I'm happy 😊
       
      { "name": "Longer App/Business Name", "short_name": "Short Name", "description": "Description of App/Business", "start_url": "/", "display": "standalone", "background_color": "#880000", "theme_color": "#880000", "icons": [ { "src": "favicon-192x192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" }, { "src": "favicon-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" }, { "src": "maskable-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }, { "src": "favicon.svg", "sizes": "150x150", "type": "image/svg+xml", "purpose": "any" } ] }  
    • By Max Esnée
      Hi,
      When I upload a large(ish) SVG (≈120ko in this case) into an image field, it tends to get stuck at 100% and block the whole website. If I force refresh the admin page, the svg has not been uploaded. The file is correctly copied into the assets folder though. Other svg tends to be uploaded fine albeit I've noticed that pages containing svg images in the admin are very slow to load generally. Other pages using the same template but with jpeg or png images are much faster to load.
      I get the following error in the JS console:

      I develop locally using MAMP on macOS and I'm using Firefox. I'm using the last ProcessWire version (3.0.165).
      I also tested in Chrome and got the same error.
    • By snck
      Hi there,
      I am having a strange problem. I have a bunch of sites that have similar content (text, images, map markers), but I am not able to edit two specific pages in the backend. I always get the following error (or 503 service unavailable):
      Maximum execution time of 30 seconds exceeded (Zeile 520 in [...]/wire/core/Pageimage.php) Line 520 in Pageimage.php:
      $imagick->readImage($filename); All of the images used on all of the pages are SVG drawings and I have no clue why there are no problems with the majority of pages but just two of them. Maybe one of you guys has experienced a similar problem with ImageMagick and SVGs?
      I have debug mode enabled, but I only get these errors and nothing more specific. Is there any smart way to find the source of the error?
      In the assets folder for all of the pages there are only SVGs so I expect no conversion to be done. If no conversion is happening, why would the script run into the max execution time? 
      I appreciate your thoughts on this.
      Cheers,
      Flo
    • By gebeer
      Hello all,
      sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: 
      a predefined folder in site/templates/ and/or a  page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully.
      UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version.
      Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference
      Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip
      Read on for features and use cases.
      Features
      Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ?
      If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github.
      Here's how the input field looks like in the page editor:

      If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip
      Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance.
      Thanks to all who contributed their feedback and suggestions which made this module what it is now.
       
    • By rst
      I am having problems uploading svg images in the the latest pw 3.0.98. It shows the preview and has the spinner on top of it, and just gets stuck on that.
      Worked fine in the previous version of PW
×
×
  • Create New...