Yes , the ESP8266 can handle a low-cost flight-radar display, as long as it does not try to do everything at once.

The best approach is to let a server or flight-data API do the heavy work, then send the ESP8266 only the few aircraft currently needed for the screen.

Key tips:

• Show only nearby aircraft, for example the closest 5–20.
• Request compact data: short JSON, CSV, or a custom simple format instead of large API responses.
• Read network data piece by piece; avoid loading a whole response into RAM.
• Store text labels/icons in flash memory (PROGMEM) rather than RAM.
• Reuse fixed-size buffers and avoid frequent String creation, which can fragment memory.
• Update only changed parts of the display instead of redrawing the full screen every time.
• Receive flight data less often, such as every 10–30 seconds, while refreshing the display smoothly in between.
• Keep Wi‑Fi/network code non-blocking so the screen and buttons remain responsive.
• Use simple map graphics and limited colours; the ESP8266 is better suited to a compact radar-style view than a detailed interactive map.

In short: the ESP8266 is capable for a small, inexpensive “viewer” display. It is not ideal for decoding raw ADS-B data, storing many aircraft, or rendering complex maps locally. The secret is filtering and simplifying the data before it reaches the device.

One additional optimization worth considering is to design the aircraft data pipeline around a fixed memory budget rather than just limiting the number of aircraft displayed.

A few practical suggestions:

1. Use a fixed-size aircraft structure. Store only the fields needed for rendering, such as latitude, longitude, altitude, heading, and a short callsign. Avoid keeping the complete API response in memory.

2. Parse JSON incrementally where practical. If the API returns large responses, filter aircraft on the server before sending the data. On the ESP8266, use a bounded buffer and handle oversized responses safely instead of allocating memory dynamically.

3. Separate data updates from display rendering. Fetch new data asynchronously, validate it, and update the display from the latest valid snapshot. This helps prevent slow network requests from freezing the radar interface.

4. Handle stale and invalid data. Keep the last valid aircraft positions during temporary network failures, mark old positions as stale, and remove aircraft after a configurable timeout.

5. Measure free heap and fragmentation. Monitor ESP.getFreeHeap() during repeated network requests and display updates. Test long-running operation, weak Wi-Fi, malformed responses, and maximum aircraft counts—not just a successful startup.

I'd also consider making the maximum aircraft count and refresh interval configurable so users can trade off responsiveness, memory consumption,