Jump to content
Search Community

Can a kind soul help me debug performance on this "Fixed Reveal Section" experience on Mobile?

cheestudio test
Moderator Tag

Go to solution Solved by OSUblake,

Recommended Posts

I can create a codepen, but I figured we can start here with the actual site, since it would be a significant amount of work to replicate this a CodePen, and I have a feeling it needs to be seen in it's entirety to debug properly. I've run into my first real performance issue with a GSAP config and I'm not sure where to start, because the site is really simple and minimal and this site works fantastically on desktop.

 

I'm pretty flabbergasted that it's basically unusable on mobile, because I've done WAY more advanced things with GSAP with almost no performance issues, so I'm really not sure what I am missing here:

 

https://ebook.chee.studio/

 

It's more or less in the vein of the Revealing Sections from Bottom Demo (embedded below)

 

In this case however, every section was wildly different in terms of the amount of content/height, so I needed to run a loop and calculate unique end points for each section so each one scrolled at the same rate. I also needed to use position:fixed in my use case, but I am using "will-change", but not sure if maybe that's a potential problem since I've seen fixed positioning cause issues on mobile before...also not sure how to make this experience work without it, though.

 

Here's the main "engine" script running the experience...there's very little JS otherwise on the site:

 

var panels = gsap.utils.toArray(".scroll-section");
  gsap.set(panels, {
   zIndex: (i, target, targets) => targets.length - i
  });

  function sizePanels() {
   var heightSoFar = 0;
   panels.forEach(function(panel, i) {
    if (i !== panels.length - 1) {
     gsap.to(panel, {
      yPercent: -101,
      boxShadow: "0px 0px 0px rgba(0,0,0,0)",
      ease: "none",
      scrollTrigger: {
       start: heightSoFar,
       end: heightSoFar + panel.offsetHeight,
       scrub: true
      }
     });
    }
    heightSoFar += panel.offsetHeight;
   });

   gsap.set("body", {
    height: heightSoFar
   });

  }

  sizePanels();

 

I've looked through the threads on performance, but I'll admit this is my first foray into using things like the Chrome Performance auditing tools, so I'm not sure what I'm looking at to even know where to point and say "Ah, there's a potential issue"! 

 

May I get a helping hand? 🥺

 

See the Pen BaowPwo by GreenSock (@GreenSock) on CodePen

Link to comment
Share on other sites

  • Solution

Performance all comes down to how complicated it is for the browser to render whatever changes you are telling it to do. Transforms and opacity are super fast. Sometimes filters are too, but all it depends. Box shadow is super sloooooowwwwwwWWWWWW. Try getting rid of that. 

 

And try adding will-change to the elements you are animating.

.container {
  will-change: transform;
}

 

CSS containment can be another performance booster, but sometimes it can mess stuff up. You just have to test and see.

.container {
  contain: content;
}

 

https://developer.mozilla.org/en-US/docs/Web/CSS/contain

 

  • Like 4
Link to comment
Share on other sites

Here's a tip!


I'm not sure what you're applying the box shadow to - But rather than animating the box shadow, it's sometimes helpful to create a pseudo element or span and apply the box shadow to that - then animate the opacity of that element.

It'll look waaay smoother and less janky.

  • Like 3
Link to comment
Share on other sites

@Cassie used to to that often in the past, and I'm usually a fan of finding clever solutions like that over high power resource hungry approaches.
But I this case putting semantically unnecessary <span>s in the page or building komplex pseudo-elements for a drop-shadow seems so 1990s.

 

Sometimes I feel that we should not spent time and thought on working around limitations that really make no sense in todays browsers....

 

But that's just me ranting no critique at all.

Link to comment
Share on other sites

I don't really see the issue with using a pseudo element. I use them all the time for presentational stuff like this.

Extra spans or divs feel less ideal to me because they muddy the markup. But technically there's nothing wrong with using one. They hold no semantic value, they're purely for layout or presentation - as is the box shadow. It's no different from using a containing div to apply a layout class or similar.

 

Link to comment
Share on other sites

I don't have any issue with pseudo elements, nor am I above using empty spans etc. 

 

it's just that in this case it should be very straight forward. A box that we want a shadow for, should be one line of css and one line of js to animate.

As I said I did not want to criticise you at all - on the contrary. I just was saying that In this case there should in my mind be no need for anything...

  • Like 2
Link to comment
Share on other sites

As someone who gets paid to implement solutions like this, I'm often glad that a workaround is required. 

@Cassie just taught me something that I can use to impress my customers: giving the impression of a smoothly animated box shadow that I can throw behind buttons/cards to add depth to my designs without introducing jank.

Given the fact that it's not straightforward, it's going to be that much harder for other developers (competitors, peers, etc) to implement, which adds value to my offerings.

If web design was straightforward, easy, and simple, I'd be out of a job.

So while I'm optimistic that browser performance and CSS specs will improve over time, and that this 'hack' may be unnecessary in a couple years, it puts me on the cutting edge and I'm going to run with it :)

Dave  

 

  • Like 3
  • Haha 1
Link to comment
Share on other sites

This has developed into an interesting discussion. I love this community!

 

