Какой самый простой способ добавить кеш страницам (php)

скорее всего это не данные о фактической погоде, а сохранённые прогнозы, поэтому такие данные полная туфта

Ну автор же четко написал:

И кстати добавив сюда данные о прогнозах на это время - вообще получаться бесценные данные, позволяющие оценить расхождение фактической погоды и прогнозов - мечта для любого метеоролога))) Так что думаю, ту не прав в своей оценке.

😀разве что для метеоролога, я глянул, на его сайте (вычислил по его постам) данные сильно расходятся по количеству осадков например в ялте с википедийными, это точно по прогнозам, а не по факту

и да, с гораздо лучшим качеством и бесплатно, можно получить такие данные, у же не по прогнозам, а модельные (либо фактические, для тех мест, где они имеют данные) от коперника от ecmwf или американского ноаа, например  https://cds.climate.copernicus.eu/datasets/reanalysis-era5-land?tab=overview

Пусть ТС сам отвечает на этот вопрос. Понятно что это интересно узкому кругу потребителей. Ну и тема не про ценность данных, а как решить проблему, смысл обсуждать нужно или нет? Я то прокомментировал это BTW,  в контексте основного вопроса. 
Но в любом случае, считаю что любая статистика может иметь ценность. А уж решать это не нам) 

Я вот счас пытаюсь решить сложную задачу, как раз по этой теме -  Стоит ли покупать зимнюю резину или достаточно всесезонки? С учетом того, что в прошлом году снег у нас лежал 2 недели))) А хранить второй комплект и особо негде)))

глянул сайт, загрузка страницы аж ~6000 мсек это никуда не годится!
я за то, чтоб почистить базу от архивных данных, нафиг они не нужны за 10 лет
другое дело, если это не поможет, может и не в бд дело, а диск крашнулся и теперь тормоза на весь сервер)
я так подумал, потому что у него статика на сайте отдается 100-200мс, а должна отдаваться за ~=ping

5 лет езжу (правда мало) на всесезонке, никаких проблем не было

по теме, думаю, у ТС данные лежат просто тупо по дням в базе, а потом он их на лету агрегирует, поэтому и тормоза, надо агрегировать по месяцам/годам и сохранять агрегированные

ну я привел свой флоу, как это решать. Не видя структуры базы - невозможно что-то советовать, можно просто предложить алгоритм решения.

Поэтому у меня пункт1 - развернуть это все локально.

Кэширующий прокси 😊

Facepalm. Поставьте хотя бы 5.4 (.45) 😊

Необязательно. Можно кэшировать страницу не при первом обращении, а заранее (отдельное действие, действие при сохранении основных данных станицы, запускаемый вручную или автоматически фоновый процесс). Также можно использовать кэширование при первом обращении, но выполнять это обращение самому (действие "предпросмотра", запускаемый вручную или автоматически процесс "обхода" определенных страниц).

Ждем следующую тему: Кэш страниц разросся до невероятных размеров. Что делать? 😊

Индексы нужно периодически перестраивать. Но в данном случае они скорее всего просто неправильно составлены.

чтобы не было никаких задержек, даже если кэш истёк, то если пхп работает как FastCGI либо PHP-FPM  и доступна функция fastcgi_finish_request, то первое отображение можно сделать так, чтобы бралось из кэша без задержки (если кэш имеется), и если кэш истёк, то после вызова fastcgi_finish_request обновлять кэш, а если как модуль апача, то тоже можно, но гораздо сложнее, с задействованием обновления кэша по крону

также, если пхп работает через нджинкс+ PHP-FPM и  имеется доступ к его настройке, то можно и через нджинкс такое кэширование прикрутить

Или с самими запросами беда, но я не стал повторять то, что уже написано в теме.