Cómo la actualización de aplicaciones en segundo plano afecta el rendimiento del WiFi público

How Background App Refresh Kills Public WiFi Performance — A Purple Technical Briefing. Welcome. If you're responsible for a guest WiFi network — whether that's a hotel, a retail estate, a stadium, or a conference centre — this briefing is going to change how you think about your air time budget. I'm going to walk you through one of the most underestimated capacity killers in public wireless deployments: background app refresh. We'll cover what it is at a protocol level, why it's particularly destructive in high-density environments, and — most importantly — what you can do about it at the network layer today. Let's start with the scale of the problem. Every smartphone your guests carry onto your network is running somewhere between 30 and 80 installed applications. Of those, a significant proportion are configured to run background refresh cycles — polling analytics servers, syncing cloud data, fetching push notification tokens, checking for OS updates, and pinging ad networks. On iOS, Apple's Background App Refresh feature was introduced in iOS 7 and has been a persistent fixture ever since. Android has its own equivalent through JobScheduler and WorkManager APIs. The key point is this: these processes run regardless of whether the user is actively using their device. They fire silently, invisibly, and constantly. Now, on a home broadband connection with one or two devices, this is essentially invisible. But scale that up to a conference centre with 1,200 delegates, or a retail flagship store with 400 concurrent guest connections, and the arithmetic becomes uncomfortable very quickly. Research into enterprise wireless deployments consistently shows that background traffic — analytics beacons, OS update checks, ad network pings, push notification polling, cloud sync, and social media refresh cycles — can account for between 30 and 45 percent of total access point capacity on a busy guest network. That's capacity that your legitimate users — the ones trying to stream a presentation, complete a transaction, or simply browse — are being denied. Let me give you the technical picture of what's actually happening at the radio layer. In an 802.11 network, every device that associates with an access point competes for air time using CSMA/CA — Carrier Sense Multiple Access with Collision Avoidance. Every background refresh request, however small the payload, requires a full association sequence: probe request, authentication, association, DHCP if needed, and then the data exchange itself. In a high-density deployment, this contention overhead is significant. A single analytics beacon from a single app might only transfer 200 bytes of data, but the overhead of that transaction on the wireless medium can consume 10 to 20 times that in air time. With Wi-Fi 6 — IEEE 802.11ax — we have OFDMA and BSS Colouring which help manage this more efficiently. But even with these improvements, the fundamental problem remains: you cannot reclaim air time consumed by background traffic unless you intervene at the network layer. The radio doesn't know or care whether a packet is a user watching a video or an app silently phoning home to a telemetry server in Virginia. This is where deep packet inspection and traffic classification become critical tools in your architecture. A properly configured traffic classification engine, sitting inline between your wireless controller and your upstream gateway, can identify background refresh traffic by its destination, its payload signature, and its behavioural pattern. Known analytics endpoints — Google Analytics, Firebase, Crashlytics, Flurry, Amplitude, Mixpanel, and dozens of others — have well-documented IP ranges and domain patterns. Ad network endpoints from DoubleClick, AppNexus, and similar platforms are equally well-catalogued. A regularly updated block list, applied at the DNS or IP layer, can intercept these requests before they consume any meaningful bandwidth. The approach is vendor-neutral. Whether you're running Cisco Catalyst Centre, Aruba Central, Juniper Mist, or a Ruckus SmartZone deployment, the principle is the same: classify, then act. You have three options for what to do with identified background traffic. You can block it entirely — the most aggressive approach, and the most effective for capacity recovery. You can rate-limit it — allowing the traffic through but capping it to a defined bandwidth ceiling, typically 64 kilobits per second per device for background categories. Or you can deprioritise it using QoS DSCP markings, pushing it to the lowest traffic class so it only consumes air time when no other traffic is competing. For most venue operators, a combination of blocking known analytics and ad network endpoints, combined with rate-limiting of OS update traffic during peak hours, delivers the best balance of capacity recovery and user experience. Now let me walk you through two real-world deployment scenarios where this made a measurable difference. The first is a 340-room four-star hotel in the UK Midlands. The property had invested in a modern Wi-Fi 6 infrastructure — 48 access points across guest floors, conference suites, and public areas. Despite the hardware investment, guest satisfaction scores for WiFi were consistently below target. The network team ran a traffic analysis using the Purple platform and discovered that background app refresh traffic was consuming 38 percent of available air time across the guest SSID during peak check-in periods between 3 and 6 PM. A targeted block list was deployed covering 847 known analytics and ad network domains. Within two weeks, average throughput per connected device increased by 34 percent during peak periods, and guest WiFi satisfaction scores improved by 22 points on the property's internal NPS tracking. The second scenario is a regional retail chain with 60 stores across England and Wales. Each store runs a guest WiFi SSID used by both customers and in-store digital signage. The IT team had been receiving complaints about digital signage latency — screens were buffering during busy trading periods. Traffic analysis revealed that customer devices connecting to the guest SSID were generating substantial background traffic, including iOS update checks that were pulling multi-gigabyte payloads through the store network. A combination of DNS-level blocking for analytics endpoints and a hard rate cap of 1 megabit per second for identified OS update traffic resolved the signage latency issue entirely. The fix took less than four hours to deploy across the estate using centralised policy management. Let me now cover the implementation steps you need to follow to deploy this in your own environment. Step one is baseline measurement. Before you touch any configuration, you need to understand your current traffic profile. Deploy a traffic analysis tool — Purple's WiFi Analytics platform provides this natively — and run it for a minimum of five business days to capture weekday and weekend patterns. You're looking for the proportion of traffic going to known background-refresh destinations, the peak periods of background activity, and the per-device consumption rates. Step two is building your block list. Start with the OISD domain block list as your foundation — it's well-maintained, community-validated, and covers the major analytics and ad network endpoints. Supplement this with your own observations from the traffic analysis. Critically, do not block indiscriminately. Certain background traffic — particularly Apple Push Notification Service on port 5223, and Google Firebase Cloud Messaging — is required for device functionality. Blocking these will generate user complaints. Test your block list in a staging environment or on a single access point group before rolling out estate-wide. Step three is policy deployment. Apply your classification rules at the WLAN controller level, not at individual access points. This ensures consistency and simplifies ongoing management. If your controller supports application-aware QoS, use DSCP marking to deprioritise background categories rather than hard-blocking everything — this gives you a softer landing and reduces the risk of unintended consequences. Step four is ongoing monitoring. Background refresh endpoints change. New analytics SDKs emerge. App developers find new ways to phone home. Your block list needs to be reviewed and updated at minimum quarterly. Automate this where possible using threat intelligence feeds that include ad and analytics network updates. From a compliance perspective, it's worth noting that traffic classification and blocking at the network layer does not constitute interception under RIPA or equivalent legislation, provided you are not inspecting the content of encrypted payloads. You are acting on destination metadata — IP addresses and domain names — not on the content of communications. This is consistent with GDPR Article 6 legitimate interests grounds for network management, but you should document your policy and ensure it is referenced in your network acceptable use policy and privacy notice. Now, a few common pitfalls to avoid. The first is over-blocking. Teams that deploy aggressive block lists without adequate testing frequently find they've inadvertently broken app functionality that users rely on. Always maintain a whitelist for critical services, and have a rollback plan ready. The second pitfall is ignoring the 5 GHz and 6 GHz band split. Background refresh traffic tends to cluster on 2.4 GHz because older devices and IoT endpoints default to that band. If you're only analysing 5 GHz traffic, you may be missing the majority of the problem. Ensure your analysis covers all bands. The third pitfall is treating this as a one-time fix. Background refresh traffic patterns evolve continuously. A block list that was comprehensive six months ago may be missing 30 percent of current analytics endpoints. Build a review cadence into your network management calendar. Let me close with a rapid-fire set of questions I hear regularly from network architects. "Will blocking analytics traffic affect app performance for my users?" In most cases, no. Analytics beacons are fire-and-forget. The app does not wait for a response before continuing to function. The user will not notice. "Does this work with encrypted DNS?" Standard DNS-over-HTTPS traffic can bypass traditional DNS-based blocking. You need to either intercept DoH at the gateway or use IP-level blocking for known analytics ranges in addition to DNS blocking. Both approaches are supported in enterprise-grade controllers. "What about BYOD devices on a corporate SSID?" The same principles apply, but you have additional options including 802.1X authentication and per-user policy enforcement. For a corporate SSID, you can be more prescriptive about what background traffic is permitted. "How do I justify the investment to the board?" The ROI case is straightforward. Recovering 30 to 40 percent of wasted air time is equivalent to adding 30 to 40 percent more capacity to your existing infrastructure — without buying a single additional access point. For a venue that was considering a hardware refresh to address capacity complaints, network-level traffic management can defer that capital expenditure by two to three years. To summarise the key actions from this briefing. First, run a traffic baseline analysis — you cannot manage what you cannot measure. Second, deploy a maintained block list targeting known analytics and ad network endpoints. Third, use rate-limiting for OS update traffic during peak trading or event hours. Fourth, monitor continuously and update your policies quarterly. And fifth, document your approach for compliance purposes. If you want to see how Purple's platform surfaces this data and enables policy deployment across multi-site estates, the link is in the show notes. Thank you for your time.