Episode Details

Ever wonder why your SharePoint pages still crawl, even after you moved everything to the cloud? You already have files on your CDN, but users are still seeing slow load times. Today, we're cutting through Microsoft’s documentation to show you the one setting pros use to unlock consistent speed—no magic, just smart configuration. Let’s build a SharePoint experience your users actually want to use.Spotting the Real Bottlenecks in SharePoint OnlineIf you’ve ever flipped every modern toggle Microsoft suggests, only to watch your SharePoint Online site load like it’s still running on an old on-prem server, you’re not alone. Most admins expect the cloud will erase years of slow load times and confusing bottlenecks, almost like magic. But SharePoint Online brings its own set of speed bumps—and one of the sneakiest offenders is hiding in plain sight: your static files.The reality is, moving to the cloud definitely upgrades your backend. But speed still takes a hit if you don’t keep an eye on the basics. Static files—think images, CSS, and all those little JavaScript helpers—traffic through SharePoint every time your page loads. Doesn’t matter if it’s an intranet homepage or a tiny team site for project managers. Every user gets the full loadout, whether they need it or not. And the worst part? It’s all happening behind the scenes. That’s why page loads stall even when your network and server metrics look fine. SharePoint’s cloud backbone takes care of your documents and security, but it doesn’t get picky about how or where it grabs your static files.Let’s walk through what’s actually slowing you down. The hidden bottlenecks aren’t your classic SharePoint features—they’re the document library clutter and all the assets stashed under Site Assets and Site Pages. If you dig into any decently used site, odds are you’ll find a graveyard of leftover images for events that ended years ago, test JavaScript from a power user’s weekend experiment, or old PowerPoint assets uploaded and never removed. And while Microsoft tells you to keep your document libraries organized, they don’t tell you that loading all these files every session is quietly wasting your users’ time.Now, figuring out which files are dragging things down doesn’t take a forensic IT degree. You just need the browser’s developer tools—Chrome DevTools or Microsoft Edge Developer Tools do the trick. Fire them up, go to the Network tab, and reload your SharePoint site. You’ll see a waterfall of requests. Watch for anything labeled as an image, style sheet, or script. If something’s taking more than a few hundred milliseconds to load—or worse, a few seconds—you’ve found a culprit. Microsoft’s own SharePoint Site Usage reports can also give you a clearer picture of what assets get hit most, but browser tools let you pinpoint the precise files, right down to the rogue PNG buried in a subfolder.Here’s an example I run into all the time. One marketing team loved branding so much they uploaded thirty different versions of their logo, trying tweaks for a launch. None of the old ones ever got deleted. Now, every single page on their SharePoint Online intranet loaded each logo in sequence, thanks to a web part that didn’t filter assets by current use. That meant each page pulled thirty unnecessary images—each one a few hundred kilobytes—on every reload for every user. Multiply that by a few dozen users and you’re not only slowing down the experience, you’re chewing through bandwidth you probably intended for actual work.Let’s call this what it is: wasted data, wasted money, and users quietly getting frustrated. When teams ignore these static files, it piles up. SharePoint’s not shy about serving files—you give it a folder full of PNGs, and it delivers, every single time. Users start working a little slower, pages lag, and eventually, someone decides SharePoint is “just slow,” when in reality, you’re just delivering bloat with every click.It gets worse when you look at the research. Studies e