I'm going to take a wild guess and say that Google probably sees both documents correctly as a xls spreadsheet (provided that the Content-Type headers on the download.php url are set correctly).
However, generating the file will mean you'll have to decide where to store it. If you store it on the filesystem, you'll limit your ability to have more than one web server. If you store it in the database, you could be bloating your database a bit. If you store it on a CDN, there will be some latency while the file is propagated (from the time it's requested or generated).
But since you asked what my preferred method is, this is what I do. I don't like tying up the UI waiting for reports to generate. Where I work, some reports take several minutes to generate and tying them to the UI is error prone because if the user exits, it'll end the generation prematurely. Even though this may add complexity, I prefer to use RabbitMQ to decouple the events (ie. a generate report event from a user or a cron) from the work (ie. a process creating a report). RabbitMQ (or some similar message-bus architecture) also allows you to easily parallelize report generation (if there are a large number of them). Then, once the report has been generated, you can use one of the three storage methods (mentioned above) to store the generated report, safe in the knowledge that it's decoupled from your user's interaction. Caching even a little bit can help quite a bit (especially on a busy site). Users often don't mind a report to be a little stale. However, it very much depends on the nature of the report. If it's an operations report, it may be required to be up to the minute. In which case, there may be little room for pre-generating your reports. Also, if there are many different variables as inputs to the report, it may be infeasible to generate given the broad scope of the permutations.
Lastly, if the report generation is costly (in time, cpu, etc.), there is another hybrid option. You may be able to pre-summarize part of your report. If the latency-intensive part can be pre-calculated and the "up-to-the-minute" part of your report can use that information to quickly generate the report, then you may be able to directly generate the report from the user's request. With that, there are few more moving parts (such as invalidating the presummarization if the data changes). However, for records from the past (such as telemetry data), the data doesn't change. So, it's a great candidate for presummarization.
Sorry for the long response. Hope this helps.