I find I am always struggling between being a proponent of good web standards, while also understanding the limitations of technology and the reality of the "client request." It's a constant decision making process. I would love to be able to get clients to understand semantic HTML, not relying on JS for layout and "polyfills" too much, being mindful about load time (every character counts...no pun intended) and maintainability of the code base, especially for future devs. @Ginger Soul I can't tell you how many sites I've stepped into where the previous dev went full on "let's just hack it together and do whatever the client wants" and it ended up biting the client in the booty in the long run, since the code base became too difficult to unwind or make modifications to. Sometimes it almost seemed intentional, as if they were trying to make it in such a way that only they could figure out how to change things. Not saying that this is what you're suggesting or condoning, it just got me thinking about that approach and the slippery slope it can lead to.

 

On the other hand, if I stick to my "purist tendencies", what you say is also true, and my work might not stand out as much as it could and blends in with all the other run-of-the-mill developers.

 

So it's a constant balance, weighing and "cost/benefit analysis" of the situation. In this particular case, is a non-semnatic empty div or pseudo selector, a few extra lines of CSS and some JS worthwhile to generate a dropshadow effect that is performant on mobile? For the status of the client (international marketing agency) and for the overall minimal codebase otherwise (small site), my gut is saying "absolutely."

 

But that's the constant battle we must fight, because if you're too cavaliar and just do whatever the client wants without regard, you could end up doing them a disservice. And they don't know one way from the other, and they look to us as professionals to make those recommendations and have their best interest at heart. I've pushed back on many a' client requests and when I explain the potential impacts, they almost always say "Oh wow, I had no idea, thanks so much for educating me...let's find an alternative solution!" (which I always try to have ready).

 

OK, I digressed, meandered and blathered, but I don't get to "talk shop" very often....so yeah, thanks all! And @Cassie, I remember coming across your stuff when it was featured somewhere (CSS Tricks, maybe?). You're a digital magician and your stuff has inspired me numerous times! 😊 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Few thoughts:

  • Web design is a service industry. You're supposed to do what the client wants (or what will delight them), even if it's semantically 'messy' sometimes.
  • If there's a wayward span in your markup, that's what comments are for. There's thousands of lines of code at work getting a website to render stuff; one little UI hack isn't going to tip the scales. Explain what you're doing for the next dev.
  • Being a purist about things like markup and performance usually has me going back to this article. UX wins in my mind. 
      
  • Like 2
Link to comment
Share on other sites

"You're supposed to do what the client wants (or what will delight them), even if it's semantically 'messy' sometimes."

 

I agree...to a degree. I've stepped into some pretty terrible projects because the previous dev was an order taker and did what the client wanted, not what the client needed. When I tell the client why their site basically needs a re-write, they say "Oh, the previous developer never said anything, he just kept doing the work as requested." So, it's a balance, as well as understanding your client. Even after I speak my piece, they might still end up doing it anyway...but I know I've saved many hours of hairpulling from devs across the country because I was able to reign in some of the ideas and approaches that the client was thinking of doing. While we're a service based industry, we're also in a highly collaborative one.

 

And yes, documenting things is huge; I try to code every site I make with the notion that I might win the lottery next month and retire, never to be seen again. A developer should be able to step into my work with minimal effort (hopefully). The only projects where I don't feel that hasn't happened, is when I "do what the client wants" more than doing what I know will serve them best in the long run...but as you said, at the end of the day we're in a service based industry and it's not a hill I'm willing to die on, since it's their project ultimately....but I'll always offer my "professional advice". 

  • Like 2
Link to comment
Share on other sites

Or you could just create your own custom element and encapsulate all the markup and logic. 

 

<shadow-element elevation="1">Hover Me</shadow-element>
let element = document.querySelector("shadow-element");

// triggers shadow animation
element.elevation = 24;

 

See the Pen d0cd70bf2923b2620cdccd857814075e by osublake (@osublake) on CodePen

 

 

 

 

  • Like 3
  • Haha 1
Link to comment
Share on other sites

4 hours ago, cheestudio said:

Sometimes it almost seemed intentional, as if they were trying to make it in such a way that only they could figure out how to change things.

Not that I would do things like that at all. But I have to admit, that sometimes I wish I could have...
Not very often, but it happens from time to time that a client (often connected to changes in management) want's to 'cut costs' and thinks that a junior developer could take over for less money, or an other agency wants to get into the project by under-biting me... 
I'm tempted to sue over my intellectual right that they give away to a competitor. No solution, and as I said it does not happen often, but still...

Link to comment
Share on other sites

@iDad5 I can see where you are coming from. I've ran into that situation once. I said good riddance, because I know the service I provide goes far beyond just the development skills I have, but also the comprehensive knowledge of a lifetime of tech work, impeccable and prompt communication, technical direction, and project management. For every client that doesn't understand the value, there's two that do! And the only time that did happen, I checked back a year later and the site wasn't even live any longer... 😛

  • Like 1
Link to comment
Share on other sites

This is the script code. 

 

See the Pen 2299f81bb8d62dae207e12ed9d72ff94?editors=0010 by osublake (@osublake) on CodePen

 

I'm using Lit, and the weird symbols are TypeScript decorators. But you don't need to use TypeScript.

https://lit.dev/

 

And you don't need any helpers like Lit. 100% native.

 

See the Pen 084c410320bcaed334a50760a45ab0ab by osublake (@osublake) on CodePen

 

 

28 minutes ago, Ginger Soul said:

Is this more performant?

 

It's an abstraction, so there will be a slight performance hit, but we're talking miniscule, so nothing you would ever notice.

 

 

 

 

  • Thanks 1
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
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...