glynnis
commented
7 years ago I looked more closely at this and I don't think these higher-res gifs actually end up being a good solution (especially as a quick fix) for a few reasons:
- The gifs that are more visually interesting, have more base map detail, or longer change over time end up being extremely large files, especially at a higher resolution that will look less stretched and grainy. Load time is already pretty significant for the gifs on production, and trying to reduce file size will make image quality suffer more than it already does.
- Using gifs for this style of display--stretched to 100% width no matter the browser width, which includes cinema displays, etc.--doesn't look good even at file sizes with higher dimensions. This is due to the inherent restrictions of the gif file format, which limits images to 256 colors and applies dithering effects (more technical details on that here: http://designingforperformance.com/optimizing-images/#gif).
More information about page load time:
- High page load times can result in much lower rankings for SEO.
- The gifs for the homepage are by far the biggest performance hit on page load. Here's a report on homepage load times (~16sec total vs. ~5sec for carto.com): http://www.webpagetest.org/result/170420_ZZ_1207/1/details/#waterfall_view_step1. Including images of that report in case that URL doesn't stay valid for very long (see below).
- I know we haven't established a performance baseline or budget for MapStory yet, but I think following best practices (especially for the homepage) would be best. Here's some info on how page load/performance affects user experience/engagement: https://blog.kissmetrics.com/loading-time/?wide=1. They find that 30% of users are willing to wait 6-10 seconds. Since we're already above that amount, I'm hesitant to add more of a hit to page load with larger gifs.
Some possible ways to move forward from here:
- Examine other ways to use gifs in a homepage design that won't impact performance so severely. Gifs with smaller dimensions, fewer frames, and less visual noise will result in smaller file types. Some tricks like using a gradient over the gif (or some other visual treatment) may be a way to draw attention away from the low resolution and still make the homepage look good while decreasing load time.
- Choose a different way to showcase animations or change over time features of MapStory. Some possibilities include: a short looping video (a la carto.com), an SVG (vector) background with CSS (or SVG) animations showing changes over time (made to look like a real MapStory with a basemap, etc.). APNGs might be an option in the future but don't have browser support or fallbacks sufficient for the browser types and versions we support currently.
- Look into embedding a trimmed-down MapStory directly on the homepage that may load faster, or that could lazy-load subsequent map animations as the user scrolls rather than all at once on page load (carto.com does something like this). Lazy-loading may not have much of an effect in reducing the performance hit, though, since MapStory has less homepage content/height than other sites. I'm guessing this also may be more effort in the short run than some other approaches.
Happy to chat more about this and possible solutions, either for implementing new gifs that are more enticing without negatively impacting performance, or trying to reduce performance hits for the current ones. We could also look at those two things as separate issues if that's preferable.
Let me know what sounds best in terms of how to proceed! 👍
jonpmarino
@reynalddizon has made some new gifs at a higher resolution to cut down on graininess and better match branding for the homepage.
However, because of the size/resolution change, we need to adjust the CSS for those areas of the homepage, since adding the new images in Django admin still relies on the current CSS, which has properties calibrated to current image sizes.
Once there's a fix for this, we'll need to coordinate with @Coop56 or @travislbrundage on the deploy so that the new images can be added via django admin as soon as the deploy goes live. Once I make the CSS adjustments the old images will probably look even worse, so we’ll want to be on call to add the new images as soon as the deploy goes out, or get the image files to the person making the deploy.